![]() Once a request is kettled, the message editor no longer attempts to display an HTTP/1 equivalent of it. There is no way to show this in HTTP/1 as a newline indicates the end of a header, so anything after it would just appear to be the start of the next header's name. In honor of our infamous Director of Research, James Kettle, we've coined the term "kettled" to describe such requests.įor example, it's technically possible to add a newline character inside a header value in HTTP/2. The Inspector enables you to create HTTP/2 requests that are impossible to accurately represent using HTTP/1 syntax without losing information. If you try to downgrade such a request, Burp warns you that the request will have to be normalized so that it can be displayed in the editor. Burp refers to this as a " kettled" request. When working in the Inspector, it's possible to create an HTTP/2 request that cannot be accurately represented using HTTP/1 syntax without losing information. If you want to try sending HTTP/2 requests anyway to test for hidden HTTP/2 support, you first need to enable the Allow HTTP/2 ALPN override option from the Repeater menu. ![]() ![]() This means you can easily upgrade and downgrade individual requests as needed.īy default, you can only upgrade requests to HTTP/2 if the server explicitly advertises support for this via ALPN during the TLS handshake. When you change the protocol, Burp performs the necessary transformations to generate an equivalent request in the correct format for the new protocol. To do this, use the toggle switch under Inspector > Request Attributes. Regardless of your default protocol settings, you can manually choose which protocol is used to send each request. For requests that you've intercepted in Burp Proxy or sent to Burp Repeater, you can toggle which protocol you want to use to send the request. In non-editable contexts, such as in the proxy history, the highlighted protocol is purely informational. In the Inspector, the Request Attributes section displays the protocol version. In Burp Repeater, the current protocol is displayed in the upper-right corner of the screen, next to the target host. This is standard for HTTP/1 messages, but also applies to the editor's representation of HTTP/2 messages. In the message editor, the request line and status line contain the protocol version. ![]() There are a number of places where this information is displayed: When testing for protocol-level vulnerabilities, it's important that you're aware of which protocol is being used for each request. Keeping track of which protocol you're using You can still send individual HTTP/2 requests by switching the protocol in the Inspector if necessary. This is useful if you're performing testing where it's necessary to always use HTTP/1. You can also tailor this behavior to suit your current needs by changing the default protocol for the project. This ensures that, even if you're not conducting any protocol-specific testing, you can still take advantage of the performance improvements provided by HTTP/2 where available. To help you get the most out of these features, we've provided a brief overview of the background concepts that are relevant.īy default, Burp speaks HTTP/2 to all servers that advertise support for it via ALPN during the TLS handshake. Under the hood, HTTP/2 is very different from HTTP/1. HTTP/2: The Sequel Is Always Worse Background concepts
0 Comments
Leave a Reply. |