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%...


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.


42

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 (...


32

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.


5

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 ...


5

I didn't read all the details you wrote, I just want to make a general observation: you're planning on re-implementing part of an existing standard. Most likely, in a few months you'll realize you need another feature and you'll have to re-implement some more of that standard. Unless you're a genius cryptographer with a dedicated team of reviewers, there's a ...


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 ...


5

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 ...


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

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 ...


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 ...


4

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 ...


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

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

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

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

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 ...


2

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 ...


2

There is an attack that uses this exact attack vector, called Rosetta Flash (CVE-2014-4671). As explained on the Rosetta Flash page, the vulnerability is that: With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. This is why allowing users to upload a SWF file on a ...


2

CORS works by determining if the request target responds with an Access-Control-Allow-Origin (ACAO) header. In this case, the request target is the performance probe. It does not matter whether the page is served with an ACAO header. From Wikipedia: Note that in the CORS architecture, the ACAO header is being set by the external web service (bar.com), ...


2

His point of contention was that it can bypass crossdomain policies if someone visits page with this in it: <script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script> Yes, he's right. But that doesn't seem to be a security hole, instead, it looks like a feature. This technique of circumventing the same-origin-policy is called ...


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