Bypassing SOP
view all blogs...

Justin Bess :: May 31, 2018

So, you need to bypass same origin policy…

Before we begin, if you find yourself asking what SOP (same origin policy) is, then this blog post is not for you. This blog post will cover some of the techniques that can be used to bypass the security standard, not what it is. Consider reading the following blog post where I explain the same origin policy, if you are unaware of SOP.

Server Settings

While, this isn’t necessarily bypassing SOP, I figured I would throw this in here, for some of those who have not looked closely enough into how CORS (cross origin resource sharing) operates. If you have escalated privileges on a system, or already have access to a system, that is running the server which hosts the code for the specific domain you are targeting, you can bypass the SOP by simply following standard CORS procedures. This is usually something done intentionally by developers who want to share access to their origin, but if someone with malicious intent gains control of the server, they could configure this standard as well.


I will quote directly from wikipedia, as I believe it has a great definition of CORS

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the first resource was served. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy.

CORS defines a way in which a browser and server can interact to determine whether or not it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests.

To work with CORS, you need to send anAccess-Control-Allow-Originheader from the server to the client. The value of this header can be a specific domain, such asAccess-Control-Allow-Origin:, or to simply allow all origins, you could use Access-Control-Allow-Origin: *If you intend on allowing multiple domains, but not all domains, I would advise a quick google search. Typically for this, you will have to do some server modification, adding server side code to manually handle origins, or modify a .htaccess file.

CORS Anywhere / Reverse Proxy

If the website you are trying to access is a public domain, accessible on the world wide web, then the CORS Anywhere approach may be a good fit for you to bypass the same origin policy of the domain.

You can find the CORS Anywhere documentation and source code on this Github repository. Essentially CORS Anywhere provides a proxy server for a client on it’s behalf. The proxy server will fetch the requested resource(s), and send that information back to the client with the appropriate CORS headers included. This allows for you to bypass the SOP, and the request can be fulfilled. There is a public facing application running CORS Anywhere, found on this Heroku deployment, listed on the Github.

Taken directly from the documentation, you should be able to use this exact approach, or a similar one in order to successfully bypass the SOP for a successful request

Chrome disable security

Admittedly, I have not ever used this approach, but I have found some trustworthy resources, explaining how this technique works. One of those things, is an internal wikipedia page provided by Amazon, however I will not cite anything specific from there, as it could breach my NDA contract.

I will link this Stack Overflow resource, which essentially demonstrates the same steps as I found on our internal wiki. The idea is to spawn a chromium instance with the following flags (if you can make those modifications on your system)

--disable-web-security --user-data-dir

Note that you can NOT have any other chrome instances running at the time of doing this, as the running version will overrule your desire to run the spawned instance without security. Whatever you do, never run this as a default setting on your browser. You should create a shortcut for this insecure instance, and use it only when you need to. If you set this for your default browser options, you run a great risk of pwning yourself by sheer stupidity. There are lots of malicious programs, which will prey on your poor choice to do such an ignorant thing. With that being said, when you run the insecure instance, only visit your trusted sites, and nothing further!

Browser Automation

So, I came across a rather niche problem, which took a lot of effort to finally come to a reasonable solution to bypass SOP. I needed to bypass SOP on an intranet domain, not publicly accessible. On top of this, the domain requires authentication from an SSO (single sign on) process. I did not have server access, and I had thrown all the other reasonable ways to bypass SOP at this domain to no avail. I was finally able to defeat this problem using browser automation.

The browser automation framework I used for this was Nightmare JS. You can essentially think of this framework and browser automation as a macro for your browser. The framework runs an electron instance, meaning you can pass in electron attributes to the window which spawn within Nightmare. This means passing in the option of show as false, such as: const nightmare = Nightmare({ show: false }) will render an invisible window, so the end user will not notice anything weird happening, while the data is fetched and scrapped. I’m choosing not to fully go in detail on how to use the framework, because that’s a whole other blog post in itself. However, use the following code snippet as a small example. The code would pull the entire DOM tree of, and you could then parse the data as you need.

If you only want specific things, or need to perform actions on the client behalf, take a look at the Nightmare documentation, and perform those actions with the framework. Afterwards, you should render out only the data you need.

Additional Techniques not covered, for your google pleasures


      December 11, 2018


      Nice posts! 🙂