[Blazor] Security recommendations for Blazor apps using Server Components with Websocket compression enables

[javiercn]

Placeholder issue so that we can track adding this to the docs.

Compression can expose the application to side-channel attacks against the TLS encryption of the connection like CRIME and BREACH. These types of attacks require that the attacker can force a browser to issue requests to the vulnerable site (via cross-site form posting or by embedding the site inside an iframe of another site) with a payload they control, and that they can observe the length of the compressed and encrypted response over the network.

For the app to be vulnerable, it needs to reflect the payload from the attacker into the response. For example, by writing out the path or the query string into the response. Using the length of the response as an oracle, the attacker can "guess" any information on the response, bypassing the encryption of the connection.

Generally speaking, it should be fine for Blazor apps to turn compression over the WebSocket connection with the appropriate security measures:

• Your app can be vulnerable when it takes content from the request (like the path or query string) that can be influenced by an attacker and reproduces it into the HTML of the page.

• Blazor applies some measures automatically:

  • When compression is configured, we automatically block the app from being embedded into any iframe. That blocks the initial (uncompressed) response from the server from being rendered, which in turn precludes the WebSocket connection from ever starting.
  • The restriction can be relaxed, however, doing so, exposes the app to be attacked if the embedding document gets compromised via a cross-site scripting vulnerability, as that will give them a way to execute the attack.

• Normally for this type of attack to take place, the app needs to reproduce the content over and over in the responses so that the attacker can guess the response. Given how Blazor Renders (it renders once and then produces diffs of the content only for the elements that changed) this is very hard to accomplish. However, it is not impossible, so care needs to be taken to avoid rendering sensitive information alongside external information that can be manipulated by an attacker. Some examples of this are:

• Render PII information on to the page, at the same time as data coming from the database that can have been added by another user.

• Rendering PII information on to the page at the same time as data coming from another user via JSInterop or a local singleton service on the server.

In general, it is recommended that you avoid rendering components that contain sensitive information alongside components that can render data from untrusted sources as part of the same render batch.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[danroth27]

In general, it is recommended that you avoid rendering components that contain sensitive information alongside components that can render data from untrusted sources as part of the same render batch.

@javiercn Is this security guidance really practical?