Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Websockets Missing Authentication Header

| Last updated: Oct 15, 2021 03:52AM UTC

I'm new to Burp Suite, so I may just not know how to do this, but it appears that my HTTP Request to establish a Websocket is missing the Authentication header. I'm using the Platform Authentication option, which seems to work for the basic application authentication, but then I never get a response from the request attempting to setup the Websocket. I have captured the traffic outside of Burp Suite with Fiddler and noticed that the Websocket request includes an Authorization header, but it's not included in Burp Suite. Please advise. Thanks

Michelle, PortSwigger Agent | Last updated: Oct 15, 2021 01:26PM UTC

Thanks for your message. Just to make sure we're picturing what you're looking at properly can you send over a couple of screenshots of the steps you're taking and what you see/expect to see to support@portswigger.net, please? Which version of Burp are you using? Are you viewing the requests in the Proxy History or the Logger tab? Are you wanting to add the Authorization header manually to all requests?

| Last updated: Oct 15, 2021 03:23PM UTC

I'm using v2021.8.4 and I'm viewing the requests in Proxy HTTP History. My original goal was to be able to test a Websockets based application, but with the missing Authorization header, the Websocket is not successfully established. I think the reason for the missing Authorization header is that I'm using the Platform Authentication option, but that appears to be the only way that I can successfully login to the application in general (without it, it just keeps prompting me for the user credentials). Does that make sense?

| Last updated: Oct 15, 2021 03:27PM UTC

A successful Websockets request (no Burp Suite) looks like this (redacted): GET https://[target] HTTP/1.1 Host: [target] Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Authorization: Negotiate [Authorization Data] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36 Upgrade: websocket Origin: https://[target] Sec-WebSocket-Version: 13 Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Cookie: [cookies] Sec-WebSocket-Key: [ws key] Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Where the Burp Suite version looks exactly the same, but it's missing the Authorization header.

Michelle, PortSwigger Agent | Last updated: Oct 18, 2021 12:08PM UTC

Thanks for the update, that makes sense. So we can look into this in more detail for you it would be good if you could email us the following: - Output from Help -> Diagnostics - Screenshots of User options -> Connections -> Platform Authentication (so we can see which options you've selected) - Whether the site you're seeing this with is publicly accessible - Whether there are other pages on the site (that do not need to upgrade the connection to use WebSockets) where the authentication works We can then use this information to dig into the issue in more detail and potentially see if we can replicate it here.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.