User:Secure Cyberspace/Same-origin policy
Lead Section Change (first paragraph - added abbreviation description and link before use)
[edit]In computing-mobile, the same-origin policy (SOP) is a concept in the web-app application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model (DOM).
Attacks Section Changes
[edit]Edits:
- Added a citation for further reading on cross-site leaks: https://xsleaks.dev/
- Added a citation for WebRTC IP address sharing from the official specification
- Added info and a citation about browsers sharing cookies between sites on the same origin with different port numbers
- Added info about the Cross-Origin Resource Policy (CORP), which doesn't yet have a Wikipedia page. The topic is small enough to be contained in the SOP article.
- Added links to WebRTC and JavaScript
- Fixed a grammar error ("...to infer information
aboutcross-origin" => "...to infer information cross-origin") - (11/10/24) Added a short section on CSRF that links to the main article
Full section text:
Reading Information
[edit]Even when same-origin policy is in effect (without being relaxed by Cross-Origin Resource Sharing), certain cross-origin attacks can be performed. WebRTC can be used to find out the internal IP address of a victim[1]. If attempting to connect to a cross-origin port, responses cannot be read in face of same-origin policy, but a JavaScript can still make inferences on whether the port is open or closed by checking if the onload/onerror event fires, or if we get a timeout. This gives opportunities for cross-origin portscanning.
Further, JavaScript snippets can use techniques like cross-site leaks[2] to exploit long-standing information leakages in the browser to infer information cross-origin. These attacks can be counteracted by implementing a Cross-Origin Resource Policy (CORP) header, which allows a website owner to block cross-origin or cross-site resources, like images, videos, and stylesheets. CORP can also block JavaScript-initiated fetch
requests, but only if they are sent with the no-cors
[3] request mode.[4]
Writing Information (CSRF)
[edit]The same-origin policy does not prevent the browser from making GET, OPTIONS, and TRACE requests; it only prevents the responses from being read by user code. Therefore, if an endpoint uses a one of these "safe" request methods to write information or perform an action on a user's behalf, it can be exploited by attackers.
Leaking Information via Cookies
[edit]Note that the Same-Origin Policy does not apply to cookies for historical reasons[5]. If multiple adversarial sites are deployed on the same hostname with different port numbers, contrary to the SOP, all cookies set by any of the sites are shared. This can be used to leak users' session tokens and steal account information. Therefore, web services should be separated by differentiating subdomains rather than port numbers.
- ^ "WebRTC: Real-Time Communication in Browsers". World Wide Web Consortium. Retrieved 2024-08-27.
{{cite web}}
: CS1 maint: url-status (link) - ^ "Introduction". XS-Leaks Wiki. Retrieved 2024-10-27.
- ^ "Fetch Standard". fetch.spec.whatwg.org. Retrieved 2024-10-27.
- ^ "Cross-Origin Resource Policy (CORP) implementation - Security on the web | MDN". developer.mozilla.org. 2024-08-07. Retrieved 2024-10-27.
- ^ Barth, Adam (2011-04-27). HTTP State Management Mechanism (Report). Internet Engineering Task Force.