56

Plaintext injection is an issue. Say you have a page template that looks like this: Hi <name>, Blah blah blah. And you can inject from the URL. An attacker can construct an email with a link to www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+requires+that+you+use+version+vul.ne.rabl.e.%0D%0A%...


47

I'll start my answer by saying that many people misunderstand the Same Origin Policy and what CORS brings to the table. Some of the up-voted answers already here are stating that the Same Origin Policy prevents cross-site requests, and therefore prevents CSRF. This is not the case. All the SOP does is prevent the response from being read by another domain (...


44

Cross site scripting is not a threat to the integrity of your web server. Rather, the problem is that an attacker can craft a site.com URL that will execute arbitrary JavaScript. If your users trust your site and allow it to do whatever it wants, this could be a major security hole.


33

TL;DR: How does CORS prevent XSS? It does not. It is not meant to do so. CORS is intended to allow resource hosts (any service that makes its data available via HTTP) to restrict which websites may access that data. Example: You are hosting a website that shows traffic data and you are using AJAX requests on your website. If SOP and CORS were not there, ...


23

Imagine if the injected text was: "></script><script>alert("hi");" which would make it look like this: <script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script> Then, you have a working custom script that can do anything it wants in the page.


15

Cross-Site-Scripting (XSS) is the execution of attacker defined script code in the context of another site. CORS does not prevent XSS, in fact it is unrelated to XSS. Instead CORS offers a way to weaken existing restrictions on Ajax requests (i.e. XMLHTTPRequest) in a way which hopefully does not introduce more security problems. Traditionally ...


12

You're mixing things up. CORS is not meant to protect your application from crafted http requests, it's meant to protect you from a certain kind of attacks that "steals" the user's cookies or access tokens, by checking what sites can access your resource. It's mostly used to protect your server/application from cross-site request forgery, where a malicious ...


11

I'm Ysrael and I'm the researcher that found this vulnerability. Let's divide your question into 2 parts: A. How did the Origin of the browser become null? B. How the null Origin affect Facebook servers? Let's start with A. The Origin is part of the CORS mechanism and it is intended to tell the server where the request comes from. When the server gets the ...


7

This crossdomain.xml policy file revokes all protection that the Same Origin Policy provides. I use the crossdomain proof of concept tool, which has a simple interface to test SOP bypasses.


6

It all comes down to the old adage: "Good IT security is hard". While none of the concerns are known by us here to be fatal (we can't know your whole business and client model), they do raise serious doubts or at least things to really think hard about, and are worth taking soberly. Flip it round and look at your users' perspective. You are asking your ...


6

Web developers can integrate Google Sign-In with their website. Google Sign-In manages the OAuth 2.0 flow and token lifecycle, simplifying your integration with Google APIs. A user always has the option to revoke access to an application at any time. Websites can access information such as your name or email when you login. There are many ways to ...


6

They do that via an iframe with one of Google's beta features which is currently closed. You can see the iframe in the following screenshot of Medium's website. However, this does not mean Medium will be able to access your user information. The content inside of the iframe is sandboxed and can only be accessed if Google adds a same origin policy ...


5

Yes, all your assumptions are correct there. As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable. For example, addthis.com may suddenly decide they want ...


5

If code is served by a large Content Delivery Network (CDN), like Google's CDN, then it is more than likely that you will be hacked through other means. Large CDNs have a lot of money to spend on security, and a CDN is unlikely to be a weak point in your own infrastructure. Once a site hits a certain level of popularity, then it needs to serve static ...


5

I'm a bit confused about your vernacular. But I'll try. I believe you are using the word "session" to refer to single sign-on (SSO). This is functionality that allows you to sign into one site and have that sign-on propagated to other sites without requiring re-authentication. There are several standards for this. They include OAuth1, SAML, and OpenID ...


4

To answer the question: Yes a website can make an HTTP request to localhost. It will not break cross domain policy, because the request will not cross domains. It will stay local. One way to avoid cross domain policies, is to get the target victim to make the HTTP request themselves. Thus the request never crosses domains. To help you understand the ...


4

The main idea behind the content-type restriction is that XMLHttpRequest with CORS should not weaken the default security compared to what already can be done within the traditional security model. The traditional security model allowed the following cross-origin requests: Simple GET requests created by the browser. That is no payload and thus also no ...


4

It seems to me this OpenID Connect scheme should do it. Note though that I'm not a security expert, so don't use it without further confirmation. User is unlogged to a.com, b.com, sso.com. User goes to a.com, clicks "Login". Redirect to sso.com, with return URL on a.com as param. User provides valid credentials. sso.com accepts them, redirects to a.com with ...


3

Same Origin Policy ensures that you cannot read or modify the content of a page with different origin. In case of the iframe this means that the parent frame can fully replace the iframe (and thus changing the origin) but it cannot read or modify the contents of the iframe has a different origin. Thus reading a cookie cross-origin from an iframe will only ...


3

Yes, it is a security issue. The included JavaScript runs in the context of your website, which means that it has control over anything that you would have control over. External JavaScript files can harm you by among other: read cookies (eg to steal sessions) read user input (eg to read password inputs) change what the user sees (eg to display ads, ...


3

If origin was spoofed in this context, this would be down to a flaw in the particular browser that had been exploited. There have been such flaws in the past, such as this one on Safari. So assuming the user is using a fully patched browser and no zero day flaws exist (!) then your method of verifying the origin cannot be spoofed within the browser when ...


3

Depends how you set it up. If you allow Cross Origin Requests from any domain, then an attacker who finds the image URLs can do anything you can do within your Javascript application - the security is exactly the same as what you have. If you restrict the requests to your specific application server, they shouldn't be able to do anything, just as you can't ...


3

Your browser will add the HTTP Referer header (which, in a sense, indicates the "originating" URL) to most resource requests originating from a web page (exceptions include loading HTTP content from an HTTPS website, and refreshes). Thus, the simplest way to automate testing is to crawl/spider/monkey your web application and log all requests to other ...


3

It's possible to exploit Access-Control-Allow-Origin: null because resources loaded over things like data URI's and sandboxed iframes use the null origin. A PDF documenting the exploit confirms that Originull used a data URI document to exploit this header to achieve cross-origin access. For this reason, the W3C recommends avoiding returning this value for ...


3

Actually, they don't even have to inject JavaScript into the main page. Extensions can require permissions to make Cross-Origin requests to certain websites, see https://developer.chrome.com/extensions/xhr. They can even use the <all_urls> permission to get Cross-Origin access for all websites. This is not a security vulnerability, as you have to ...


3

A preflight request to check for CORS headers is only done if the request done with XHR could not be achieved without XHR. In your case you are just doing a simple GET request with no special headers which could be done also by including an image with the same URL or similar. Thus the request does not need to be preflighted. For more details which request ...


3

The --disable-web-security flag will prevent Chromium from enforcing the same-origin policy (SOP), which will allow you to read the response of your cross-origin POST request. However, do note that the POST request is always sent, regardless of same-origin policy. Anything that takes place on the server for that request will still happen (creating a ...


3

(Disclaimer: I work for Automattic) The OP is right to be concerned, because there is something wrong here. But, it's not nearly as bad as it appears on the surface. WordPress.com is a WordPress Multisite network, so digest.bps.org.uk is not a separate site from wordpress.com, it's just an alias. It's the exact same server/codebase/database serving both ...


3

If some server backend for the app is sending the requests As I understand it, the requests that fetch data from your website are comming from a server that works as a backend for the offending Android app. You have a number of possibilities: Block the IP of the server. This may end up being a cat and mouse game if they change the IP, so not the greatest ...


Only top voted, non community-wiki answers of a minimum length are eligible