News

The Complex World of Web Application Security Testing – Part One by Nithiya Subramanian and Shruthi Jagadeesh

In the first of this two-part blog, Triad consultants Nithiya Subramanian and Shruthi Jagadeesh break down the often-complex world of Web Application Security testing.

We recently created a digital service for the Department for Transport (DfT). Built to GDS (Government Digital Service) standards, we used multiple system testing approaches including manual testing, UI automation testing (using BDD framework with Selenium and Specflow), and API automation (using RestSharp and BDD). An accessibility audit was conducted with automation and manual testing using the Axe dev tool and WCAG colour contrast checker. This service underwent security penetration testing by a third-party tester; however, we also conducted web security testing ourselves, which is how we came to write this blog.

A blog of two halves

Researching and testing a variety of web security tools was a fascinating process. But also an in-depth one. We have split this blog into two parts to make it easier on the eye.

In part one, we explain the research and preparation that we did to understand the features that would be important for us in a Web Application Security tool. We also break down the complex world of web security testing to explain some key phrases and testing methods you should know.

Spoiler alert! In part two, we walk you through the four tools that fit our criteria and explain the pros and cons of each before highlighting the web security tool that we think did the best job for us.

Let’s get stuck in, shall we?

What is Web Application Security testing?

Web Application Security testing evaluates web application security for weaknesses, technical flaws, and vulnerabilities to prevent malware, data breaches, and other cyberattacks that might lead to an information leak, crash, or present unexpected behaviour.

We had built a system for the DfT that we believed would be secure. Still, we needed to be certain that it couldn’t be compromised and, equally important, we wanted to identify where any vulnerabilities lay.

Popular Web Application Security testing methods

When it comes to Web Application Security testing, you can assess a variety of things. Here are the things that we identified as important:

  • Risk Assessment – The security risks facing the app, software or network are identified, analysed, and classified (as Critical, High, Medium, or Low) so that one can assign priority to appropriate mitigation measures and controls.
  • Ethical Hacking – This is an umbrella term to describe the practice of testing a system’s security. It includes many hacking methods that an otherwise unscrupulous hacker might use.
  • Vulnerability Scanning – We do this to identify known loopholes and vulnerability signatures. It helps us gain an understanding of the baseline security risk.
  • Security Scanning – This identifies vulnerabilities and misconfigurations in the app or software, network, and systems. Both manual and automated tools are used for this type of test.
  • Security Audit/Review – This is a structured process to review or audit the app or software against defined standards. Through gap analysis and code/design reviews, we can assess the security of the physical configurations, operating system, information handling processes and user practices. We would also assess compliance with regulatory standards and frameworks.
  • Penetration Testing –This simulates a real-time cyberattack against an app, software, system, or network under secure conditions.
  • Posture Assessment – This is a kind of catch-all when the organisation’s overall security position or posture is assessed using a combination of security scanning, ethical hacking, and risk assessment.

Important Web Application Security terms

If you are new to it, then the world of web security testing can sound complicated. Here are some phrases that we think you should know:

  • Authentication – Authentication is how we identify a unique individual (or service account) using credentials or ‘keys’ to control access to the account.
  • Authorisation – This is how we determine whether an authenticated user or account should have access to a specific system, and if so, what they should have access to, including whether they can modify data or access certain files. Authorisation can be implemented in several ways, including access control lists, role-based access control (RBAC), and user or group mappings. Each typically defines the permissions & restrictions a specific user or group has by either granting or restricting permissions specific to the system.
  • Availability – Availability is often described as a target % (e.g., 99.9% available), which indicates the time a system is expected to be fully functional for end users. This may or may not exclude maintenance windows, which are scheduled downtime where system owners apply necessary updates and patches.
  • Confidentiality – The term ‘confidentiality’ is a bit misleading. It relates to ‘who’ has access to ‘what’. By testing the confidentiality attribute, we can see whether information, services, and resources are accessible only to intended users and only when appropriate. Encryption, multi-factor authentication, and the use of digital keys helps to ensure the confidentiality of data.
  • Integrity – This is how we assess whether the data we have received is well-formed. What we are really checking is whether it has arrived as intended or if it has been altered during transit. We will also check whether the correct information is presented to users in accordance with their user privileges and restrictions.
  • Resilience – This term describes how resilient the system is to attack and if it can continue operating throughout an attack.
  •  Non-repudiation – A widely used legal concept within information security, it relates to a service providing proof of the origin and integrity of data. Non-repudiation ensures no party can deny sending or receiving a communication using encryption and digital signatures.

Features to look for in a Web Application Security product

Between them, Web Security Application products cover a wide variety of features. We created this list to help us identify the features that we wanted to use when security testing the digital service:

  • Automatic scanning – This is when the web security product sends a spider to crawl the web application and passively scans each page it finds. This type of scanning is very quick. It is good at identifying and assessing vulnerabilities. Providing confidence in the basic security state of a web application, it identifies where more investigation may be warranted.
  • Manual scanning – Tools with a manual scanning feature allow testers to drive specific pages interactively whilst the tool continues to scan. This is particularly useful for pages protected by login or where using real data is beneficial for the test. Automated spiders are a great way to explore your site, but they should be combined with manual exploration to be more effective.
  • Support for authentication – Authentication is a keyway of restricting access to an application. Most applications protect their main functionality using authentication. If a tool cannot authenticate to the application, then it will not be able to automatically find the most interesting and impactful vulnerabilities. Some authentication mechanisms also make it significantly harder to use security testing tools, even for people with permission to use them.
  • Powerful AJAX spiders – AJAX spiders are an effective tool for detecting requests in AJAX rich web applications. These spiders explore the web application by invoking browsers, which then follow the links that have been generated.
  • Multi-platform support – It was important that the tool could be easily installed and used on major OS such as Windows and Linux. It is particularly important in the modern world of web development for the tool to support testing for web, mobile and API assets hosted in public and private cloud environments.
  • Comprehensive test report – A record of requests and responses sent to each page with enough information on the vulnerability alert and references that could help the developer understand and fix the issue. We were particularly keen to identify tools to customise the report to our needs.
  • GUI support – A desktop UI for non-technical users to use. Many tools on the market are command line based and more difficult to learn and operate. Check whether comprehensive documentation is available to help new team members understand and use the tool efficiently.
  • SQL Injection Testing SQL injection is a major concern when developing a Web application. It occurs when the application accepts a malicious user input and then uses it as part of a SQL statement to query a backend database. A successful SQL injection exploit can read sensitive data from the database, modify database data (insert, update, or delete), or even execute administrative operations on a database. So, it is important to cover this attack in security testing.
  • DevOps integration – Whilst DevOps is now a common approach and practice, DevSecOps is still maturing. Security should be ‘shifted as left’ as possible. Security testing should be part of your process to achieve a far more secure application. Security tools should have some form of plugin to integrate with common automation tools such as Jenkins and/or cloud-based CI/CD pipelines.
  • Automation – The tool should provide the opportunity for automation so security testing can be added to test suites and automated within the CI/CD pipeline. With the help of this kind of approach, everyone in the team becomes aware of security issues as soon as they materialise (lower cost of remediation).

Ready for more?

In part two of this blog, we will walk you through the four tools that matched our criteria. We explain the pros and cons of each, before highlighting the web security tool that we think did the best job for us. You can read it here.

We hope that you have found our blog of two halves useful. If you are interested in security testing or have a question for the Triad Automation test team, please get in touch.