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?

  • Did you include the javascript library? Dec 30, 2013 at 7:59
  • Have you tried setting the "Method" attribute of a form to your XSS payload? I haven't tried it myself but i think it's worth a shot. It would defeat the purpose of XSS though i guess
    – user36467
    Dec 30, 2013 at 9:56
  • I did include the jquery library using script src=, and and HTML form only supports the GET and POST methods. any other method would result in the form being submitted using POST. Dec 30, 2013 at 11:44
  • I suppose most XHR implementations restrict valid HTTP methods to at least [what the HTTP specification allows, i. e., a token (one or more of !, #, $, %, &, ', *, +, -, ., 09, @, AZ, ^, `, _, az, and ~)](http://tools.ietf.org/html/rfc2616#section-5.1.1). But I think it’s even more restricted, like, to only uppercase AZ` and -.
    – Gumbo
    Dec 30, 2013 at 16:56
  • Erratum: Without @.
    – Gumbo
    Dec 30, 2013 at 17:19

1 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>">

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .