0

As we all know that what is the SOP? As its very popular. But my question arises when, pentesting this functionality.

AS SOP provide the website to call the resources only from its domain. Ex. http: //example.com/ have the SOP functionality then Only resources can call from this (example.com) domain.

Now, How the attacker might get damage this? I think its very simple functionality. So i want to know about what vulnerabilities can arise here?.

It might be Out of scope but really i didn't find it on the google.

januu agrawal
  • 81
  • 2
  • 8

2 Answers2

1

As we all know that what is the SOP? As its very popular. But my question arises when, pentesting this functionality.

AS SOP provide the website to call the resources only from its domain. Ex. http: //example.com/ have the SOP functionality then Only resources can call from this (example.com) domain.

Before you go ahead and try to pentest, you need a more than vague understanding of how it works. Mozilla's MDN webdocs provide a very good starting point.

How the attacker might get damage this? I think its very simple functionality. So i want to know about what vulnerabilities can arise here?.

The same-origin policy (SOP) is a browser-level security control that dictates how a document or script belonging to one origin can interact with a resource from some other origin. Basically, SOP prevents scripts running under one origin from reading data from another origin. There may be cases where an app needs to allow other origins for resource access. This is achieved by using Cross Origin Resource Sharing. There can be potential security issues due to CORS mis-configurations. There are basically two ways in which CORS allows cross origin communications:

  1. Access Control Headers: For every cross domain request the resource server issues access control headers in response which indicate if the requested access can be provided. TO gain a full understanding of how and when these headers are used and how they are interpreted by the browsers, I point you back to the MDN references.

Recently the guys at PortSwigger came up with a blog post, highlighting vulnerabilities arising due to CORS mis-configurations.

  1. HTML5 postMessage API: The Window.postMessage() method, introduced in HTML5, allows JavaScript code running on different origins to communicate with each other in a bidirectional manner. e.g. This API can be used for communication between an iframe and its parent document.

This blog post highlights potential security issues in postMessage API implementations.

Recommended reads:

Why is the same origin policy so important?

How does CSRF correlate with Same Origin Policy

Community
  • 1
Shurmajee
  • 7,285
  • 5
  • 27
  • 59
  • Thanks for this awesome answering. You are absolutely right! and i also agreed (when you brings up the cors concept in the SOP). But suppose that the website using only the same origin Policy, no **CORS** is there. Now, how i should pentest/test the SOP functionality? – januu agrawal Oct 05 '17 at 14:12
  • @januuagrawal In that case there is nothing much to pentest. We are talking about a browser based security control here. SOP is not something controlled by the application developer. SOP will work the same way for your web app and say a popular app like Google.com. Hence the statement that "Website is using SOP", is incorrect. – Shurmajee Oct 06 '17 at 04:45
  • hello, yeah i got you are saying. But May i ask you something in cors query (a small one). If the website request a cross domain request then, how will request be treated? Is the web browser automatically use CORS? – januu agrawal Oct 08 '17 at 09:30
  • The references included in my answer have the information that you are looking for. It is one of those things which can not be summarized in a comment as there are too many ifs and buts involved. First, you have to understand how CORS works. Read the Mozilla documentation and the PortSwigger blog. No shortcuts here! – Shurmajee Oct 10 '17 at 07:13
0

To exploit web services with SOP enabled, the focus shifts from XSS to rogue user data uploads and exploiting vulnerabilities which provide the attacker a method to host/manipulate data hosted on the origin server domain itself.

A client-side approach would be to direct DNS/proxy requests for example.com to a rogue/malicious destination but this takes things to the network layer and isn't strictly a valid penetration of the web-service itself. For example network man-in-the-middle attacks or client-side trickery using something like a poisontap.

Hope this was the type of information you were looking for.

Fahad Yousuf
  • 251
  • 1
  • 4