ASP.NET Core

Question 1

Server.HTMLEncode Method

HTML.Encode() - What/How does it prevent scripting security problems in ASP .NET?

Server.HTMLEncode Method

Answer 1

https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525347(v=vs.90)

The HTMLEncode method applies HTML encoding to a specified string. This is useful as a quick method of encoding form data and other client request data before using it in your Web application. Encoding data converts potentially unsafe characters to their HTML-encoded equivalent.

If the string to be encoded is not DBCS, HTMLEncode converts characters as follows:

The less-than character () is converted to >.

The ampersand character (&) is converted to &.

The double-quote character (“) is converted to “.

Any ASCII code character whose code is greater-than or equal to 0x80 is converted to , where is the ASCII character value.

If the string to be encoded is DBCS, HTMLEncode converts characters as follows:

All extended characters are converted.

Any ASCII code character whose code is greater-than or equal to 0x80 is converted to , where is the ASCII character value.

Half-width Katakana characters in the Japanese code page are not converted.

Copy
HTMLEncode(
string
)

”) %>

Example Code
The following script:

Copy
“) %>
Produces the following output:

Copy
The paragraph tag: <p>
The preceding output will be displayed by a Web browser as:

Copy
The paragraph tag: </p><p>
If you view source, or open the page as a text file, you will be able to see the encoded HTML.

This means that if you are going to dump some data to the request stream and that data was saved to the database from a user-entered field it will prevent users from being able to say that their first name is:

function doSomethingEvil() { /* ... */ }

In this example, Server.HTMLEncode would encode the , and “ characters leaving this:

function doSomethingEvil() { /* ... */ }

which, if rendered in the browser will look like this:

function doSomethingEvil() { /* … */ }

rather than actually executing.</p>

Question 2

Ensure appropriate controls are in place when accepting files from users

Answer 2

https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-input-validation#controls-users

Uploaded files represent a significant risk to applications.

The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement.

It depends on what the application does with the uploaded file and especially where it is stored. Server side validation of file uploads is missing. Following security controls should be implemented for File Upload functionality:

File Extension check (only a valid set of allowed file type should be accepted)
Maximum file size limit
File should not be uploaded to webroot; the location should be a directory on non-system drive
Naming convention should be followed, such that the uploaded file name have some randomness, so as to prevent file overwrites
Files should be scanned for anti-virus before writing to the disk
Ensure that the file name and any other metadata (e.g., file path) are validated for malicious characters
File format signature should be checked, to prevent a user from uploading a masqueraded file (e.g., uploading an exe file by changing extension to txt)

Question 3

The app’s process must have read and write permissions to the storage location. Never grant execute permission.

Answer 3

The app’s process must have read and write permissions to the storage location. Never grant execute permission.