Be careful what you request for

HTTP Verbs

Did you know that the HTTP verb in a request can be arbitrary? GET, POST, and their compatriots are so commonplace it's easy to think those are the only verbs. However, the HTTP/1.1 specification in RFC2616 states there is support for custom verbs. Section 9 reads:

This means the HTTP verb can be manipulated, and, if you're not careful, might be an exploitation vector in your application.

OOPS HTTP/1.1

While scanning for cross-site scripting (XSS) in Django apps, I came across an app that handled GET and POST requests by checking request.method or otherwise returning HttpResponseBadRequest containing a message: "Method not supported: {}".format(request.method)". That seems like a perfectly reasonable thing to do, right? I came really close to calling this a false positive and moving on. I assumed request.method was a well-defined set. As it turns out, request.method can be much more, and this is actually an XSS vulnerability.

If we start up a Django app with a view like this, we can start throwing crafted HTTP requests at it using netcat.

1@csrf_exempt # Do this for demonstration purposes.
2def vote(request, question_id):
3    if request.method != "GET" and request.method != "POST":
4        return HttpResponseBadRequest(
5            "This view can not handle method {0}\n".format(request.method), status=405
6        )
7    ...

The protocol parser for HTTP recognizes the first sequence of characters prior to a space as the HTTP verb. This means our payload cannot contain spaces. Further, request.method transforms all text to uppercase. This rules out most JavaScript; the tried-and-true <script>alert(1)</script> becomes <SCRIPT>ALERT(1)</SCRIPT>, and ALERT(...) is not a valid function. Our payload therefore is subject to the following restrictions:

1. The payload cannot contain spaces.

2. The payload must be understood by the browser when transformed to uppercase.

I found this GitHub page where a friendly neighborhood hacker left behind some slick payloads. The first payload in the list, <A/hREf="j%0aavas%09cript%0a:%09con%0afirm%0d``">z, indicates that browsers will "fix" the slash. Since I also knew an inline script would be difficult due to capitalization, I decided to go with a social engineering trick:

1<A/HREF="HTTPS://GOOGLE.COM">BACK</A>

I'm sure there are other clever payloads that could successfully exploit under these conditions, but I was satisfied with this result!

Now, is this really dangerous? ...Well, it depends. An attacker would have to use XMLHttpRequests or the Fetch API to pull this off in a browser, and browsers are pretty good about forbidding weird characters in HTTP verbs. However, that doesn't mean it's impossible to exploit--there are some really clever hackers out there--so it's better not to reflect request.method.

You can scan your code for this pattern using Semgrep using a set of rules we wrote to detect this and many other security problems in Django.

1$ semgrep --config=https://semgrep.dev/c/r/python.django.security.injection
2scanning code...
3polls/views.py
4WARNING rule:python.django.security.injection.reflected-data-httpresponsebadrequest.reflected-data-httpresponsebadrequest: Found request data reflected into HttpResponseBadRequest. This could be vulnerable to XSS. Ensure the request data is properly escaped or sanitzed.
538:        return HttpResponseBadRequest(
639:            "This view can not handle method {0}\n".format(request.method), status=405

In fact, the rule for this is relatively easy to write in just a few lines. Semgrep makes it easy to write simple rules for detecting complex patterns. You can check out this rule in action at semgrep.live.

1- pattern-either:
2    - pattern: django.http.HttpResponseBadRequest(..., <... request.$W ...>, ...)
3    - pattern: |
4        $DATA = request.$W
5        ...
6        django.http.HttpResponseBadRequest(..., <... $DATA ...>, ...)

Check out more of our Semgrep rules at semgrep.live, or consider contributing your own!