I think you are very confused about what both CORS and SOP do... neither is relevant to these attacks at all.
There are lots of ways to bypass client-side validation. HTTP is just a stream of bytes, and in HTTP 1.x they're even human-readable text (at least for the headers). This makes it trivial to forge or manipulate requests. Here's a subset of ways to do ...
In theory your suggestion is perfectly reasonable. If browsers blocked all cross origin POST requests by default, and it required a CORS policy to unlock them, a lot of all the CSRF vulnerabilities out there would magically disappear. As a developer, you would only need to make sure to not change server state on GET requests. No tokens would be needed. That ...
What does that really mean? Can you please give me a real life example?
Attack example 1: Cross-Site Request Forgery (CSRF) with an HTML form
On page at evil.com the attacker has put:
<form method="post" action="http://bank.com/trasfer">
<input type="hidden" name="to" value="ciro">
It is perfectly fine if a http:// and a https:// resource provide different data, even if everything but the access method is the same. For example access to http:// will today often result in a redirect response while access to https:// provide the real content. A browser will therefore cache these resources independent from each other.
Review: Same-origin policy
First, let's clarify that the behavior observed here (the iframe does not render) is much stricter than the default same-origin policy. If you already understand that, skip down to "What's actually happening," below.
To review, the same-origin policy prevents scripts from having programmatic access to the contents of ...
The administrators of security.stackexchange.com have configured the site to not let it be framed on other sites. This is usually done to prevent clickjacking attacks, to prevent others from embedding security.stackexchange.com into a page full of ads, and to save traffic. You may read more about X-Frame-Options header here.
This protection is off by ...
Let us start by defining the term "origin". The origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://test.com and https://test.com have different origins as the protocol is different. Similarly http://one.test.com and http://two.test.com have different origins as the hostnames are different. The origin ...
If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario:
www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites.
www.privatesite.com - this is your external site, but instead of locking ...
And how can a web server distinguish between requests coming from a script and coming from a user?
It doesn't. The same origin policy is enforced by the browser, not the server.
The purpose of the Same Origin Policy (SOP) isn't to protect the server itself. Instead it's to protect confidential information which the server wishes to share with the user, but ...
The problem is not the request method: CSRF could also be done with a GET request. The problem is instead that authentication information like (session) cookies or the Authorization header are automatically included with the cross-site request, thus making CSRF possible. Therefore the mitigation would not be to prohibit such methods to be used within cross ...
Maybe a very short answer will help as well.
I never thought about it much, I just thought this meant someone could
bypass the validations by making a request on something like Postman.
But then I learned that with a same origin policy that's not possible.
The same-origin policy is something that browsers voluntarily implement to protect their users. It ...
The request can still be sent, just not read:
Cross-origin writes are typically allowed. Examples are links, redirects and form sumissions [sic].
Cross-origin reads are typically not allowed.
So only the reading of the response is protected by the Same Origin Policy, not the making of the request itself, although only certain headers can be used ...
If one enters a URL in the browser one starts with a new empty origin, i.e. no domain and port belong to the origin initially. Everything can be put into a window/tab with an empty origin and once it is put there the origin changes depending on where the data came from.
If one instead calls a HTTP request from inside a loaded web page, one starts with a non-...
The simple answer to your question is that "requests to display a web page" are what set the origin, so obviously they cannot violate same-origin policy. Things that happen within a page (such as JS execution and notably XHR/Fetch) are subject to various restrictions due to same-origin policy, but top-level navigation is always allowed*.
* Iframes ...
What initially bothered me with CORS policies was their indiscriminate application regardless of resource/type, I feel that sentiment resonates with your question quite well. W3 spec actually advises that:
A resource that is publicly accessible, with no access control checks,
can always safely return an Access-Control-Allow-Origin header whose
It seems to me you're discussing two things: sandboxing on the desktop and then strategies for user content access in sandboxed applications.
There are many sandboxing models out there, including the ones used by OSes:
Windows 8 WinRT Store Apps
OS X Sandboxed Store Apps
Some apps are shipped sandboxed, for instance ...
This is one of the most fundamental principles of web security and goes way beyond CSRF protection. Without the same-origin policy, any website could read our e-mails through our webmailer, have a look at our PayPal account, get our private information from Facebook etc. So ...
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 ...
The goals of the SameSite flag are:
prevent cross-site timing attacks (see eg here)
prevent cross-site script inclusion (see here)
prevent CSRF: SameSite cookies are only sent if the site the request originated from is in the same site as the target site (in strict mode for GET and POST, in lax mode only for POST requests).
limited privacy protection
I think the attack they are trying to protect against is the following.
Imagine santaclause.com serves an image at santaclause.com/naughty_or_nice.png to logged in users. The image is a green checkmark if the logged in user has been nice, and a red X if they have been naughty. Mallory wants to know if Alice has been nice or not. So on evil.com ...
Postman and same origin policy aren't obstacles. To understand this, I need to explain why, as a developer, you virtually never trust the client/front end.
Front and back end trust
If someone controls a computer, they control what it sends the server. That's literal: every last byte of it, every last header or request, every last POST field in a form or GET ...
What exactly would that image request URL look like?
It need not be anything complicated or abnormal. There are two main ways this could work (were it not for the restrictions in the browser):
In the first, there is a specific URL for the profile image of the current user, say http://mydatingsite.com/currentuser/profileimage.jpg. This might be an odd way ...
I partly disagree with Anders on
But that is not how the internet was built back in the day, and there
is no way to change it now.
The developers of major browsers do have pretty much power to change the Internet and guide web developers to the direction they want. Obsoleting cross-site POST data would be possible, if it was seen as a major threat. ...
Your backend is accessible via the network. That means I don't need to use your frontend. I can find out what endpoints it uses, and and what format the request looks like, and use my own tools to send requests that your frontend would never allow. You must never assume that a request hitting your backend actually originated from your own application. It ...
The actual answer should be, as always: it depends on your usage scenario.
The Strict value will prevent the cookie from being sent by the browser
to the target site in all cross-site browsing context, even when following a regular
link. For example, for a GitHub-like website this would mean that if a logged-in user
follows a link to a private GitHub ...
This is considered acceptable because scripts are limited in interacting with cross origin images unless crossorigin="anonymous" is set, which tells the browser not to send cookies or other credentials when retrieving the image. Without setting crossorigin="anonymous" scripts are allowed to retrieve dimensions, but not pixel data from the image due to the ...
The primary cache key for any standards-compliant browser is an absolute URI
The absolute URI begins http: for all insecure requests and https: for all secure requests
Consequently, a resource fetched securely can never use the same cache key as a resource fetched insecurely
The current standard for HTTP is split across multiple "RFC" documents, ...
Therefore, it doesn't matter if old browsers have certain behaviours or ...
Yes, you can use a custom header such as X-Requested-With to protect AJAX requests from CSRF.
A customer header is not allowed cross-domain without CORS being enabled on your server. The Origin header could also be used, however the logic for this is not straightforward.
If you wanted to add extra security to the custom header in the spirit of defence in ...