Secure Code Warrior OWASP Web Top 10 2021 A3-A4 3: Injection Flaws and 4: Insecure Design

Learn the ropes or hone your skills in secure programming here. This set of levels will focus on 3: Injection Flaws and 4: Insecure Design

 3: Injection Flaws

Injection Flaws - OS Command Injection

Argon2 hashing algorithm is applied for passwords, the implementation of which is made in a separate application. A command line with user input without any cleaning is used to work with an executable file. An adversary can include malicious OS Commands, that would be performed on the server-side, into data .

Using built-in application functionality without starting external processes that include any user input protects the system from OS Command Injection. The Nuget package manager contains Argon2 hashing algorithm implementation for .NET Framework, so, the launch of an external application is not required.

Cross-Site Scripting (XSS) - Stored Cross-Site Scripting

The page is rendered with user-defined data, which is stored in the database without any sanitization. An adversary could exploit this vulnerability and save in the database some malicious JavaScript or HTML code, which will be lately rendered.

which one fix  @Html.Raw(Model.Content)

A.<span>@Html.Raw(Model.Content)</span>
B. @Html.DisplayTextFor(p => p.Content)
C. @Html.Raw(Microsoft.Security.Application.Encoder.CssEncode(Model.Content))
D. @(new HtmlString(Model.Content))
explain the reason

The correct option to fix @Html.Raw(Model.Content) is:

D. @(new HtmlString(Model.Content))  应该是B

Here's the reasoning behind it:

1. Option A: <span>@Html.Raw(Model.Content)</span>
   This option wraps @Html.Raw(Model.Content) with an HTML <span> element. While this will render the content correctly as raw HTML, it introduces an additional <span> element that may not be necessary depending on the context.

2. Option B: @Html.DisplayTextFor(p => p.Content)
   This option uses @Html.DisplayTextFor which is used for rendering plain text and doesn't interpret any HTML. It won't fix the issue of rendering HTML content as intended.

3. Option C: @Html.Raw(Microsoft.Security.Application.Encoder.CssEncode(Model.Content))
   This option uses Microsoft.Security.Application.Encoder.CssEncode which is used to encode CSS content, not HTML content. It's not suitable for rendering HTML.

4. Option D: @(new HtmlString(Model.Content))
   This option creates a new instance of HtmlString, which is a type that allows you to render raw HTML content. This is the correct way to render HTML content from a string in Razor syntax.

   Using @(new HtmlString(Model.Content)) ensures that the Model.Content is treated as raw HTML and will be rendered as intended.

It's worth noting that Html.Raw also serves a similar purpose, but HtmlString is considered more explicit and safer in some contexts because it explicitly marks the content as raw HTML.

 

 

HtmlString class is used instead of Html.Raw() method. But it is as vulnerable as the original solution because Html.Raw() is just creating HtmlString. So an adversary is still able to paste JavaScript or HTML code and save it in the database.

It is recommended to always sanitize user-defined data before rendering it on pages. In ASP.NET, Razor Pages encode all data by default (instead of using Html.Raw method or HtmlString class). So rendering data with Html.DisplayTextFor() method is enough to prevent XSS attacks.

 

Injection Flaws - NoSQL Injection

The application is vulnerable to NoSQL injection attacks as user input is used directly to create JavaScript expressions. These expressions are used with $where operator on the MongoDB database and can be manipulated by an attacker to bypass restrictions and manipulate/access sensitive data. In this scenario, an attacker can manipulate the input to search and edit medicine details added by other users.

 

The MongoDB C# driver API provides safer and more performant filters for generating BSON queries that are recommended instead of parsing JavaScriptON directly or using JavaScript expressions.
Here C# Linq query is used to validate user input before querying in MongoDB. As such, the searched medicine name retrieved from the client-side is automatically encoded by the C# MongoDB driver in the resulting BSON query. This approach nullifies any threat of injection attacks as the generated query is secure and cannot be manipulated.

4: Insecure Design

File Upload Vulnerability - Unrestricted File Upload

This application allows users to upload a profile picture to the server. The application does not check the type of the file being uploaded by the users. This makes the application vulnerable to local file-inclusion attacks. An attacker can upload code files to the server and execute it on the server by traversing to the uploaded file path on the server. It is also possible to overwrite application files on the server such as the code files, the configuration files, etc., by uploading files with the same name as of the application files.

In this case, the application checks the extension of the file being uploaded by the user. If the extension of the file is other than what is expected by the application then the upload operation is aborted with an error message. Additionally, the application assigns a unique random name to the files uploaded to the server using GUID values. This prevents users from uploading files of types other than the allowed file types. Renaming the file to a GUID ensures that the application files on the server do not get overwritten by files uploaded by users.