Due to the architecture and proprietary message formats used by Blazor Applications, they cannot be comprehensibly scanned by AppCheck or other Dynamic Application Security Testing (DAST) vulnerabilities scanners.
AppCheck's Research & Development team are investigating the feasibility of adding support in the future, though we cannot currently give a timescale for this project.
This article will go into further details on the challenges of scanning Blazor applications.
The Challenges of Scanning Blazor Applications
In order to identify vulnerabilities a DAST scanner, such as AppCheck, must be able to form a valid request to the application and observe its response. By modifying each parameter within that request and observing differences in application behaviour the scanner can infer the existence of vulnerabilities. This process is known as fuzzing, and is essential to all DAST scanners.
Most Blazor applications use a proprietary message format called “BlazorPack”, as opposed to the HTML, JSON, XML etc used by most web applications. BlazorPack is not a language the AppCheck scanner currently understands, which means the scanner is not able to fuzz the BlazorPack messages.
Adding support for BlazorPack is on our developers' future tasks list, but has not yet been picked up for implementation.
Architecture of Blazor Applications
There are three variations of Blazor:
- Blazor WebAssembly is entirely in the web browser using WebAssembly (WASM) executing .NET byte code in the browser.
- Blazor Server hosts Razor components in a ASP.NET Core application on the server and sends UI updates to the browser via a SignalR connection.
- Blazor Hybrid use a blend of native and web technologies to run a native client application rendering a UI to an embedded Web View.
You can read more about Blazor in Microsoft's documentation.
In WASM applications messages are sent between the application front end (the elements rendered in a browser that a user interacts with directly) and web workers (parts of the application than run as background processes), and between the web workers and the server.
The AppCheck scanner cannot inspect or fuzz the messages between the front end and the web workers.
The AppCheck scanner can inspect and fuzz the messages between the web workers and the server, provided they are in a supported format, which is not currently the case if using BlazorPack.
Blazor Server uses a SignalR connection to send asynchronous binary messages between the browser and the server. SignalR uses WebSockets, however it also offers fallback to “long polling” which uses HTTP messages.
AppCheck support for WebSockets is currently experimental and undergoing testing, so AppCheck will use the fallback HTTP method were available.
AppCheck has excellent support for fuzzing HTTP messages provided they are in a supported format, which is not currently the case if using BlazorPack.
However, even when using a supported format and protocol, the architecture of Blazor Server applications differs from other web applications to such an extant that a bespoke scanning solution would be required.
When crawling an application, AppCheck's objective is to stimulate side effects within the application. In the context of Blazor Server applications, a unique scenario unfolds: the server side maintains a state that mirrors the state within the browser. Consequently, certain parameters within the messages exchanged between the application and the server encapsulate information from this synchronized state. One illustrative example is the eventHandlerId.
This intricacy presents a series of challenges. Typically, our scanners operate within a Request/Response framework, where a single request corresponds to a single response. However, in a Blazor application, the client or server might dispatch multiple messages before the other party responds. This dynamic complicates the fuzzing process, requiring us to capture "groups" of messages and replay them in a coherent flow. The key obstacle lies in the difficulty of distinguishing between these groups of messages, posing a significant challenge in ensuring accurate and meaningful fuzzing.
AppCheck’s web application vulnerability scanner does not support scanning native applications (i.e. applications installed on a machine rather than running in a browser), therefore there are currently no plans to add support for scanning Blazor Hybrid applications.