QA – the newly appreciated cybersecurity testing warriors

As a QA engineer at The Software House, I have had the opportunity to work with a huge foreign corporation that implements solutions for their government. Government websites, no matter what country they’re in, handle an incredible amount of sensitive information and personal data – this made me think a lot more about end-user security. 

And we’re not only talking about the US, Canada, or EU regulations containing provisions on the protection of the flow and processing of personal data like the General Data Protection Regulation (GDPR), which is the harshest law in the world right now. 

Lost in translation – step one in security is getting to know the client

When working with international clients, you have to take into account both the legal aspects and work culture of parts of the world like the Middle East, Africa, Australia, or in our case, West Asia. 

As I found out, you should definitely start by getting familiar with your end client’s work environment and conditions. What might seem irrelevant to us and is something that we can’t foresee because we don’t even think about it might actually be a sensitive data leak hiding in plain sight. 

For example, after talking to the Product Owner and having a chat, I learned that several people in different positions and with different security access may use the same computer station. 

This illustrates why a proactive approach has to be taken by the QA to get to know all the data – both hard and soft. That’s essential in order to find out about all the threats that the whole team might miss otherwise. 

What can you learn from OWASP? 

My knowledge about threats to web applications is based mainly on the rankings of the international non-profit foundation OWASP (The Open Web Application Security Project®). 

OWASP is a non-profit community founded in 2001. They produce tools, documentation, research, articles, and methodologies that all have to do with web application security. They also organize conferences and workshops on industry standards. OWASP projects are supported by the OWASP Foundation. If you’re not familiar with their work, you’re behind! 

OWASP’s research, carried out on the basis of risk analysis in recent years, allowed for the presentation and specification of methods. These were the development of tools, and remedial actions in connection with ensuring the security of IT systems. Also, the operation of enterprises implementing internet applications to improve business processes. 

Conducting case studies, the OWASP organization has been creating rankings of the most common web application threats since 2003, called OWASP Top 10. The first one was created in 2003 and, like each subsequent one, it contained the ten most common threats. 

Updates resulting from the changing behavior of web application users, as well as the advancement of security breach tools, took place in 2004, 2007, 2010, 2013, 2017, and 2021. 

It is worth analyzing the dynamics and trends of the last two decades. It is easy to notice that new threats have been added, but the positions of those previously listed have also changed in subsequent rankings. Below is a table I made containing all vulnerabilities from reports prepared over 18 years and the positions assigned to them in the ranking (from A1 – the most common to A10 – the least frequent).

Own study based on A. Sołtysik-Piorunkiewicz, M. Krysiak, “The Cyber Threats Analysis for Web Applications Security in Industry 4.0, Springer 10.1007 / 978-3-030-40417-8_8, 2020, p. 134

It is also worth paying attention to the 7 most frequently recurring web application threats (occurring 3 or more times). 

You’ll notice that Injections are listed in each of the rankings. The next ones on the list are

• Broken Authentication,
• Session Management, 
• and Cross-Site Scripting (XSS, CSS), 

which appear in reports from 2003-2017. 

Other common threats are Security Misconfiguration (noted between 2010-2021) and Broken Access Control (which were noted in 2003 and 2004 to be returned in 2017 and 2021 reports), and Insecure Direct Object Reference and Cross-Site Request Forgery (CSRF, XSRF), as shown in the figure below.

Own research,  A. Sołtysik-Piorunkieicz, M. Krysiak, “Contemporary threats to Internet application security in the light of OWASP research”, Wydawnictwo Politechniki Częstochowskiej, 2022, p. 267

Together with my colleague Adam Gola we try to create an analysis of changes to understand the latest trends and threats, every time the OWASP Top 10 rankings are updated. 

Of course, I recommend his article: on the Top 10 Vulnerabilities on the differences in the latest reports (2017 and 2021). It is worth commenting on the lack of compliance in the name of the report. 

Adam used 2020 in the name because the first version of OWASP Top 10 was released at the end of 2020, but the final version was available in early 2021. Check out The OWASP 2021 study. A picture of the latest changes is on the screen below.

The 2022 OWASP Top 10 report won’t be available until late 2022 or early in 2023.

But enough of theory! Let’s see some real work and simply show how to ensure quality based on some of the problems mentioned in the OWASP Top 10 2021. 

Of course, all the examples are based on my current project, therefore not all criteria will be tested and described. One criteria is a  A10 Server Side Request Forgery (SSRF), which can be easily tested. You need a component that is a field to which the user is to provide the URL to an external resource, so that the application will download and display the output.

Just try to enter the address leading to a file on the local disk, using e.g. file: /// etc / passwd, which clearly indicates that the application allows you to download any files from the disk. 

This is why in this article I focused on:

• A1 Broken Access Contol, 
• A3 Injection, 
• A4 Insecure Design, 
• A7 Identification and 
• Authentication Failures, and 
• A9 Security Logging and Monitoring Failures.

1. OWASP Top 10: 2021 A1 Broken Access Contol

Following the “OWASP Top 10: 2021” ranking, Broken Access Contol is the most common threat. 

This vulnerability allows for unauthorized access to data, e.g. by manipulating parameters in the URL address. For example, having a request with id = 10, the user will change the value from 10 to 11 in the URL address and the application data with the number id = 11. 

This makes any user able to access your information. This is a fairly simple thing to spot, and extremely important from a security point of view. Many people are knowledgable enough that instead of clicking on the link in an application, they replace ID values ​​in URLs and, by inadvertent (and sometimes even deliberate) action, may gain unauthorized access to data.

A very similar case is logging from user A’s account and then logging into user B’s account. I happened to be on the tab with my company details, logged out, and logged into another user to perform another test. 

At this point, it turned out that the URL is not cleared after logging out and the new user was able to see user A’s company data. 

The initial fix was to load the page with blank fields (all values ​​were replaced with “-“), but in my opinion, it is not the best method as user B saw user A’s company number in the URL. Another fix was cleaning the URL so that the next user would not be able to see any data from the previous user. Thanks to this, each logged-in user immediately after logging in goes to the service’s Dashboard.

I had a similar situation when I switched from a user with higher privileges to a user with lower privileges. 

A user with higher privileges could view all applications (submitted by other users) and edit them. I previewed the X application and logged into a low-privilege user. It turned out that I could see the details of X’s request. 

I looked at the list of requests submitted by this user and it turned out that he had never submitted one. This is another unacceptable situation where a given user has a chance to see another user’s sensitive data (without even interfering with the URL). 

And just like in the previous scenario, for unauthorized users, the developers first changed the values ​​into “-“, and only in the next patch they cleaned the entire URL address so that it was not even possible to suspect the application number. 

This situation is important because the client confirmed that there are companies in which there is only one computer and it is used by different employees (with different levels of authorization).

2. OWASP Top 10: A3 Injection

Third on the OWASP Top 10 list is Injection. It’s a category focused on various types of injections, such as SQL injection, PHP Injection, etc. 

Since last year, it has been combined with the Cross-Site Scripting (XSS) category, which was unique until 2017.

Cross-Site Scripting (XSS) attacks by themselves can be divided into three categories:

• Reflected XSS, 
• Stored <Persistant> XSS,
• and DOM-based XSS.

I’m going to focus on the first two for testing. Each of them can be tested in a fairly simple way:

• Reflected XSS – occurs when part of the HTTP request is reflected in the output (e.g. when sending a link). Out of curiosity, I tried to parse a URL request from: https://project/api/laborer?perPage=100&page=1to: https://project/api/laborer?perPage=<script>alert(XSS)</script>

• To display a pop-up window with the text “XSS” (this is one of the flagship ways to detect this vulnerability). Of course, the security on the website automatically changed the request to:https://project/api/laborer?perPage=10&page=NaN

Checking in DevTools, the GET method got the status 422 – Unprocessable entity, as it expected to receive an integer value, not a string. The page then reloaded the correct data.

• Stored (Persistent) XSS – occurs when the XSS code is saved in the database, e.g. as a blog comment. Similarly to the first case, I wanted to use the <script> alert (XSS) </script> phrase when adding a description to the form I am filling out.

This way, I learned that the React framework makes sure that characters are encoded, and the application does not send requests containing “malicious” code, but only reads it as a comment.

• It is equally important to check if there is no possibility of injections during logging (eg SQL Injection). This vulnerability may lead to unauthorized access to the database, resulting in the reading of data, i.e. logins and passwords, bypassing the authentication mechanism, code execution, etc.
• Flagship examples are variations on the simple SQL query language code:

1. using the following code in the password field: ‘OR’ 1 ‘=’ 1, which theoretically allows you to log into the system without a password, as the condition (1 = 1) is always met.

1. using the code in the login field: admin ‘) – which theoretically allows you to log in as the admin user, because “-” is the beginning of the comment, so the password will not be checked in the database.

Of course, that’s not the case after the first attempt and with exactly such a fragment of the code, we will be able to find an SQLi vulnerability. 

First of all, the administrator’s name does not have to be admin, but administrator, or it must be a series of numbers or a completely different name. It is worth trying different variations, and the examples shown above are intended to present the technique so that it would be understandable even for a person who does not write SQL scripts.

First of all, the administrator’s name does not have to be admin, but administrator, or it must be a series of numbers or a completely different name. It is worth trying different variations, and the examples shown above are intended to present the technique so that it would be understandable even for a person who does not write SQL scripts.

3. OWASP Top 10:2021 A4 Insecure Design

The A4 Insecure Design category is the debut of the current report. It is a broad category that focuses on the risks associated with the design and architectural flaws. It is supposed to make you aware of possible risks in the project at the design stage and does not refer to the implementation itself.

An example would be the file upload function. The most important thing is to check that only files with the allowed extension can actually be added. For example, when selecting files, the user should only be able to select those with a specific extension (in this case .png, .jpeg, .jpg, and .pdf), the rest should not be possible to add.

Of course, the user can manually switch the file explorer to allow adding any file extension (just in the format option, set the value to “All Files”).

A good practice is that despite adding a forbidden file, it does not save anywhere (in our project on the UI side, it looks as if the user did not select any file). Thanks to this, it is not possible to upload a malicious .exe file, etc.

Of course, it happens that a file, although it has a good extension (e.g. .png), is actually an .exe file. Such data can be procured by opening the file, e.g. in a notebook, and changing it to a forbidden extension.

This is what an attempt at opening the file in Paint looks like:

On macOS, at first glance, the file’s icon does not raise any doubts, but after trying to open it, we will get the information that it may be a damaged or unseen file.

Interestingly, Slack immediately recognizes that it is not an image and indicates that it is a binary.

After trying to upload such a file, our application displays a message about an illegal extension, and the file itself is not saved anywhere.

4. OWASP Top 10: 2021 A7 Identification and Authentication Failures

Another vulnerability is A7 Identification and Authentication Failures, concerning the login and error handling aspects of the application.

It is known that logging in to your application is a key element of many flows, so we can easily verify that a CAPTCHA will not appear after entering an incorrect login or password several times. This is a great security method from a customer’s point of view, but it’s not perfect either.

Of course, a better method of securing against a brute force attack is to implement throttling, which limits the frequency of accepted connections. Checking it manually, unfortunately, is not an option, because sending, for example, 2 requests in 1 second is impossible to perform. You can try to do it by sending requests from the API, but in this article, I focused on the aspects of manual testing.

In addition, it is important that after entering a wrong password, the user does not receive a message that they entered it incorrectly, because, for an unauthorized person, it will be a clear signal that such a user already exists in the database. The attacker will now be able to focus on this particular login. 

The same goes for restoring passwords. A better message is to indicate that the password or login is incorrect, thus the attacker is not sure of any of the values.

When restoring the password, it is worth checking whether the user has been logged out of all sessions (as a failure to do so may cause an unauthorized person connected to one of the sessions to make a similar move and replace the password with another one). Additional protection may be a message that an e-mail with a password change has been sent. If such an e-mail address does not exist in the database, the reset e-mail will never be sent.

Another problem with resetting passwords and creating accounts is imposing on the user the conditions that the password must meet, i.e.

• upper case letters, 
• lower case letters, 
• numbers, and 
• special characters.
  

This standard is currently being abandoned. Of course, the user should have a password longer than 1 character (a minimum of 12 and a maximum of 127 characters is a good practice). Recent research shows that using a passphrase, not necessarily with special characters, is much safer than using one or two words with a few special characters and numbers (eg Adm! N1). It is also a good practice to allow for the use of spaces, emoticons, and diacritics in a password. Experts also highly recommend the use of password managers.

5. OWASP Top 10: 2021 A9 Security Logging and Monitoring Failures

The last one I have for you is A9 Security Logging and Monitoring Failures, which concerns data stored in logs and error handling.

I honestly admit that this threat is not verifiable by every QA. This is not due to a lack of our skills, but due to a lack of access to logs. In my current project, practically each of us has the opportunity to see logs, so it is worth paying attention to what data is stored there. Sometimes the application does not log sensitive data defined in accordance with local regulations or privacy policy, sensitive data, including session IDs, passwords, hash strings, or API tokens.

And above all, whether the application returns error messages that contain sensitive data can help attackers. This includes session IDs, software/platform versions, and personal information. In the case of error messages from our applications, there is no question of showing redundant data. We try to handle all errors in each of the websites in a similar way.

Of course, we are not saints; not every case has been predicted and designed much in advance. Each time we try to maintain the standard to show the user as little technical details as possible, as in the picture below.

It is also worth remembering that when displaying an error, when “something goes wrong”, the user has the option to return to the previous step or reload the page.

It is not strictly related to safety, but to good practices and ensuring the quality of our product!

Remember that we QA are not only responsible for the appearance and clicking through the tests. It’s much more serious than that. Quality assurance should be important to us, not only through seamlessly crossing the line to UX and performance but also through web security aspects.

There are different standards on the Internet, depending on the client’s location. I try to focus on the results of the OWASP organization and their OWASP Top 10 Web Application Security Risks reports on web applications. It’s important that you too stay informed about the changes. Consider watching any upcoming OWASP global events – get into it!

It is worth mentioning that in 2016 a report was developed: 

OWASP Mobile Top 10, which can be found here: 

https://owasp.org/www-project-mobile-top-10/ 

And 2019 for API security: 

OWASP API Security Project, which can be found here:

https://owasp.org/www-project-api-security/

The organization itself has many tools, not only for pentesters, but also for QAs, developers, and designers to create the most secure applications possible. I hope that with this article, I encouraged you to pay attention to security in their project, and my examples will prove to be valuable tips!