Secure Code Warrior C# Basic OWASP Web Top 10 2017 1: Injection Flaws and 2: Broken Authentication vulnerabilities

Let's start with the most critical application weaknesses. These challenges get you the foundations of 1: Injection Flaws and 2: Broken Authentication vulnerabilities

1: Injection Flaws 

Injection Flaws - OS Command Injection

Using the System.IO library, the temporary files folder is cleared (the type of which is selected by the user). User input is limited, therefore user-supplied input does not affect the OS command.

 

Injection Flaws - NoSQL Injection

Using string concatenation when building the NoSQL query filter may allow an adversary to inject malicious code to get access to sensitive information or carry out unauthorized operations.

Database queries should be built with parameterized input or OM/ORM technologies, if possible. Parameterized input is used to build a Mongo query filter. All parameters will be automatically escaped so an attacker will not be able to inject malicious query code.

Injection Flaws - OS Command Injection

Using unsanitized user-provided values to call OS commands may allow an attacker to execute malicious commands to carry out unauthorized operations.

If possible, it is recommended to avoid the use of OS command calls and use application native methods to perform the same operation. The file is being saved with <code>File.WriteAllLines(path, content) method, which does not allow the injection of malicious OS commands.

 

 

2: Broken Authentication vulnerabilities

Authentication - Improper Authentication

The authentication process is incorrectly implemented because, in case of a failed login, the authentication process is not interrupted. Additionally, password confirmation will accept any entered value. An adversary could take advantage of this incorrect implementation to bypass security controls and gain unauthorized access.

The authentication process has been properly implemented by requiring a valid username and password in order to allow access to the user. The hash values of the entered password and stored password are checked in order to ensure a valid value was provided. In this way, an attacker will not be able to take advantage to gain unauthorized access.

 

Session Handling - Weak Session Token Generation

Generating a session ID based on the username encoded with Base64 is unreliable. An attacker could figure out the logic behind this method of generating and use this knowledge to bypass authentication. The session ID must be completely random and unpredictable.

Generating a session token based on the SessionID value is random enough and creates a sufficiently large value. It is practically impossible for an attacker to derive the generation pattern of the session ID's and thus to exploit this vulnerability. 

 

Session Handling - Exposed Session Tokens

Storing the session token in a plaintext file or displaying it in the console output may allow a malicious actor to have access to it and impersonate the legitimate user.

The session tokens should be protected from malicious actors. The application is no longer displaying the token value in the console output or storing it in plaintext files. The token will only be available in the application memory space. In this way, an adversary will not be able to have to it and use it to impersonate legitimate users.