Back to all blogposts

Web application security testing and its role in Quality Assurance

Adam Gola

Adam Gola

QA Engineer

I will tell you a real-life story about security testing. The one I faced at The Software House. I believe that it’ll help you understand why it’s so important to introduce software security testing in your projects. One day, a client asked us to perform business analysis and code analysis, including efficiency and security audits. He was himself aware that his app may be full of vulnerabilities, so for me, as a QA tester, it was obvious that I must be prepared for thorough security testing. I had very limited time to act, but I managed to take care of everything. Below, I’ll show you, step by step, how I approached this task and what were the results. 

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.

A photo of a person looking for a laptop screen with credit card in hand
Some applications have payment systems built-in which is pretty crucial when it comes to application security testing

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.

See also: Check out how to use Kakunin to speed up your automated test? 👇

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. 

The screenshot presents an example of Cross-Site Scripting
Cross-Site Scripting example

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.

See also: Not enough QA? Introduce quality standards in software 👇

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.

At The Software House, we always do our best to make sure all the applications have the highest level of security 🙋🏼‍♂️

All the projects we work on must undergo thorough analysis from all the major perspectives: business and functional but also security. Book a free one-hour consultation and learn more. ☎️

CTO vs Status Quo

Find the exact rules Tech Managers used to organize IT & deliver solutions the Board praised.

Read here

The Software House is promoting EU projects and driving innovation with the support of EU funds

What would you like to do?

    Your personal data will be processed in order to handle your question, and their administrator will be The Software House sp. z o.o. with its registered office in Gliwice. Other information regarding the processing of personal data, including information on your rights, can be found in our Privacy Policy.

    This site is protected by reCAPTCHA and the Google
    Privacy Policy and Terms of Service apply.

    We regard the TSH team as co-founders in our business. The entire team from The Software House has invested an incredible amount of time to truly understand our business, our users and their needs.

    Eyass Shakrah

    Co-Founder of Pet Media Group


    Thank you for your inquiry!

    We'll be back to you shortly to discuss your needs in more detail.