Web Application Security Testing: An Essential Guide
SHARE
back to Guides

Web Application Security Testing: An Essential Guide

Web applications, often in the form of Software as a Service (SaaS), are now the cornerstone for businesses all over the world. SaaS solutions have revolutionised the way they operate and deliver services, and are essential tools in nearly every industry, from finance and banking to healthcare and education.  

Most startup CTOs have an excellent understanding of how to build a highly-functional SaaS businesses but as they’re not security professionals, may have a limited knowledge of how to secure the web application that underpins it.

Why test your web applications?

If you’re a CTO at a startup, you’ll already know that every business – however big or small – is potentially in the firing line. With cyberattacks increasingly automated and indiscriminate, startups are as vulnerable and attractive as big business to hackers scanning the internet looking for flaws.  

It only takes one weakness for your customer data to end up on the internet, and the reputation you’ve taken years to build could be trashed overnight. If you need a reminder that you can’t afford to ignore the security of your web applications, attacks on apps are involved in 26% of all breaches and app security is a major concern for ¾ of enterprises.

Testing is critical for start-ups  

No matter where you are in your web application development, securing your apps doesn’t need to be difficult. It helps to have a bit of background knowledge, so here’s our essential guide to kick start your web app testing programme.

What are the most common web app security vulnerabilities?

Web application vulnerabilities can range from low-risk issues like the disclosure of version information, all the way up to malicious code injection into the core functionality of your application. Here are five of the most common types of attack, and their potential impact:

SQL injection

Where attackers exploit vulnerabilities to execute malicious code in your database, potentially stealing or dumping all your data and accessing everything else on your internal systems by backdooring the server.  

Example: the TalkTalk breach, where 150,000 private data records were stolen, including over 15,000 bank account numbers and sort codes, when TalkTalk took over Tiscali and failed to update its old coding – leaving it open for hackers to access the database using a simple SQL injection.

XSS (cross site scripting)

This is where hackers can target the application’s users and enable them to carry out attacks such as installing trojans and keyloggers, take over user accounts, carry out phishing campaigns or identity theft, especially when used with social engineering.  

Example: When British Airways was attacked by Magecart, a hacker group famous for credit card skimming attacks, the group exploited an XSS vulnerability in a JavaScript library called Feedify, which was used on the British Airway website. Attackers modified the script to send customer data to a malicious server, which used a domain name similar to British Airways. The fake server had an SSL certificate, so users thought they were buying from a secure server. They skimmed credit cards on 380,000 booking transactions before the breach was discovered – leading to a $20m dollar fine.

Path traversal

These allow attackers to read files held on a system, allowing them to read source code, sensitive protected system files, and capture credentials held within configuration files, and can even lead to remote code execution. The impact can range from malware execution to an attacker gaining full control of a compromised machine.

Example: in September 2019, researchers discovered a “critical severity” path traversal vulnerability in Atlassian’s Jira Service Desk Server and Jira Service Desk Data Center that allowed attackers to access information belonging to the company’s customers. Atlassian wasn’t the only company to make news with such a vulnerability. In late September 2019, Adobe released a fix for three vulnerabilities in its ColdFusion platform, including a “critical” directory traversal vulnerability that could allow attackers to bypass access controls.

Broken authentication

This is an umbrella term for weaknesses in session management and credential management, where attackers masquerade as a user and use hijacked session IDs or stolen login credentials to access user accounts and use their permissions to exploit web app vulnerabilities.

Example: Gibson Security revealed vulnerabilities in Snapchat, which was dismissed by the social media platform as a purely theoretical attack. A week later, brute force enumeration had revealed 4.6 million usernames and phone numbers. Why was this significant? The attack seems to have been motivated partly by Snapchat’s assertion that the attack was theoretical, and they had not taken any action. This resulted in a data leakage of phone numbers and users’ details.

Security misconfiguration

These vulnerabilities can include unpatched flaws, expired pages, unprotected files or directories, outdated software, or running software in debug mode.

Example: in 2019 NASA was exposed via default authorization misconfiguration when a security researcher discovered a security misconfiguration in Jira. This single misconfiguration made several Fortune 500 companies (and NASA) vulnerable to a release of personal and corporate data. An authorization misconfiguration in the permissions setting of Jira caused this data disclosure. When the dashboards and filters for the projects or issues were developed in Jira, by default the settings were “All users” and “Everyone”. Rather than sharing roadmap tasks and the like within the organization, it shared them with the public. Lesson learned? Look at the file sharing configurations in every app to make sure confidential data is not revealed publicly.

How can you test for these vulnerabilities?

Web security testing for applications is usually split into two types – vulnerability scanning and penetration testing:

Vulnerability scanners are automated tests that identify vulnerabilities in your web applications and their underlying systems. They’re designed to uncover a range of weaknesses in your apps – due to the frequent changes you have to make in development, and because ports need to be open because of the nature of the app.  

There are many off-the-shelf tools that can do this. Some use static application security testing (SAST) which analyzes program source code to identify security vulnerabilities, others use dynamic security testing (DAST). Both have their advantages, but with its dynamic approach to security testing, DAST can detect a wide range of real world vulnerabilities for web applications.  

It’s capable of detecting all the OWASP Top Ten vulnerabilities and can be used to dynamically check an application’s internal state, based on inputs and outputs, and test your application’s external environment.  

DAST can be used to test any system and API endpoint or web service your application connects to, to test physical infrastructure and host systems (networking, storage, compute), and to test virtual resources such as API endpoints and web services. This makes DAST tools invaluable to developers, but also makes it useful to the wider operations and IT community.

Penetration testing: these manual security tests are much more rigorous, as they’re essentially a controlled form of hacking. They’re therefore recommended to be run alongside vulnerability scanning for more critical applications, especially those undergoing major changes. The tester – known as an ethical hacker – works on behalf of an organisation and looks for vulnerabilities in its systems.

Which web app security testing tool should I choose?

There are many testing tools on the market that use one or more of these tests for different types of applications and test stages. It falls on you and your team to choose the tool or tools that fit your needs, but make sure that you find a tool that doesn’t slow down your development. Here are five of the leading options:

  1. Intruder prioritises results to help users focus on the issues which truly matter. The Intruder API integrates with automated development pipelines, so engineering teams can catch bugs as soon as possible after new deployments, so that security keeps pace with software development. Users can check that what they think was deployed in code is what was actually deployed in the infrastructure and application that is now accessible. Designed to be easy to use, it performs numerous checks, going beyond the OWASP Top 10 vulnerabilities, such as checking for server misconfigurations and injection vulnerabilities.  
  2. Checkmarx SAST is a classic static code scanning tool that finds and fixes low hanging fruit. The scanning capabilities are powerful and it offers opportunities to automate, enabling a DevSecOps pipeline. However, it can return a high number of false positives, especially with Javascript scans, machine changes invalidate the licence, and it’s hard to customise.
  3. Acunetix is an excellent tool for dynamic application security testing and detecting OWASP Top 10 attacks, scaling easily from small web developers to full-scale web application enterprises. However, it can have authentication issues with modern enterprise apps, and it doesn’t meet advanced IAST requirements like business logic errors.
  4. InsightAppSec identifies various API vulnerabilities, detailing which URLs are vulnerable and should be prioritised, and how to mitigate attacks. But the number of features can be overwhelming for beginners, it can be hard to integrate with automated pipelines, and it can have issues with authentication.
  5. OWASP ZAP is a free, open-source solution that includes automatic scanning and is very simple to use, particularly for beginners. However, it's basic scanning implementation functionality is limited, and it comes up short when you need more in-depth reporting, context and actionable results.

What is ‘authenticated’ web application scanning?

Much of your attack surface can be hidden behind a login page. Authenticated web application scanning allows you to find vulnerabilities which exist behind these login pages.

While automated attacks targeting your external systems are highly likely to impact you at some point, a more targeted attack that includes the use of credentials is possible.  

If your application allows anyone on the internet to sign up, then you could easily be exposed. What’s more, the functionality available to authenticated users is often more powerful and sensitive, which means a vulnerability identified in an authenticated part of an application is likely to have a greater impact.

Intruder’s authenticated web app scanner includes a number of key benefits including ease of use, developer integrations, false positive reduction, and remediation advice. You can read more about authenticated web app scanning here.  

Common challenges and FAQs about web app security scanning

How often should I test critical web applications?

Everyone has their own definition of critical, so think about what web applications your business relies on to get things done. It could be your e-commerce site. It could be a behind-the-scenes customer or business partner portal. It could be your marketing site or blog. You should test as often as necessary to ensure that vulnerabilities are discovered in your applications in reasonable time, and that you maintain a secure and robust environment. It’s that simple. Do what’s best for your situation, team and business. If you need more information, we've written a helpful guide on the frequency of vulnerability scanning.

Could I damage my app with a security scan?

A scanner will send thousands of requests of known types of issues to see if it can find a weakness, but doing this in a production environment can delete data, leave thousands of unwanted entries in databases, or order thousands of products. For this reason, we always recommend testing in a dedicated testing environment and ensuring users have appropriate permissions.

Can I scan my single-page-application?

A single page application (SPA) is a website or web application that dynamically rewrites a current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. You’ll have seen examples in Gmail, Google Maps, Airbnb, Netflix, Pinterest and PayPal. Intruder’s scanning engine handles unauthenticated parts of SPAs by fetching the application and running it within a headless browser; it then manipulates the Document Object Model (DOM) and attempts to follow any links it finds – recording a list of paths and parameters for further analysis.

What if my web application has complicated workflows?

This is an area where automated tools can struggle. They are good at crawling (also known as spidering) for pages and submitting forms, but where multi-step forms come in, the scanners can find them difficult to navigate. It’s important to remember that these automated scans are good, but they are not bulletproof, so we recommend continuous penetration testing as well.

How often should I get a penetration test?

Start-ups or small businesses rarely understand the need for a manual penetration test or can afford one. For this reason, most compliance requirements only expect them to be run once a year (the PCI Data Security Standard requires one after every significant change).  

Ultimately you need a process in your organisation to decide whether a change is significant enough for a pentest; but bear in mind that even the slightest change can cause a security weakness. With agile development, it’s unrealistic to run a pentest after every change, so it’s important to:

What if I’m using someone else’s web application, should I test that too?

Simple answer? No. For example, if you’re using Salesforce for your CRM, it’s their job to make their application secure, so you don’t have to. In fact, testing their app behind the login will at least annoy them, and could potentially be illegal. Many software vendors forbid this type of activity. The best way to ensure the security of these applications is to ask for their security certifications such as:

How do I get started?

Web app security is a journey and can’t be ‘baked-in’ retrospectively to your application just before release. Embed testing with a vulnerability scanner throughout your entire development lifecycle to help find and fix problems earlier.  

This approach allows you and your developers to deliver clean and safe code, accelerates the development lifecycle, and improves the overall reliability and maintainability of your application.  

But testing earlier and faster is nearly impossible without automation. Intruder’s automated web application scanner is available to try for free before you buy. Sign up to a free trial today and experience it firsthand.

Want to find out more?

Get in touch to schedule a demo or send us a message in the chat bubble, we’d be happy to help.

Don’t have time to read the whole guide right now?
Get a copy sent to your inbox and read it when it’s convenient for you. Just let us know where to send it (only takes a few seconds).
Contents

Written by

James Harrison

Ready to get started with your 14-day trial?

try for free