I was watching a tutorial and the tutor put a XSS filter on a GET request only app.

My understanding of cross site scripting is using POST and GET. A “hacker” POSTs a script to the server and when your Web app makes a GET request it receives that script and the browser runs it when the script data loads onto the page.

This can effect all users viewing the page where the data (script) is recieved.

How would you be vulnerable if you had and only had a GET request web app?

I was watching a tutorial and the tutor put a XSS filter on a GET request only app.

My understanding of cross site scripting is using POST and GET. A “hacker” POSTs a script to the server and when your Web app makes a GET request it receives that script and the browser runs it when the script data loads onto the page.

This can effect all users viewing the page where the data (script) is recieved.

How would you be vulnerable if you had and only had a GET request web app?

• javascript
• security
• xss

• 3 It could be done over any http verb, over websockets, pretty much any munication that can be used to send data such that it is viewed by another user without being properly sanitized. – Kevin B Commented Nov 22, 2017 at 21:54

1 Answer 1

You seem to be under several misapprehensions here.

Only POST requests can cause a server to store data — false.

While the HTTP specification requires that GET requests are Safe and Idempotent, it is easy to write server-side code which violates this rule.

Only GET requests can get data from a server — false.

Most HTTP requests can have a response which includes a body for the client to render.

While it is often a good idea to use the Post-Redirect-Get pattern, this is not required, nor always the best approach. A POST request can have a response which is rendered in the browser.

Data needs to be stored to cause an XSS vulnerability — false

Many XSS attacks are of the Reflected form, where the input is directly echoed out in the response.

Let's take a naïve implement of a search engine like Google for example.

When you perform a search, the search term is displayed in an input element at the top of the page so you can modify it and make a new search.

<input name="q" value="<?php echo $_GET['q'];">

Now let's craft an XSS attack as a search string.

http://example./?q="><script>alert("XSS");</script>

That gets rendered on the page as:

<input name="q" value=""><script>alert("XSS");</script>">

… and vulnerability is obvious.