Companies expect that their web applications will load very fast and have intuitive UX. According to them, they need well-performing systems, fast, reliable, and usable.

Unfortunately, they often tend to forget about one crucial thing – web application security testing. Due to limited time, budget, and (sometimes) knowledge, clients resign from QA engineers taking care of software security testing. And, in the era of GDPR, massive phishing threads, and many successful cyber-attacks, consequences for their business may be dreadful.

So, it’s great that you’ve taken this first step and opened this article – let me explain why web application security testing is important and how to do it properly.

Security risk assessment in software development 

The very first thing to do before actual security testing is to explore the application in order to learn its business logic and functionalities. It’s a crucial part of the whole process because you have to detect any vulnerabilities at this point. You have to analyse HTTP headers and gather as much information as possible.

It’s necessary to obtain the data about users, levels of permission, network servers and configuration. In the presented case, I used Kali Linux and its predefined applications to obtain all the aforementioned information and prepare something like a security assessment report.

Thanks to that, I gathered the details listed below:

• the application was built to manage a chain of restaurants,
• there was open access to the website (you just needed to know a hierarchical URI address),
• once logged in, you got access to sensitive data (personal details, contracts, salaries, medical surveys),
• there was no payment system,
• the app included file upload modules,
• there was also a messaging (with attachments) module,
• the system had over 300 possible permission levels (yup!),
• there were no headers, tokens or flags which could improve the security level.

Having that data gathered made me ready to step into the next phase – the execution of security tests.

Web application security testing: a step-by-step case study

I started by confirming that there are no headers. I added this information to the report. Also, I noted that there are no tokens or flags which could have improved security level.

The next step was to analyse the strength of cookies. The result was rather positive. Unfortunately, the outcome of the sign-in and sign-up modules’ audit led to some negative conclusions. I detected that there’s no validation of the minimal/maximum number of characters. For instance – a user could have registered a one-character password (such as a space character). Obviously, it’s a serious security risk. Also, I found that the buffer may be easily overloaded during hashing or salting passwords.

The other results of security testing also weren’t promising. Permission levels investigation helped me to discover the possibility of incrementation or decrementation in ID provided in the URL address. It was another security risk, as it may have led to the intentional or accidental discovery of other users’ sensitive/confidential data. And the system itself was full of this kind of information – there were scans of contract details and salaries, passports or IDs. All this information could have been easily used for phishing or even for taking a loan on someone’s behalf.

Moreover, during code analysis, our development team found “root” permission. It basically gives access to all the available actions and data. Activating it was as simple as hijacking and modifying the request.

The next step was about security testing of the forms (such as adding a user, a comment or an element). Again, I found a variety of vulnerabilities such as cross-site scripting (as can be seen on the screenshot below), session hijacking or possibility to send scripts. 

Some other vulnerabilities were discovered in the module responsible for sending attachment files. A user could have sent executable files or scripts under .svg files. 

The final part of security testing helped to discover the presence of version control files on the server. It allowed hijacking the whole page’s source file by analysing the latest commits and branches. Finally, versions of the used libraries and frameworks were really old and, therefore, full of some critical security gaps. 

After performing all those QA actions, I started creating the report for the client.

Security assessment report in web application testing

Basing on all the gathered information, I created a universal template which we now use in all the projects. It contains:

• introduction with some basic information about testing and the environment,
• reconnaissance information – tests of the server and implemented services, 
• a prioritized list of detected vulnerabilities,
• detailed information about security risks and gaps with some offered solutions provided in a straightforward, non-technical language,
• a list of all the remaining tests which met the criteria and finished with a positive outcome,
• subjective valuation of the tested app and some future recommendations. 

The report got positive feedback from the client. It helped them realize how many security risks and gaps there were in their system. My recommendations helped them prioritize and solve the most important issues connected to the security of the system.

Most common security risks

Based on the vulnerabilities mentioned above, it’s easy to point out some real security risks which could have happened if an app like that appeared in the production environment. I’ll focus on three of the most important vulnerabilities.

• Signing in.

No password validation could have led to the situation in which an account is taken over by an unauthorized person. If the login was a simple email address or a basic “name.surname” model, the risk would be significantly higher. Additionally, some other employees could have logged in with someone’s credentials and learned everything about their personal data or salary.

Also, a risk of buffer overload caused by the use of too long password might have caused some serious efficiency problems. Obviously, it’s something you can’t accept from a purely business perspective. Moreover, there was no protection from potential brute force attacks.

Negative scenario: an employee gets access to someone else’s account.

Critical scenario: a user gets access to the admin account, therefore gets access to all the data available as well as the possibility to use it or delete it. 

• Permission levels.

An incorrect configuration of the permission model might have led to easy access to sensitive data. 

Negative scenario: an employee finds information about the salaries within the company and gets access to the scanned documents.

Critical scenario: an employee uses the data by leaking them (phishing, blackmail).

• Files validation.

The lack of file validation might have allowed sending of the executable files or hidden scripts.

Negative scenario: one can use this vulnerability to reveal the credentials and use them in the future.

Critical scenario: possibility to send viruses, keyloggers, or disk encryption script.

So what’s the deal with web application security testing?

As you can see, application security testing is crucial when it comes to quality assurance in software development. You have to be very cautious and perform all the necessary tests to get the bigger picture of the application and its security. It’s not exactly common knowledge and we weren’t aware of it at the beginning of our company either.

However, you need to remember that the final security audit in the last phase of software development is very important too. So, make sure that you properly verify your app’s security at the final stage before deployment.

Coming to the end, I’ll draw your attention to the fact that even the strictest protection won’t help if you aren’t aware of awaiting dangers. The lack of knowledge and consciousness is often used for phishing which may lead to the loss of money or reputation.