Hendrik Buchwald 491c17525b
Modify rule S5131: Add fix for Blazor (APPSEC-1898) (#4116)
* Add fix for Blazor

* Update rules/S5131/csharp/how-to-fix-it/blazor.adoc
2024-08-27 09:37:06 +02:00

62 lines
1.6 KiB
Plaintext

== How to fix it in Blazor
=== Code examples
==== Noncompliant code example
[source,csharp,diff-id=21,diff-type=noncompliant]
----
@page "/"
@((MarkupString)tainted) <!-- Noncompliant -->
@code {
[SupplyParameterFromQuery]
private String tainted { get; set; } = "";
}
----
==== Compliant solution
[source,csharp,diff-id=21,diff-type=compliant]
----
@page "/"
@(tainted)
@code {
[SupplyParameterFromQuery]
private String tainted { get; set; } = "";
}
----
=== How does this work?
Template engines are used by web applications to build HTML content. Template
files contain static HTML as well as template language instructions. These
instructions allow, for example, to insert dynamic values in the document as the
template is rendered. Template engines can auto-escape HTML special characters
of dynamic values in order to prevent XSS vulnerabilities.
In .NET applications relying on Blazor/Razor, the auto-escaping feature is
enabled by default. XSS vulnerabilities arise when an untrusted value is
injected in the template and auto-escaping is disabled by type-casting the value
into `++MarkupString++`. This is often the case when a piece of dynamic HTML is
generated from the code and used in a
template variable.
include::../../common/fix/data_encoding.adoc[]
Razor engine auto-escaping only takes care of HTML entity encoding. It will not
prevent XSS if a variable is injected in an unquoted attribute or directly in a
script block.
=== Pitfalls
include::../../common/pitfalls/validation.adoc[]
=== Going the extra mile
include::../../common/extra-mile/csp.adoc[]