4

When I capture HTTP requests and responses with Burp suite, everything works fine except when I want to capture facebook.com responses, I get a strange response body which is in some unreadable format that is not HTML, but just some strange symbols (the response headers are ok and readable, but the body is not). Does anybody have an idea what could be the reason for that and if there is a fix? The burp cert is configured in my browser. And the response renders fine in my browser.

Edit:

The response headers (without some values for which I'm not sure if I should post them) are:

HTTP/1.1 200 OK
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
public-key-pins-report-only: 
Pragma: no-cache
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net *.atlassolutions.com blob: data:;style-src data: 'unsafe-inline' *;connect-src *.facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* *.akamaihd.net wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob:;
Cache-Control: private, no-cache, no-store, must-revalidate
Strict-Transport-Security: max-age=15552000; preload
Vary: Accept-Encoding
Content-Encoding: br
Content-Type: text/html
X-FB-Debug: 
Date: Mon, 05 Sep 2016 22:09:00 GMT
Connection: close

And the first few bytes of the response body in HEX look like this:

0a 07 30 0c 00 e4 af 9f ab fe f7 e7 cb 7a 7b 41
pineappleman
  • 2,279
  • 11
  • 21
  • 3
    Since you don't provide exactly what you see we cannot analyze it. But maybe you are looking at compressed data? Please provide at least the response header (without the real cookie values) and the first few bytes of the response body (as hex not "characters" so that one can have a look at the binary values). – Steffen Ullrich Sep 06 '16 at 04:37
  • Is it happening only with Facebook? Can you infer what kind of websites are giving you this kind of response? – one Sep 06 '16 at 06:33

1 Answers1

10

The response of the server reply is Brotli encoded:

Content-Encoding: br

I think that the Burp Suite doesn't decode this, so you're seeing the compressed version of your response.

For more information about Brotli you can look here.

Update:

Until the Burp Suite supports Brotli, you can override the Accept-Encoding-Header as a workaround. Go to Proxy -> Options -> Match and Replace. There is allready a template named "Require non-compressed responses" that you can simply activate: Require non-compressed responses

sven.to
  • 586
  • 3
  • 5
  • I'd like to add that Brotli is currently only supported in Google Chrome and Opera - using another browser should result in another compression. – Lukas Sep 06 '16 at 13:07
  • I used Mozilla User-Agent and still got that encoding. I would appreciate it if anybody has a solution how to easily decode that with Burp. If not, I would accept this answer. Thanks! – pineappleman Sep 06 '16 at 15:39
  • 1
    Firefox supports also [Brotli since version 44](https://www.mozilla.org/en-US/firefox/44.0/releasenotes/). I've added a workaround in my answer. – sven.to Sep 06 '16 at 18:02