Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burpsuite Professional fails to handle Blazor SignalR WebSocket traffic

Wiktor | Last updated: Apr 12, 2022 09:06AM UTC

Hello, During my work, i've stumbled across the web application project which uses the Blazor technology. Blazor is .NET framework that uses SignalR library. This leads to use of WebSocket protocol communication in every aspect of application, from authentication up to any keep-alive / basic functionality request. I've found that Burpsuite Professional could not handle WebSocket traffic in this peculiar setup - fallbacking to normal HTTP requests and creating half unreadeable requests which therefore are not handled properly and could not be tampered in normal way. Worth mentionting is the fact that browser itself (without Burpsuite in the middle) properly handles WS traffic - socket connected to the endpoint ID and sending frames (WS messages) properly. However with the Burpsuite as proxy server this fails and Burpsuite could not read this as WS but as normal HTTP traffic and as i aformentioned - this leads to request handling failure. I've thought this might be NTLM handling problem (application uses NTLMv2 authentication), however i've tested proxy server such as Fiddler and this software handles everything properly. I've also tried upstream proxy Burpsuite > Fiddler with Fiddler Script in place to handle NTLM properly (as i am doing this in daily tests), however this is not the case. It seems like Burpsuite has just problem to comprehend communication. In the outcome of this problem i can't properly make use of BurpSuite software for my penetrating testing project. I will write down my setup and any clues i've gathered: + I am using latest stable version of Burpsuite Professional 2022.3.3, + I've tested the issues with use of Chromium embbeded browser, Firefox, Edge, + This problem seems to be strictly exclusive to the Blazor SignalR Websocket, because other applications which uses WS works like charm. I can give any more information regarding this issue which (i hope) i will lead to fix this peculiar problem. Thanks in advance and cheers.

Liam, PortSwigger Agent | Last updated: Apr 12, 2022 10:03AM UTC

Thanks for this report, Wiktor. Is the application publicly accessible? If so, could we perform some remote testing?

Wiktor | Last updated: Apr 12, 2022 12:35PM UTC

Hello Liam, No, unfortunely this application is in closed environment and due to No Disclosure Agreement and other confidential / secret classification we cannot share the code itself. However application uses public libraries and components and stricte working environment can be created by setting the solution. This is the application setup i've got from developer, including server information itself: + Windows Server 2019, + IIS, + Blazor Server (https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-6.0). 1. SDK/Framework information: <Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.2"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> <PackageReference Include="Swashbuckle.AspNetCore" Version="6.2.3" /> </ItemGroup> </Project> 2. Web Application was created via VisualStudio template. Windows authentication was along with followings components and libraries: <Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <UseRazorSourceGenerator>false</UseRazorSourceGenerator> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Mvc.NewtonsoftJson" Version="5.0.11" /> <PackageReference Include="Radzen.Blazor" Version="3.12.5" /> <PackageReference Include="System.DirectoryServices" Version="6.0.0" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="6.0.0" /> </ItemGroup> </Project> If you need any more information regarding the issue, let me know. Best regards, Wiktor

Liam, PortSwigger Agent | Last updated: Apr 12, 2022 01:33PM UTC

Hi Wiktor. It looks like this requirement has been discussed in the following thread - https://forum.portswigger.net/thread/websocket-api-07e77f9ee3dd58552eb770 We need to provide support through the Extender API for WebSockets. I've added your requirement to the development ticket, which is a candidate for our next roadmap. Please let us know if you need any further assistance.

Wiktor | Last updated: Apr 14, 2022 06:19PM UTC

Hello Liam, Thanks for reply, about the roadmap - when probably this might happen, could you atleast point quarter of the year when this might be addressed or you have no information about this in this stage of request? Despite this, there is no more question regarding this topic. Best regards,

Liam, PortSwigger Agent | Last updated: Apr 15, 2022 08:24AM UTC

I'll discuss this with our product team and get an update if possible.

Liam, PortSwigger Agent | Last updated: Apr 26, 2022 09:36AM UTC

We hope to begin work on this feature towards the end of the year. We'll keep this thread updated.

Cdos | Last updated: May 23, 2023 04:09PM UTC

@Liam, may I know any updates on this please? any progress for burp suite pro able to handle the blazorpack via websocket traffics please? I am seeing more web applications have been developed in such a way to prevent us to actually intercept and analyse the HTTP traffic.

Cdos | Last updated: May 23, 2023 04:11PM UTC

There is a tool call Mallet that was shared by sensepost https://sensepost.com/blog/2023/decoding-blazorpack/ and they do have the demo site web application as well https://blazor.syncfusion.com/demos/

Liam, PortSwigger Agent | Last updated: May 24, 2023 09:08AM UTC

Hi Cdos, thanks for following up.

Can we get a link to an example in the demo site where Burp fails, please? We can't see any problems navigating to the demos page.

Cdos | Last updated: May 24, 2023 10:34AM UTC

Hi Liam, I couldn't share any site because its customer confidential information and have no external access. The main issue is burp didn't decode the blazorpack HTTP request as describe in the https://sensepost.com/blog/2023/decoding-blazorpack/ making it so difficult for a pentester to tamper or investigate the HTTP requests. Any ideas has this feature has been added yet? Thanks!

Dominyque, PortSwigger Agent | Last updated: May 25, 2023 09:24AM UTC

Hi Just so we are sure we have a solid understanding of the issue here, it's not that Burp cannot handle the Blazor web sockets but more that Burp does not understand the Blazor-specific protocol sent over from them. It should be noted that our Montoya API will give you all the tools that you need to build a plugin/ extensions that can decode the Blazor traffic yourselves. Here is a link to more information about creating extensions: https://portswigger.net/burp/documentation/desktop/extensions/creating

Cdos | Last updated: May 25, 2023 10:52AM UTC

Hi Dominyque, The Montoya API tools in the burp suite, does it support aggregating WebSocket frames ? The WebSocket frames shown by Burp were a maximum of 4096 bytes each, but the actual message could be far larger than that and spread over several frames. From what I could see, Burp had no support for aggregating multiple WebSocket frames (Continuation Frames) into a single entity, and so any attempt to decode a message that was spread over multiple frames would be failed. any ideas please? Thanks,

Dominyque, PortSwigger Agent | Last updated: Jul 04, 2023 09:47AM UTC

Hi We have not been able to replicate the issue you are having. We would not aggregate, but it should be able to handle an arbitrary length of up to 7+64 bits. Therefore, there is no limit of 4096 bytes. Are we able to have access to the site?

Rogan | Last updated: Jul 19, 2023 01:57PM UTC

If you read the Mallet post on the SensePost blog above, there is a site with demo applications, which you can use for your testing. One of the screenshots shows how the websocket frames come through in chunks of 4096 bytes. This is likely to be an artifact of the server, chunking them into an initial frame and then multiple continuation frames. However it happens, the frames need to be reassembled into a single frame to allow the binary payload to be decoded in any sane way.

Dominyque, PortSwigger Agent | Last updated: Jul 21, 2023 10:29AM UTC

Hi Rogan It should be noted that Burp will only proxy the traffic. It would not decode it. We currently have an extension in our backlog created by one of our users that we are reviewing. This should help you with what you are trying to do. I will update this thread when the extension has been released.

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