How to conduct XSS via message body or HTTP cookie?

Question

I am reading Hackers Handbook and in one chapter it says: "Parameters submitted within the URL query string, message body, and HTTP cookies, are the most obvious entry points..."

I understand that the URL can provide e.g. a XSS. But can somebody explain how the message body and/or the HTTP cookie can be used as "User input" to conduct an e.g. XSS? Please provide an example of such "user input".

Answer 1

The main attack vector for reflected XSS is creating a request with embedded script code - usually JavaScript - which is then taken by the server and injected in the response sent back to the client. How the script code is sent to the server initially doesn't matter, as long as the server takes it and embeds it in the response.

It seems to me that you struggle with the following question: "How does the attacker trigger the victims browser to send such a request?"

1. In the URL. You mention that you understand this version, so we can work from there. The attacker crafts a URL that he send to his victim. This can be a simple link, that the victim clicks on, or some kind of redirect from another website. When the victim clicks the link, a GET request is sent with the payload, the server embeds it in the response, and the browser executes the malicious script.
2. In the message body. If you cannot use a GET request to perform XSS (because the server requires a POST request), you cannot provide the script code in the URL. You still use the same principle, but instead of putting the parameter in the URL, you put it in the message body. It's basically the same, but now you cannot craft a simple link with the payload. Instead you must trick the victims browser to send a POST request. An easy way for an attacker to do this is luring the victim to a website he controls. On this website, he uses e.g. JavaScript to create a form with auto-submit, which includes the payload as a POST parameter in the message body. When the website is visited, the browser executes the JavaScript code which sends the post request with the XSS payload to the vulnerable website - voila!
3. In a cookie. This seems tricky at first, because you cannot set a cookie for another domain in the victims browser. But that is already the solution to the problem - it does not work usually. What you need is a special use case, that allows you to set the vulnerable cookie through a mechanism in the website. Imagine a cookie that defines the language of the website. The website could implement a simple request that allows the user to store his language preferences in a cookie, allowing an arbitrary value. The server answers with a Set-Cookie response header containing this user defined value. This arbitrary language value is stored in the browser and sent as cookie with every future request. If the website is vulnerable to XSS, meaning it reflects the cookie value without sanitation, an attacker can craft an easy attack by forcing the browser of the victim to send two requests. The first one will store the cookie payload in the browser, the second one will be another request to the website, where the cookie gets reflected.

In the end, the concept of XSS stay the same in all three scenarios, only the attack vectors look slightly different. Providing specific user input, as you requested in your question, doesn't make sense though, because the payload is always the same. If you can do it with a GET parameter in the URL, you can do it with any other form of user input as well.