Crossing Boundaries: A Deep Dive into Cross-Origin Attacks and Their Prevention
Hello Smart hackers, Welcome back to my new blog, I hope you all are well!! In this blog, we are going to discuss Cross-Origin Attacks and…
Hello Smart hackers, Welcome back to my new blog, I hope you all are well!!
In this blog, we are going to discuss Cross-Origin Attacks and Their Prevention.
Please, read this article until the end.
Before start writing the blog, I have such a small request for all of you, I always write articles on many. So if you didn’t follow, then follow me first and clap on this article, because that gives me the motivation to write something new !!
If you didn’t follow me on my social, here is my Twitter and LinkedIn.
Thank you !!!
Let’s Start !!!
Once upon a time, web applications were like islands, self-contained and isolated, with everything packed into a single domain. But the digital landscape has evolved! Today’s cutting-edge web apps are like bustling international airports, pulling in data and resources like flights from all over the world. When one domain acts as a traffic controller, guiding your browser to fetch resources from another domain, it’s like a jet-setting journey across borders. Welcome to the age of cross-origin adventures!
Let’s discuss about SOP(same-origin policy)
Origin is the combination of protocol, hostname, and port number. Browsers enforce SOP to stop one origin from accessing resources on a different origin [1]. SOP just blocks JS from reading from another origin.
“It helps isolate potentially malicious documents, reducing possible attack vectors. For example, it prevents a malicious website on the Internet from running JS in a browser to read data from a third-party webmail service (which the user is signed into) or a company intranet (which is protected from direct access by the attacker by not having a public IP address) and relaying that data to the attacker” [1].
So, How do we access resources in different origins if we want to?
That is the job of CORS (Cross-Origin Resource Sharing).
CORS:
Cross-Origin Resource Sharing (CORS) tells a browser (via headers)which origins can access resources from the server. Before making the actual request, browsers send a preliminary “preflight” request to the target server. This is to confirm if the server allows the main request. During this preflight, the browser provides details about the method and headers it intends to use in the main request [2].
Good to Know:
Before sending the actual request (especially for methods like PUT, DELETE, or any request that modifies data), the browser sends an HTTP OPTIONS request to the server. This is the preflight request.
Then, what the bell is CSP?
Content Security Policy (CSP) is a guideline that web pages use to determine which content sources, like scripts, styles, or images, are safe to load and run. These sources can be identified by URLs, schemes, keywords, or unique tokens called nonces. By default, browsers let web pages load content from any source. However, with CSP, set through HTTP headers or meta tags, web pages can limit these sources, helping to protect against threats like cross-site scripting (XSS) attacks. [3]
Did I just confuse you? Oopsy
Let me clarify,
CORS and CSP serve distinct security roles in web development. CORS manages how web resources are accessed across different origins, ensuring safe interactions between servers and browsers across domains. In contrast, CSP dictates which content sources are permissible for a webpage to load and execute, safeguarding against potential threats. While CORS is a collaborative protocol between the server and the browser, CSP is a policy strictly enforced by the browser. In essence, CORS oversees the communication between web pages and external resources, whereas CSP governs the presentation and functionality of a web page based on its content sources.
Attacks (Exploiting Cross-Origin)
1. CSRF (Cross-site Request Forgery)
Cross-site Request Forgery (CSRF) was a prominent threat in the OWASP Top 10 but was removed in 2017 due to enhanced browser defenses and the integration of CSRF protections in web frameworks.
In a CSRF attack, attackers deceive users into making unintended requests to a logged-in website. They might use phishing or embed malicious content in a web app. Without proper defenses, the targeted web app can’t differentiate between legitimate and malicious requests. The danger lies in any website potentially initiating these requests if the user is logged in. The impact varies: from unauthorized money transfers in banking apps to creating admin users or changing passwords, leading to account breaches. [4]
What is the solution now :( ?
Cross-site scripting (XSS) can bypass CSRF protections. When an application is compromised by XSS, any malicious scripts run as if it is a part of the website. As a result, these scripts can access hidden form fields and automatically include cookies in their requests. As a result, CSRF protections are ineffective against them.
Types of CSRF:
- Get-based CSRF (Make the request to the server via GET)
- Post-based CSRF (Make the request to the server via POST)
Prevention:
- 1. Token Synchronization
- 2. Double-Submitting Cookies
- 3. Same-Site Cookies
- 4. Enabling User Interaction
- 5. Custom Headers for Requests
Blogs:
- https://medium.com/@zellwk/understanding-csrf-attacks-43f2c942ca43
- https://www.hahwul.com/2019/10/11/bypass-referer-check-logic-for-csrf/
Tools:
2. Exploiting CORS
If a website has weak CORS, then it will be easy to do CSRF attacks. [5]
- Reflected Origins
When testing for CORS misconfigurations, set the Origin header in the request to a mock domain, like https://attackersdomain.com. If the response’s Access-Control-Allow-Origin header mirrors the domain you provided, it indicates a lack of origin filtering.
This misconfiguration becomes especially risky if the domain accepts credentials in requests. Confirm this by seeing if the response includes the Access-Control-Allow-Credentials header set to true.
- Modified Origins
Modify the Origin header to resemble the target domain by adding a prefix or suffix. This checks if the domain validates the entire string or just parts of it.
If there’s no thorough validation, attackers can craft domains that skirt the CORS policy of the target. For instance, for the domain metrics.com, potential bypass domains could be attackmetrics.com or metrics.com.attack.com.
- Null Origin
Set the Origin header to the null value — Origin: null, and see if the application sets the Access-Control-Allow-Origin header to null. If it does, it means that null origins are whitelisted.
Prevention:
For effective CORS implementation:
1. Create a whitelist for the Access-Control-Allow-Origin header, listing specific domains (like your organization’s domains) permitted to access resources.
2. When a domain seeks access, have your application cross-check against this whitelist.
3. Avoid setting the Access-Control-Allow-Origin header to NULL. Attackers can exploit this by sending requests with a NULL origin, potentially sidestepping other security measures.
Blogs:
- https://medium.com/swlh/exploiting-cors-misconfiguration-vulnerabilities-2a16b5b979
- https://portswigger.net/web-security/cors
Tools:
References:
2. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
3. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
4. https://reflectoring.io/complete-guide-to-csrf/
5. https://www.freecodecamp.org/news/exploiting-cors-guide-to-pentesting/