Most Common Security Vulnerabilities

This part of the course is devoted to the discovery and reporting of security vulnerabilities in web applications. The focus is on the most critical web application security risks as reported by OWASP.

Injection

Injection vulnerabilities make it possible for the user (or the application) to send data to the web application that is then interpreted by the web application or one of its components although is should not be. A common example of such a vulnerability is the SQL injection, where query parameters or other unsanitized data are used as a part of a SQL query.

(source xkcd: Exploits of a mom.)

While SQL injections are perhaps the most common examples of Injection vulnerabilities (see e.g. Ruby on Rails and Spring Data JPA), other types of injections also exist. It can be, for example, possible to execute code on the application server (see e.g. Ruby on Rails and Spring) or Django.

Broken Authentication

Broken Authentication vulnerabilities allow users to impersonate other users. This may happen, for example, through poor session management (session hijacking), through very poor passwords, or through storing the users' passwords in plain-text format (or in an easily decryptable format) and accidentally leaking the data. If the user uses the same password in multiple locations, it is also possible that the data from some other web application is leaked, and a malicious user is able to connect the username and password of another web application to this application.

Sensitive Data Exposure

Sensitive Data Exposure is a vulnerability that is related to not properly protecting sensitive user data such as credit card information, social security numbers etc. Access to such information may lead to credit card fraud, identity theft, etc. This risk is related to many of the other vulnerabilities in that other vulnerabilities may allow leaking of such data; at the same time, if a data leak occurs, risks should be minimized. For example, passwords should be salted etc.

Broken Access Control

Broken accesss control makes it possible to access resources or functionalities on the server that should not be available to the user. As an example, the web application may store user specific data that is available through a query parameter or a path variable. If the user modifies the variable, access can be gained to resources that should not be accessible. Another common mistake with access control is having functionalities that should require authentication but do not. It may be the case that the application checks that the user is authenticated, but may fail to verify that the user has the required credentials for the action that he or she seeks to take.

The next assignment is done within Test My Code.

Security Misconfiguration

Security misconfiguration includes a wide range of issues from poorly configured servers and outdated software libraries to not changing default passwords. Such misconfigurations can reside both within the application as well as outside the application. Questions such as 'who has access to the server where the web application is running?', 'who has access to the server where the database or other components are running?', 'are the software components and libraries as well as the operating systems up to date?', 'are the used passwords high quality?' and so on.

As an example, one of the Denial of Service attacks was partially made possible by thousands of internet of things devices with default passwords (or poor passwords).

As software is often developed for third parties who become responsible for maintaining the software, fixing the issues is not straightforward. If a flaw is identified in the platform that is used to host the software, is it the task of the original developer(s) to provide support? For free, or at what cost? The customer may not be able to distinguish between the product and the platform and may not understand the responsibilities related to managing software.

Cross-site Scripting

Cross-site scripting (XSS) vulnerabilities make it possible for the user to include malicious content to a site that will then be executed on the machine of another user. The malicious content may be permanently stored on the web application (e.g. in a database if the input and output is not sanitized), or it may be included temporarily (e.g. as a part of a query parameter).

Such attacks make it possible to — among other things — hijack users' sessions and as a consequence impersonate another user. For example, the cookies that are related to the current document may be accessible through the variable document.cookie, and sent to the server of a malicious user through a simple XMLHttpRequest.

<script>alert(document.cookie);</script>

There exists a handful of (incomplete) solutions that are used to filter out possible XSS attacks, including removing brackets from the code. OWASP has a good checklist that can be used for XSS testing.

Using Components with Known Vulnerabilities

Using Components with Known Vulnerabilities is typically related to unmaintained software. As software is built upon existing libraries and vulnerabilities are constantly identified and fixed, it is important to keep track and maintain the software libraries in use. This is an issue that is not limited to web frameworks, but also to the underlying software components including the operating system (see e.g. The Dirty COW).

Most dependency management tools have plugins that can analyze the used dependencies and identify components with vulnerabilities. For example, Python packages safety (and safety-db) can be used to check any vulnerable packages.

Unvalidated Redirects and Forwards

Unvalidated Redirects and Forwards may cause the web application to redirect the user to an unwanted location. This may happen, for example, if the address to which the user is forwarded after an action can be tampered with. For further information, see the OWASP Cheat sheet.

Cross-site Request Forgery

Cross-site Request Forgery (CSRF) makes it possible to create requests from another site (source) to the web application (target). If the user who is accessing the source site is authenticated to the target web application, the browser of the user will send an authentication token (e.g. cookie) with the request to the target application as the user is accessing the source site, making it possible to access data as an authenticated user that should not be accessible. Many frameworks these days include CSRF defences by default.

In this this part of the securing software course, we looked at some of the most common web security issues. During the next part, we will look a bit deeper into finding flaws in software.

Remember to check your points from the ball on the bottom-right corner of the material!