Manual tests extended with security tests using the browser

Introduction

For years, functional testing has been part of the software development cycle (SDLC). Functional testing is concerned with known expectations, simple processes, and easy-to-interpret results, so security considerations rarely appeared on the radar, especially as the goal was often to release the application "yesterday!"

I guess needless to mention what security tests are and what are the advantages of these tests. There are plenty of entries on the Internet on this subject. The statistics can also speak for themselves. During the pandemic, cyber attacks increased up to 4 times, increasing awareness of the organization's software/application security approach. This means considering and incorporating security testing into the SDLC.

Not so long ago, security testing (or the menacingly sounding "penetration testing") was a very scary thing, best left to those who understood it. However, after exploring the information and broadening the knowledge we have at Apptension, I came to the conclusion that the awareness I will share later in this article is nothing spectacular.

This is something every tester has always known and seen, but perhaps unaware of the severity of the bugs found. Each of the elements listed below is part of maintaining the security of the web application and may affect the security itself. All this without any sophisticated tools, practically only through the browser (devTools).

Comments in the code

The source code for server-side storage can sometimes be exposed to users. Such code may contain sensitive information, such as database passwords and secret keys, which may help malicious users formulate attacks on the application.

How to start with it?

By right-clicking on the selected application, we choose the "Source code" and the easiest way is to start searching for the phrase <! -, which means a comment. You can also search by phrases such as key, secret, password etc.

Invisible elements

Everything that exists on the user interface is not secure. It is no different with the elements on the page with the following parameters: visibility: hidden or display: none. Why is it important? Implementing visibility changes, e.g. buttons in CSS properties, will not fulfill their security function, unless there is no implemented business logic on the BE side. Such a hidden button, even when validated, can still reveal a page that an unauthorized person will try to access.

Business logic gaps

Most often, it is about showing an error message that contains important information that may appear to be irrelevant, and for the attacker it is a huge source of knowledge. The fastest and easiest way to do this, where there should be numbers, is to type letters / special characters and vice versa. When we deviate from the expected user behavior, the application does not take the appropriate steps to prevent it, and thus cannot safely handle the situation. A valuable find can be calling the page from stacktrace:

Source: https://www.codeproject.com/Articles/783229/Hack-proof-your-ASP-NET-applications-from-Sensitiv

‍

Security headers

HTTP security headers are a fundamental part of application security. Once deployed, they protect against the different types of attacks that your application is most vulnerable to. Headers protect against XSS, SQLi, clickjacking, etc.

It is worth making sure that the application uses headers such as:

X-Frame-Options
Strict-Transport-Security
Content Security Policy (CSP)
X-Content-Type-Options
X-XSS-Protection - This header is no longer supported by Chrome, Firefox and Edge, the X-XSS-Protection functionality can be replaced with the CSP header.

What are these headlines in a nutshell can be heard from Jakub Mrugalski in a 3-minute film: https://www.youtube.com/watch?v=QBOOvyZv7SU.

Tools for checking security headers:

https://securityheaders.com/ - we provide the address of the application or page we want to test, and after entering, information about the domain and what headers are used on this page pops up (remember to select the "hide results" option so that the scan results are not visible publicly)
https://report-uri.com/home/analyse - there is a CSP Analyzer tool - enter the domain in the dedicated field and you will see what CSP headers were used with the recommendations.
https://report-uri.com/home/generate - another tool is CSP Policy Builder, where we create a policy and generate a string that we then want to add to the configuration of our web server.

Cookies and session

Cookies are information that the server can send to our browser. They usually contain the application configuration and / or user identification data (it’s session identifier, the so-called session token). Cookies’ content can be very interesting from the point of view of the attacker, so it is worth making sure that our cookies are safe. Fortunately, cookies have attributes called Flags that can improve this security include:

Secure - whether the cookie is sent over an encrypted connection.
HTTPOnly - does not allow scripts to read cookies. The name of this flag indicates that cookies are only used in HTTP / S Requests and nowhere else.
SameSite - This is an experimental flag that Google added in Chrome 51. It aims to reduce the risk of CSRF.
HostOnly - This flag indicates whether the cookie is to be accessed from other subdomains of our application or not.

Once we know what to look for with cookies, we can begin to explore the session and its mechanisms.

Registration - when registering, it is worth paying attention to such aspects as password policy, whether passwords are not stored in plaintext or encoded in base64, and what the password recovery process looks like
Login - what are the methods of logging in, are there any security mechanisms, what are the mechanisms, is there a need to implement e.g. 2FA
Logging out - the session token should first of all be removed on the client and server side.

URL manipulation

By manipulating some parts of the URL, you can trick the server into delivering the network pages that should not be accessed.

In dynamic pages, most parameters are passed via a URL as follows:

http://aim/forum/?cat=2

The data present in the URL is created automatically by the site and during navigation usually, the user simply clicks on the links suggested by the site. If the user manually modifies a parameter, it can try different values, for example:

http://aim/forum/?cat=6

So you can potentially access an area that is normally protected.

The easiest way is also to add /robots.txt in the URL of our website - maybe there are interesting informations visible from the attacker's point of view, which should be invisible.

Example based on Apptension’s app: teamdeck.io

In order not to be groundless, I checked the teamdeck.io application for the above-mentioned examples. Here are some examples that may be useful to a potential attacker.

1. Link do github which shows, that some of the components may be created for Angular. Not it’s easy to search for any Angular vulnerabilities

2.I found that application use nginx

3. Some of the Security Headers missing

Conclusion

The term "security testing" is fairly simple but covers many subject areas. Thanks to these few additional steps, we will make a solid brick to the quality of the application. Especially since in today's threatening development landscape, both functional and security testing are essential to make sure that all vulnerabilities are detected and fixed early, and that users get the quality product they demand and expect. It is, of course, a tedious job, but unprecedentedly worth the time spent.