Blog
The empire of the World Wide Web was built on shaky foundations due to simple short-sightedness of what this technology would later evolve to become. Behind the web, the protocol that powers the majority of the web today is known as the HyperText Transfer Protocol (HTTP). In its early days, rudimentary browsers were able to parse HTML and rendered data for its users. Most of the data rendered were static; very few dynamic plugins or features were present. Fast forward to the modern web; people use browsers to connect to websites to check their emails, handle banking transactions, purchases, and process sensitive documents (e.g., immigration).
The Shortcomings of HTTP
There are two significant shortcomings of the HTTP protocol that one must understand.
First, HTTP is in plaintext; this essentially means everything transmitted across the wire is using common words and verbs. This poses a significant privacy concern when people begin to use web sites to perform more sensitive actions such as banking, logins, and messaging, all of this can be intercepted by someone nefarious sitting on the same network.
Second, HTTP has no concept of the “state” between connections. Take, for example, an online shopping platform. User Bob bought a bicycle for his birthday, and user Alice purchased a pair of Apple Airpods. The HTTP protocol has no way of differentiating between the two users., and a result, the HTTP cookie was invented in June 1994 by Louis J. Montulli II at Netscape Communications Corporation as a way for websites to track “state.”
Cookie Monster
On February 12, 1996, HTTP cookies received media wide attention and were discussed in two U.S. Federal Trade Commission hearings due to potential privacy concerns. At the time, users of websites were not informed of cookies, and they were accepted by default.
Modern browsers (Chrome, Firefox, Microsoft Edge) have become extremely helpful to the end-user, which will automatically send any matching cookies scoped to the same domain on every request. Beyond privacy concerns, this also raises some security concerns.
Imagine sensitive web applications such as banking and financial transactions are all tied back to a user’s session cookie. Failing to address the security of cookies would lead to monstrous problems for cookie security.
It’s All About the SOP
If any website, that a user visits, can load and execute code, the Internet would have been a very dangerous place. In the early inception of the World Wide Web, it was like this for some time. However, developers of web browsers recognize the danger of executing arbitrary code and instilled two main security boundaries.
The first security boundary browsers have in place is that JavaScript should never be allowed to access data on your host. ‘Operation Aurora’ is a case of when such a security boundary was broken. In the case of Operation Aurora, a zero-day Internet Explorer vulnerability that exploits a memory corruption flaw, allowed code to escape out of the browser and execute code on the host. Many high-profile companies such as Google, Akamai, Adobe, Yahoo, Symantec, and many more suffered losses and had intellectual property taken.
The second security boundary is that JavaScript should only be able to read and access data associated with the site from where it was loaded. This is called the same-origin policy (SOP). If such a policy were not to exist, any site that a user visits can load malicious JavaScript that may affect other tabs in your browser where you are logged in. Just to give an example, as soon as your browser makes a request to evil.com, without the SOP, the JavaScript on evil.com may be making a malicious request to transfer money from your CIBC bank account, or a request might be made to purchase a new television. Therefore, the SOP protects users by limiting what JavaScript can do on other tabs that you have simultaneously open and logged in to.
Bypassing the SOP
Critical web application vulnerabilities in the history of the Open Web Application Security Project (OWASP), listed Cross-site scripting, cross-site request forgery, and cross-origin resource sharing all have one thing in common. They are all either vulnerabilities or misconfigurations that end up bypassing the same-origin policy.
Cross-site scripting bypasses the same-origin policy because malicious JavaScript is injected in a valid HTTP request causing the code to run in the same origin. Since malicious JavaScript comes from within the origin, the browser will trust it and cannot do anything about it.
According to the same-origin policy, resources from another origin cannot write or modify that that belongs to another origin. The only exceptions to this rule are HTML requests and cookies. Cross-site request forgeries exploit these exceptions coupled with the browser’s helpfulness; it is on the server to verify whether or not these requests are legitimate.
Since the same-origin policy is exceptionally restrictive, browsers have a unique method to bypass this policy by setting special headers. While not classed as a vulnerability, misconfigurations of this nature may end up disabling SOP and allow an attacker to execute JavaScript on their origin, but have read and write access to another. Developers do this in their pre-production, user accepted testing state, but often leave the configurations the same when pushing to production.
Mitigations and How SOP can Help
When designing a security strategy for your web applications, one must rely on the SOP. Notice in most modern and security-aware banking applications, their login portals, and the security aspects of online banking are served on to different origins. If an application needs to allow untrusted input, always serve them from a different origin. Any content injection such as XSS discovered on authentication.td.com will not affect easyweb.td.com.
If the web application requires a user to send data, rely on JavaScript to generate and send forms as well as credentials and headers. This will allow the same-origin policy and cross-origin checking to be in effect. Ensure sensitive endpoints are protected with a whitelisting of origins, and methods. Wildcard origins should only be used when API or endpoint is truly public.
How We Can Help
The Packetlabs team is composed of highly trained and experienced web application penetration testers. Reach out today to have a discussion and learn more about how we can test your applications to ensure gaps are closed and how we can formulate a security strategy for your development processes.