sleeyax / burp-awesome-tls

Burp extension to evade TLS fingerprinting. Bypass WAF, spoof any browser.
GNU General Public License v3.0
992 stars 66 forks source link

Add response header order #19

Closed AlecHaring closed 1 year ago

AlecHaring commented 1 year ago

If you compare the response header order of a request with and without the extension enabled, you'll notice it's different.

GET http://httpbin.org/get with extension:

Screen Shot 2022-09-25 at 9 45 06 PM

GET http://httpbin.org/get without extension:

Screen Shot 2022-09-25 at 9 45 14 PM
AlecHaring commented 1 year ago

Header stores the headers in a map, which doesn't preserve order. So we can't trust the order of res.Header, nor can we use the current method of transferring the response headers to the Burp response (Header().Add).

sleeyax commented 1 year ago

Thank you for opening a issue. Initially, I only aimed for the request headers to have the correct order because those can be prone to fingerprinting/censorship whereas response headers are only relevant for the developer/security researcher using Burp.

To support response headers order, I think you need to dig deeper into the net/http source code and find the code that writes the response header bytes into the header map. You can probably re-use the HeaderOrderKey to store the order.

I'd happily accept a PR for this.

AlecHaring commented 1 year ago

Yeah, I suspected that was the case. Definitely not as important as the request header order, as you said. It was just something I noticed, and I thought I should report it.

I noticed you have a copy of net/http in this repo with some patches. If needed, would you accept a PR that makes changes to that, or would you prefer a method that avoids changes to the net/http source?

sleeyax commented 1 year ago

I noticed you have a copy of net/http in this repo with some patches. If needed, would you accept a PR that makes changes to that, or would you prefer a method that avoids changes to the net/http source?

If those changes are needed for a feature/fix you are adding then sure, go ahead.

sleeyax commented 1 year ago

Marked as wontfix because I don't plan to work on this myself any time soon.