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:
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.
Interested in application testing? Read about E2E tests for frontend in our recent blog post!
Sources and Inspiration:
- https://testuj.pl/blog/testy-bezpieczenstwa-przy-okazji-testow-manualnych/
- https://www.netsparker.com/blog/web-security/web-application-security-tests-included-in-functionality-qa-tests/
- https://itwiz.pl/lockdown-sprzyja-cyberprzestepcom-czterokrotnie-wzrosla-liczba-atakow/
- https://www.packetlabs.net/security-testing-in-sdlc/
- https://www.3pillarglobal.com/insights/approaches-tools-techniques-for-security-testing/
- https://szkolasecurity.pl/ciasteczka/
