Cross site Scripting in HTTP Method?

Question

Lately, I've noticed that many web server configurations reflect the method of an HTTP request sent with a non implemented method in the body of the server's response.

For example, A request sent with the method GETTT will be responded with a 501 "method not implemented" response code, while the body of the response announces that the method "GETTT" is not supported. From what I understand, this means that if the method sent to the web server is not properly validated it can be vulnerable to a reflected XSS attack.

My question is, how can an attacker take advantage of this type of situation to create a link that will cause an HTTP request to be issued with an arbitrary method containing XSS payload? In theory, jquery $ajax requests should be able to handle this type of issue, as also stated in the following discussion - https://stackoverflow.com/questions/20425594/sending-an-http-request-with-an-unordinary-method/

I was able to send these type of requests several months ago (In Internet Explorer), but for some reason, jquery $ajax does do the trick for me anymore.

I'm sure this is a solvable issue and just a matter of finding the right payload, does anyone have any suggestions?

Answer 1

Simple answer: Not exploitable

Although it maybe possible to inject script code using a malformed HTTP verb, this attack vector is missing the "cross-site" component which makes the vulnerability useful to an attacker. So, why would an injection like this be useless to an attacker?

Well first of all how does an attacker send a "cross-site" request? There are a couple of variants, but the most common is as follows.

<form id="CSRF" method="POST"  action="http://victim/search" >
<type=hidden name=search value="<script>alert(1)</script>">
</form>
<script>
document.getElementById("CSRF").submit()
</script>

The HTML above will automatically send a POST request when the victim renders the HTML. The page http://victim/search is reflecting the search POST request on the page, thus executing the XSS payload in the victim's browser in the context of http://victim/search regardless of where the request originated from.

It is possible to control some of the HTTP header using flash, so I wrote a flash exploit framework to leverage unusual CSRF/XSS. Unfortunately flash currently only permit the GET and POST verbs, PUT and DELETE where allowed at once upon a time, but no longer.