A web application penetration test takes a look at the security of external or internal application for your organization. This type of testing goes above and beyond standard network-level penetration testing, focusing on the both the unauthenticated and authenticated portions of a website. But why do web application penetration testing? What threats are you addressing for the cost of a web application penetration test? What questions does this type of testing answer for an organization or concerned CISO? We’re often asked what type of testing will answer some of these exact questions, so we decided to compile a list of the top 10 questions answered by a web application penetration test.
1. Can an unauthorized individual break into my application?
This may seem obvious, but it’s also one of the highest risks to any application that’s available on the Internet. The second part of this question which helps put the risk in context is if they do get in, what information can they gain access to/exfiltrate?
2. Is any sensitive information stored in the application being disclosed publicly to unauthenticated users?
You’d be amazed at how many penetration tests we’ve done reveal misconfigurations that result in databases or folders being shared openly. A lot of times, these shares contain sensitive information such as health information (ePHI), personally identifiable information (PII), user credentials, credit card data (PCI), etc. It doesn’t have to be a sophisticated attack that compromises your application, many times. An impartial set of eyes helps reliably uncover these types of issues.
3. In a multi-tenant application, can one organizational user access the information of another organization?
Web application penetration testing will cover information disclosure/bleed between tenants in a shared application space. Oftentimes, for SaaS providers specifically, this can be the worst-case scenario. Where one authenticated user to your application can see the data of another user or organization within the application.
4. Can a low-level user escalate their privileges to that of an application administrator?
This can be referred to as “vertical movement.” Can a user become an administrator or take administrative actions within the app? This can lead to confidentiality, integrity, and availability issues. These vulnerabilities can also increase the severity of other vulnerabilities discovered. For example, its bad if an unauthorized individual can gain access to the application as a low level user. It’s worse if that user can then escalate their privileges and become an administrator.
5. Can one user view/modify the information of another user?
Conversely, this is “horizontal movement.” Can one user become another user or take actions on their behalf? If you were a user of a banking website and some other user could transfer money out of your account, that’d be pretty scary right?
6. Can a user trick the website into giving them free services/products?
For e-commerce websites, this is a significant concern. Can a user change the pricing information of products? Web application penetration testing will identify logic errors and other issues that could allow a user to bypass certain protections or controls. Is a user able to break out of sequential process (e.g. choose a car -> pass a credit check -> pay for car -> receive car)? Or maybe a user can modify certain web requests to only pay $1 for a $500 item?
7. Can an external attacker or user gain access to the underlying web server?
Could this application be used as an entry point to your organization’s internal network? Many application-layer vulnerabilities can quickly turn your web application into foothold on the internal network for an external attacker. Injection style attacks, Server-side template injection, command execution, etc. can all provide access to the underlying host.
8. Can this application be used to gather information that can be used in other attacks on your organization?
Certain weaknesses in your application could allow it to be used as a weapon against your organization. Some misconfigurations could allow it to be used as a piece of a social engineering attack. Username enumeration on your application could allow me to build a list of your users that I can then use for password attacks on your other externally exposed services.
9. Can an attacker deface the site in any way that would potentially harm your organization’s brand image?
This could be concerned less concerning than a lot of the other questions posed here, but for some organizations, this can be just as important. If an attacker is able to compromise your website, even if that can’t gain access to any sensitive data, public defacement could cause immediate negative effects to brand image, shareholder confidence, etc. If you had the choice of using Amazon or Microsoft for web hosting services, and one of them suddenly had unsavory images and content all over their main website, it would probably affect your decision.
10. Is the web server configured according to security best practice?
This is important not just for overall security posture, but also for compliance. Host server and web server configurations can not only provide defense in depth for you applications, but they are also important for a lot of organizations to maintain compliance with required standards, such as HIPAA or PCI. While SSLv3 being enabled definitely has some security implications, it could be more important for a lot of companies because it would cause a PCI DSS compliance failure.
If you’re interested in reading more about how we methodically answer each of these questions (and many others), take a look at our testing methodology. And as always, leave a comment below if you’ve got any other questions we can help answer.