Pentesting for Web Applications: Methodologies & Best Practices


Pentest reports are a requirement for many security compliance certifications (such as ISO 27001 and SOC 2), and having regular pentest reports on hand can also signal to high-value customers that you care about the security of your web applications, boosting customer trust and brand loyalty.

Jump to a topic using the links below:

Testing Methodologies

HackerOne’s testing methodologies are grounded in the principles of the OWASP Top 10, Penetration Testing Execution Standard (PTES), Open Source Security Testing Methodology (OSSTM), Council for Registered Ethical Security Testers (CREST) and can be tailored to various assessment types including web applications.

Our methodology is continuously evolving to ensure comprehensive coverage for each pentesting engagement. This approach stems from:

  • Consultations with both internal and external industry experts.
  • Leveraging and adhering to recognized industry standards.
  • Gleaning insights from a vast array of global customer programs, spanning both time-bound and continuous engagements.
  • Detailed analysis of millions of vulnerability reports we receive through our platform (see the Hacktivity page for details).

Threats are constantly evolving, so our methodology can’t remain stagnant. HackerOne’s Delivery team, including experienced Technical Engagement Managers (TEMs), constantly refine and adapt based on feedback and real-world experiences, delivering unparalleled security assurance.

Common Vulnerabilities

Injection

Injection is a wide category of vulnerabilities, which refers to user input data not being properly validated, sanitized, or filtered by the web application before use. Most common injection vulnerabilities include Cross-Site Scripting (XSS), SQL injection, OS Command Injection, and Server Side Template Injection. Injection bugs have severe impacts since they often enable attackers to access sensitive data, execute arbitrary code, or steal private information from authenticated users.

Testing for this type of vulnerability involves a mixture of automated and manual testing of all user-controlled input parameters, such as form submissions, cookies, URL parameters, as well as XML and JSON-encoded user inputs.

Broken Access Control

Broken access control is the current top-runner in OWASP Top 10. It refers to a variety of access control issues in the web application’s business and access control logic, where a user can access data they are not authorized to. Popular examples of broken access control include IDOR (Insecure Direct Object Referencing), privilege escalation, path traversal, and open redirects.

Testing for broken access control requires a careful examination of business logic, analysis of various access levels, and cross-tenant issues in a web application, in combination with powerful automated tools that check for auth issues in each request, such as PortSwigger autorize.

Authentication and authorization are hard to get right, hence the importance of pentests. Our community of ethical hackers is well-versed in testing for access control issues; in fact, it’s the second most frequent type of bug found in HackerOne’s bug bounty programs.

Information Disclosure

Information disclosure often occurs as a consequence of other vulnerabilities, but it can also happen on its own. From misconfigured cloud services (such as AWS S3 buckets and Google Firebase) down to memory issues (such as buffer overreads in edge devices), data leaks can occur anywhere. Failure to implement or enforce access control in REST and GraphQL APIs is another common source of information disclosure, where users can request data belonging to any other entity in the database.

Depending on the sensitivity of the disclosed data, it could be leveraged to perform other attacks (such as CSRF tokens, API keys, and disclosed paths in verbose error messages), or it could create direct business impact and have regulatory implications (such as leaked Personal Identifiable / Health Information).

Vulnerable Components

The supply chain of web application libraries is increasingly complex, involving thousands of frontend and backend components to support the needs of an application. It’s challenging to keep them all patched and working well with each other, which is why using components with known vulnerabilities is a common finding in pentests. Depending on the vulnerability and how the component is used (either directly or as a transitive dependency), it can have serious impacts, ranging from XSS and denial of service to remote code execution.

Testing for vulnerable components, especially finding higher-impact vulnerabilities in backend code is much easier with white-box testing and gray-box testing setups, where the source code and SBOM (Software Bill Of Materials) are provided to pentesters. 

Best Practices

Careful Scoping

Having the right scope is crucial to a successful pentest — what is being tested can be just as important as how it is being tested. Modern web applications can be complex beasts with many different features, subdomains, APIs, and so on. 

Effective pentesting hinges on the strategic selection of targets within the web application. Choosing the right focus can mean the difference between an inconsequential report with few findings (such as testing the frontend form components after a ‘UI Refresh’) and a valuable pentest uncovering high-impact business issues (like examining critical and complex authentication and authorization logic). HackerOne assesses your assets to determine the optimal scope for your pentest and delivers a quote tailored to your specific requirements.

Read the Pre-Pentest Checklist Series Part 1 and Part 2 to address crucial questions before your next pentest.

Skills-Based Tester Matching

Most traditional consultancies and professional service providers rely on a static team of mixed-skilled in-house pentesters or long-term contractors,  who are rostered on and off for every test. These testers are often based on constrained availability within their busy schedules. The result is a mixed bag with inconsistent quality depending on who is doing the current engagement.

With HackerOne Pentest, delivered via a Pentest as a Service (PTaaS) model, customers gain access to a diverse pool of elite, vetted security researchers who bring a wide range of skills, certifications, and experience. The community-driven PTaaS approach delivers comprehensive coverage, versatility, and the highest quality results tailored to the types of assets and technology stacks of your web applications.

Retesting

After identifying and remedying a vulnerability, retesting is crucial to validate the effectiveness of the patch and ensure it is not bypassable. This is particularly vital for organizations with limited security expertise in their development teams. Our pentesters possess extensive experience in bypassing patches and filters even after vulnerabilities have been addressed with incomplete fixes, such as blocking specific payload strings in cases involving injection vulnerabilities. 

HackerOne offers retesting as part of the pentest, and requesting a retest for a vulnerability is as simple as a click of the button in the platform. Customers can request a retest at any point during the testing period and have an additional 60 days after the testing period ends.

Zero Trust Access

Providing restricted access to a testing environment, whether it be an internal application or a restricted sandbox, is always a tricky part of a pentest. For the testing of pre-release web application features, customers may wish to restrict access to the general public and only allow authorized testers into the environment. 

In traditional pentest offerings, this can be a major pain point for both the customer and the testers. Security teams within organizations may reluctantly adjust firewall rules, add additional VPN accounts, and grant access to virtual desktops, ironically compromising their environment’s security to facilitate testing. This has a big impact on pentester productivity, as slow network access and cumbersome configurations quickly drain energy and focus.

HackerOne’s Gateway V2 offers a Zero Trust tunnel using Cloudflare’s WARP technology to connect pentesters in a secure and fast manner to the target assets, along with traditional IP allowlisting rules. It uses a WARP client installed on the tester’s endpoints that authenticates their identity and device to the private network and allows customers to easily grant, revoke, and audit tester access to applications wherever they are in the world. The use of Zero Trust Network Access (ZTNA) for pentesting is a rare sight in traditional pentest offerings or even other PTaaS platforms and greatly enhances both network security and tester productivity during engagements.

Case Study: The Easily Avoidable IDOR

Insecure Direct Object Reference (IDOR) is a low-hanging vulnerability, but it can lead to the biggest impact: often the disclosure of all customer details just by making small changes to a predictable ID. This HackerOne report outlines an IDOR bug that could have led to the disclosure of all user email and phone numbers within a financial web application.

 

 

This bug looks a lot like the major Optus data breach in 2022, where roughly 10 million customers’ PII (such as names, emails, and phone numbers) were stolen in a data breach. The financial impact of the breach was significant, with Optus setting aside AU$140 million (approximately $91.26 million USD) to cover the expected costs of the incident, including customer compensation and remediation efforts. This also resulted in severe legal implications, with an ongoing class action lawsuit against the company claiming that Optus breached consumer and telecommunications law and failed in its duty of care to protect users from harm. 

Optus data breach article

 

Optus data breach code

 

All that from a single IDOR vulnerability that could have been easily discovered and mitigated if a pentest had been conducted by expert web security researchers,  , such as those available in HackerOne’s extensive talent pool.

By utilizing HackerOne’s community-driven pentest for web applications, you can efficiently identify exploitable vulnerabilities such as the IDOR explained above within a matter of days, along with numerous other complex vulnerabilities, within our standard 14-day testing cycle.

Why HackerOne Is the Best Option for Web Pentests

By choosing HackerOne as your partner in pentesting, your organization can fully benefit from the community-driven PTaaS model. This model leverages a combination of HackerOne security experts, who are skill-matched and vetted, working together with your teams to deliver the best overall ROI in risk reduction.

The HackerOne Platform simplifies the process of requesting a new pentest, onboarding new assets, and enlisting expert researchers in just a few days. Its purpose-built UI for reporting vulnerabilities and Zero Trust Access for fast, secure application access make web pentests more seamless and efficient.

With the right blend of people and technology, HackerOne is the ideal choice for your web application pentests. To get started pentesting web applications with HackerOne, contact us today.



Source link