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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.