Plaintext injection is an issue. Say you have a page template that looks like this:
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%...
JSONP is a bit dodgy, from a security perspective:
Requires excessive trust. Suppose you have a page hosted on a.com and it uses JSONP to access services provided by b.org. This involves placing 100% trust in b.org. If b.org is malicious or buggy, it can subvert the security of the embedding page and all of the a.com origin. This kind of excess trust is ...
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 ...
Imagine if the injected text was:
which would make it look like this:
Then, you have a working custom script that can do anything it wants in the page.
As well as via a cross-domain AJAX request with credentials, the POST in your example could also be sent by using a standard form without AJAX:
<form method="post" action="http://MyApp/Page" name="hiddenFormInIframe">
<input type="hidden" name="my" value="a" />
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 ...
The callback parameter may be an XSS vector
I found an answer on stackoverflow that filters the JSONP callback response. This is needed because the callback parameter can be manipulated into a XSS attack that steals CSRF tokens like this:
The PUT HTTP verb is supposed to be idempotent, a smart word meaning that sending twice the request should not have any further effect. The idea is that a "PUT" command is the opposite of "GET": the data contents sent with a "PUT" are supposed to be stored at the specified URL, and may conceptually be obtained back from that same URL with a "GET". In that ...
To prevent CSRF you need to have something unguessable in the explicit part of the request (GET or POST). Putting it into the POST part is preferred, since it's harder to leak it, and you typically only protect requests that trigger an action, which should be POST.
A per-session random value is unguessable and should do the job. The standard anti CSRF token ...
So there are a few reasons why you don't want to do this, although I do not understand the code you presented as I do not deal with that. You should use a third party library to manage your sessions. There are several reasons...
Code is vetted, tested and improved across a much wider audience when you use a built in or well know authentication scheme.
Im surprised nobody has pointed out that the accepted answer (by meltdownmonk) is wrong.
"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."
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 ...
You should use POST for any state-changing action. If you save the content of the form, or use the form to send an e-mail, you should use a POST.
There are several reasons why this is more secure:
CSRF is easier with GET requests than with POST requests. With GET requests you can simply send someone a link. With a POST request an attacker needs to have a ...
They are both equally secure. There are mistakes you could make in any version, but none is inherently better than the other.
What is relevant for the security of your login is the server side. You can put no security restrictions on the client, since any such restrictions could be trivially bypassed. So the important thing here is the code on the server ...
From what I understand using GET to submit usernames/passwords is a security issue because the username/password are part of the URL which can show up in browser history.
That's not the only issue. Using GET for situations where the user is submitting data opens up your application to CSRF vulnerabilities.
For example, I could embed <img src="http://...
OAuth is flexible, and sometimes the OAuth flow is modified for application specific needs. The most common two flows are 2-legged and 3-legged, which if these flows are implemented correctly, then they are generally accepted as secure.
The proposed CORS AJAX implementation of the OAuth flow violates two security requirements of RFC-6749 - OAuth 2.0 ...
The same-origin policy is a client-enforced restriction. Certainly, it's possible for a particular client to fail to enforce this restriction. Note that doing so would bring the client out of compliance with W3C standards for the XMLHttpRequest API and iframe behavior.
Note that any program that can formulate an HTTP request can send a request to your site. ...
If you want the user to issue the request, then it is not possible to do this with an XMLHttpRequest:
Terminate these steps if header is a case-insensitive match for one of the following headers:
Same Origin Policy (SOP) preserves the data of other domains...
There are two parts to the SOP:
It prevents scripts on origin A from reading data from origin B.
It prevents sites on origin A from sending anything but so called "simple" requests to origin B. Simple requests are limited to GET and POST, and only a few headers can be modified.
Yes, you could do this. This should be fine. It is a reasonable defense against CSRF.
Do make sure that side-effecting actions can only happen via POSTs (never via GET), and that all POSTs check for the presence of the token. Also, make sure you generate the token as a cryptographically-strong pseudorandom number (e.g., using CryptGenRandom(), /dev/...
Encode unsafe characters in the response (how do I do this? using \uxxxx?)
Yes. < to \u003C in particular.
There may be an option in your JSON encoder to do this already (eg in PHP, JSON_HEX_TAG); otherwise, it's a simple job to do a string replace after the encoding. (This is safe as there is no place a < may legally be used in JSON other than in a ...
I'm not sure if browsershots will handle this - since it seems to be mainly focused on looks, rather than behaviour.
An XHR response, if it issues a "Set-Cookie" header, it will be included in further requests. From http://www.w3.org/TR/XMLHttpRequest:
If the user agent supports HTTP State Management it should persist, discard
and send cookies (as ...
The following links may provide you with an in-depth answer:
REST security standards
I just send username and password over https. Is this ok?
Please keep in mind that it is better to not use the username-password combination in every request that you make. Better is to authenticate the ...
CSRF would still be possible if you are using HTTP Basic or HTTP Digest authentication. The reason is that browsers implement those protocols "natively", meaning the browser will automatically insert the credentials with every request going to a particular domain.
If you are using some other form of authentication without cookies, then CSRF isn't possible.