-
You're confusing vanilla Ajax calls with REST calls.
Vanilla Ajax calls use GET or POST and it is completely up to you how to handle them.
REST uses the verbs GET, HEAD, POST, PUT, DELETE
HTTP VERB REST/CRUD
POST Create
GET Read
PUT Update, Create
DELETE Delete
You want to use POST over GET when you are worried about CSRF, not XSS.
A good rule of thumb is always use POST and only use GET if you are absolutely sure you want to share that data with other sites or the data is not sensitive.
But just using POST alone won't protect you 100%.
Both XSS and CSRF are very important and you should review your app for both, but they are two very different beasts.
CSRF :
Wikipedia
OWASP
XSS:
OWASP
-
I think you're misunderstanding REST. The point isn't to prefer GET over POST, the point is to use GET where the request doesn't affect the data on the server, and POST where data is modified. REST is all about properly using the HTTP verbs available.
For example, a search form will often use GET, while a Create X form will usually use POST.
-
Since when did REST imply using GET for everything? Last I checked, it meant the exact opposite. Use GET requests for getting a resource, and POST for posting one to the server.
One of the key points of REST is to use the HTTP requests that best maps to the operation you're trying to do. GET should be used for what it is intended for: Getting data from the server, without changing state on the server. It should not be used to update resources on the server. POST or PUT are designed for that.
Using HTTP the way it was intended to be used both helps avoid some (but far from all) XSS attacks, it also makes browsers behave a lot nicer when communicating with your site. The browser expects that GET requests can be safely repeated, without requiring confirmation from the user. That's what it does if you refresh the page, for example, or use the back/forward buttons. POST is expected to change state on the server, so the browser typically asks for confirmation before repeating a POST request.
-
Anyone can set up a simple html form and 'POST' data to your webservice via their browser and the local html file.
Restricting to POST will stop simple xss but if they can get a javascript running it won't really change much.
From my experience GET is mainly used for 'getting' stuff from the server, post is used for 'posting stuff' to the server.
GET's Have the ability to be bookmarked simply and clearly.
POST's can hold much more data due to not being restricted by the max url length which you should be trying to keep small.
-
There are situations when you should use POST rather than GET, but avoiding XSS isn't one of them. Perhaps you're thinking of XSRF, but even then, requiring POST doesn't really protect you. And in fact, REST advocates would actually say that you shouldn't just use GET but that you should use POST, PUT and DELETE for the corresponding "CRUD" operations.
To avoid XSS, escape and/or scrub content from users appropriately.
To avoid XSRF, require secret tokens on any side-effect causing operation that is potentially dangerous. (BTW: it's a good idea to avoid using GET requests when passing secret tokens as this could result in them leaking in referrers.)
Use GET for read-only requests whenever possible. (pretty much whenever the query can fit in a URL)
Use POST (or PUT or DELETE, if feasible and appropriate) for write requests.
-
XSS won't be stopped; XSS is when a user gets you to somehow output their script to other users. That requires filtering.
XSRF won't be stopped either; it requires adding one-time-tokens of some sort, to ensure that someone can only hit your site if they're actually on it (rather than posting from an embedded iframe or the like).
However, POST vs GET does prevent web accelerators and scrapers (eg Google Bot) from modifying your site. They only go to GET links, and thus if you don't want to have your site deleted (a la Daily WTF posts on this), make sure that 'delete this item' isn't a GET. ;-)
More usually, it's a matter of semantics and form size. GET does not post a form, thus is limited to whatever you can put in a URL, which is not much. POST allows arbitrary amounts of data. PUT and DELETE are more there for semantics; they can both be done via POST too.
-
The already-given answers really do answer your question - no, prevention of XSS is not a valid reason to prefer POST over GET. However, if you want a demonstration of this, check out tools like WebScarab or Tamper Data, which are very useful for testing your own site's vulnerabilities. It's just as easy to inject code into a POST request as into a GET. Even without these tools, though, note that unless you're checking for POST vs. GET server-side, it's easy to simply send parms using a GET. Simply add, e.g., ?parm1=value1&parm2=value2&etc to the URL.
