C# - Common Security Threats & Vulnerabilities (Part 2/6)

Read part 1

5. Host Header Injection

Host header attacks are a type of injection vulnerability whereby an attacker can set the HTTP "Host" header value to an attacker-controlled domain name. Should a web application use this HTTP "Host" header values, for example to generate "password reset" links, an attacker can alter the reset token URI to redirect the user to a malicious site and further leak their token.

Modify Request

Bob knows that if the application relies on the value of the Host header for sending links, it could be vulnerable to Host Header Injection attacks.

Bob intercepts the request and modifies the Host header field, this time by replacing the hostname with his newly registered domain:

Bob now needs to wait for Alice to access and click the DesignDECK password reset email.

Upon accessing the password reset URL, a  GET request event is simultaneously logged on Bob's apache webserver, revealing Alice's password reset token!

Mitigation

In order to effectively mitigate against Header Injection attacks, developers must ensure all incoming HTTP headers are properly sanitized to prevent malicious header values from being included in the response or backend business logic.

This can be achieved by implementing an allowlist of allowed hostnames and subdomains, which can be used to prevent malicious hostnames from being included in the response. 

6. Use of Insufficiently Random Values (Weak Randomness)

Vulnerabilities associated with weak or insufficient randomness occur when an application generates predictable values in a context requiring unpredictability. This includes cryptographically weak tokens, predictable session cookies or incremental identifiers. The possibility to predict valid values can allow attackers to infer sensitive information or even impersonate other users.

Mitigation

To effectively mitigate against Weak Randomness in applications, developers should avoid writing custom cryptographic primitives and random number generators.

Instead, developers should leverage their web framework or operating system's cryptographic libraries, which offer a wide variety of random number generation functions that are well tested and proven by cryptographic standards such as FIPS and NIST.

7. Personally Identifiable Data in URL (PII data in URL)

Sensitive information exposure through URLs occurs when data such as Personally Identifiable Information (PII), usernames, credit card numbers, passwords, session tokens, and any other potentially sensitive data is passed via HTTP GET parameters. This can result in sensitive data being exposed logged by an application server e.g. web server logs, proxy logs or third-party analytics and monitoring applications and increase the likelihood of information being exposed to malicious actors.

Mitigation 

In order to effectively mitigate against PII exposure in URL's, developers must ensure personally identifiable data is not transmitted via URL query parameters.

8. Session Fixation

Session Fixation is a type of attack on web application users where an attacker is able to trick a victim into using a Session ID which is previously known to the attacker. If the application fails to generate a new session ID every time a user authenticates, an attacker can obtain a valid session and then trick an unsuspecting user into authenticating with the attacker's session ID, thereby allowing the attacker to impersonation as an authenticated user.

 Bob simply copies the URL that was generated upon loading Invoiceable's login page. He then sends an email to Alice, requesting her to access that URL.

 

 As Alice, go ahead and log in using your Invoiceable authentication credentials.

 

 Having waited for a few hours, Bob returns to his browser session and attempts to refresh the Invoiceable login page.

 

 By simply refreshing his browser, Bob has managed to access Alice's account. 

 

 Mitigation

To effectively mitigate against Session Fixation attacks, web applications must ignore any session ID provided by the user's browser at login and must always generate a new session to which the user will log in if successfully authenticated.

Further, all sessions must be refreshed upon each login, logout and password reset event. This ensures that a user's session ID is not reused by another user or attacker who may already have access to a valid session ID.