Web Security

Goals

Read up on Web Security Basics and write simple web vulnerabilities using Javascript/HTML

With the knowledge of Web Security attack three targets using the following web exploits:

Explain the vulnerability in each target and explain the details about how to correct it.

The vulnerability of this attack pertains to the account.php file. Specifically the following code snippets:

Code Snippet 1. account.php CSRF protection

Code Snippet 2. account.php CSRF hashing function

Given the first snippet, we can clearly see that line 25 gives you the information necessary to recreate the form since it gives you the exact value it is supposed to be when an XSRF attack is unsuccessful given the wrong response value. In addition, given the first and second snippet, we can clearly see that line 19-22 and lines 67-70 respectively has the algorithm to create the response value, which an attacker can easily recreate.

In order to fix this vulnerability, instead of displaying the expected value when an unsuccessful XSRF attack takes place, we can replace it with a more generic message. In addition, we can move the algorithm used to create the response value to another file, which restricts the access of the algorithm from the attacker. Another implementation could be using a randomized challenge value, which is unique to the session, making it unpredictable for the attacker to forge a request with the correct token.

The vulnerability of this attack pertains to the index.php file. Specifically the following code snippet:

Code Snippet 3. index.php Login field

Given the code snippet, it can be noticed that within the login value, there is not really any input sanitation, which results in an injection of malicious javascript.

One way to tackle this vulnerability is to sanitize the input with a php function called htmlspecialchars(), which encodes all special characters into HTML entities within the value of the input field.

The vulnerability of this attack pertains to the auth.php file. Specifically the following code snippet:

Code Snippet 4. auth.php SQLi filter function

Given the first code snippet, it can be noticed that although there is a function that sanitizes the username to remove fishy input, it does not cover multiple cases in which a SQL injection can take advantage. For example, OR, single quotation and double quotation. Therefore, this makes it so it is possible to inject a string following the username that will evaluate to True by adding “‘ OR ‘1=1’”. In this case, the SQL statement will bypass the code that validates the password, allowing for unauthorized access to any registered username.

One way to tackle this vulnerability is to sanitize the input by encoding special characters into HTML entities or cover all the cases of special characters within the sqli_filter function to make it impossible to create a SQL statement following the username. However, since blacklisting is very hard to implement, because there are many possible ways to inject malicious strings, instead a whitelisting methodology can be used to allow only well-defined set of safe values. Another solution to this would be to use prepared statements, which “it makes sure that whatever the user enters is treated as a string literal in SQL and NOT as a part of the SQL query. It may also escape certain characters and detect/remove malicious code”. This can be used within the auth.php file and change the “$sql = "SELECT user_id, name, eid FROM users WHERE eid='$escaped_username' AND password='$hash'";” accordingly to make it a parameterized statement.