Take Your XSS and POST It
- Nov 13, 2014
- Guest Author
Parameter injection is one of the most common classes of web application vulnerabilities exploited in the wild. This class of vulnerability implies that attackers inject known malicious strings into Hypertext Transfer Protocol (HTTP) request parameters in an attempt to cause unexpected application behavior. This class of vulnerability encompasses a large variety of attack methods including, but not limited to, cross-site scripting (XSS), SQL injection (SQLi), local file includes, and path traversal.
There are two variants of XSS, reflected and persistent. The two types of XSS differ only in the way the exploit is delivered to the victim. The initial attack vector for reflected and persistent XSS relies on a vulnerable web application echoing unsanitized end user input in the server response. However, in the case of persistent XSS the injected value is not lost when the page is refreshed, but rather persisted in a back end database where it can be delivered to victims continuously. As an example, assume that the comment section of your local newspaper’s web page was vulnerable to persistent XSS, and exploited by a malicious adversary. Each user that visits the page containing the poisoned comment would fall victim to the XSS attack. Reflected XSS on the other hand relies on a phishing component for successful exploitation. Essentially, the attacker identifies a vulnerable URL query (GET) parameter, crafts a malicious URL, and sends this URL to the intended victims.
In the case of reflected XSS, given that a URL must be sent to the target victim as part of a phishing campaign, web developers often overlook the risk of vulnerable POST parameters, or parameters present in the body of an HTTP requests (rather than in the URL as a GET parameter). There is simply no way to cut and paste a clickable link that contains POST parameters into an email. As a result, one would assume that the real world exploitation of POST parameter based reflected XSS is essentially impossible. How can you send a POST request in an email? You just can’t. This is all sound logic, but it is not entirely correct.
In other words, the risk of reflected XSS is equivalent regardless of how a vulnerable web application receives user-supplied input. Web developers should therefor treat all remediation efforts with the same level of urgency, regardless of whether a parameter is submitted via GET or POST requests.