Application Pen Testing Methodology

Application Pen Testing Methodology

A Web Application Hacker’s Methodology: Steps to Expose Vulnerabilities

Application penetration testing is an art and a science. Experienced penetration testers understand and employ the mindset and techniques that hackers use to expose vulnerabilities in applications before hackers find them.

Contact A Penetration Testing Expert

The following proven methodology, borrowed from the Web Application Hacker’s Handbook (2011 edition) covers all the key regions of a web application’s attack surface step-by-step. Comprehensive penetration testing will assess and attack each of these areas, ensuring that as many issues as possible are uncovered.

      1. Map the Application’s Content
        After configuring your browser with a proxy/spidering tool, browse the application. Visit every link and URL, submit every form, and complete all multistep functions. Create a login if the application uses authentication. As you browse, monitor the requests and responses passing through the proxy to see what kinds of data are being submitted and how the browser controls the application. Use both manual/passive and automated/active spidering, and also consult system documentation and/or public resources. This approach should reveal not only visible content but also some hidden and default content.
      2. Analyze the Application
        Identify all core and peripheral actions that the application was created to perform and how it was intended to be used. This includes identifying its core security mechanisms (authentication, session management and access control) and how they work. In this way you map the application’s attack surface and can formulate the best approach to assess the application..
      3. Test Client-Side Controls
        Client-side controls include ways that data is transmitted to the server via the client, client-side input controls, and “thick client” components like Java applets, ActiveX controls, and Flash. The goal is to pinpoint what purpose each item serves within the application’s logic, based on its context, name, and value. By submitting arbitrary values, for example, you can try to interfere with the application’s logic or undermine security controls—even if items are encrypted.
      4. Test the Authentication Mechanism
        To test the authentication mechanism, you first need to identify the technologies used (forms, certificates, multi-factor) and locate all the authentication-related functions (login, registration, etc.) Is there a way to obtain multiple user accounts? From there you can launch direct attacks to test password and username, “remember me”, credential handling, and other authentication logic.
      5. Test the Session Management Mechanism
        How does the application manage the requests it receives from users? How does it re-identify users? Is token transmission and/or logging secure? Test how tokens map to sessions, how sessions terminate, how (and if) cookies are configured, and so on. Are all the bytes within a token used to determine session state?
      6. Test Access Controls
        Access controls work on two levels: different levels of users being given access to different application functions (vertical segregation) and users with similar privileges being given access to different subsets of data (horizontal segregation). Usually both types are used. Once you’ve mapped the application you can begin to identify the functional areas and data resources at which to direct privilege escalation attacks. Ideally you’ll want to test for insecure access controls using multiple accounts with different privileges. As this area is hard to automate, this will predominantly involve manual testing.
      7. Test for Input-Based Vulnerabilities
        Unpredicted user input can trigger a range of vulnerabilities from anywhere within the application. To probe for these vulnerabilities, hit every parameter for every request with a set of attack strings (SQL injection, XSS and response injection, script injection, etc.). This is most effectively done in an automated manner leveraging an appropriate tool.
      8. Test for Function-Specific Input Vulnerabilities
        Besides input functionality, a wide range of other functions can offer vulnerabilities. After assessing the application’s attack surface you can identify the most likely areas on which to focus testing. Attack vectors include SMTP injection, SOAP injection, LDAP injection, and so on.
      9. Test for Logic Flaws
        Exploitable logic flaws can occur anywhere in the application in one form or another. So once again, you need to start by identifying a reasonable attack surface to target with manual testing. This is likely to include: critical security functions (e.g., login), multi-stage processes, transitions across “trust boundaries” (e.g., moving from being anonymous to being logged in), opportunities for incomplete input, and transaction logic around prices, quantities, etc.
      10. Test for Shared Hosting Vulnerabilities
        If an application is hosted on shared infrastructure, such as a public cloud, you can probe the access mechanisms that the hosting provider has set up to enable its customers to manage their web application content and functionality. Does the facility use a secure protocol and hardened infrastructure? Can customers access resources beyond what they legitimately need to access? Can customers execute arbitrary commands within the hosting environment? You may also be able to target an application the ASP uses to allow customers to configure a shared environment, thus compromising the environment itself. If segregation is inadequate, you may be able to exploit more than one application within the ASP’s environment.
      11. Test for Web and Application Server Vulnerabilities
        Through application mapping you can identify the web server and other technologies in use by the application, which could contain vulnerable administrative interface. Test (or guess) default ports, default passwords, and other credentials. Check for vulnerabilities in HTTP methods, proxy functionality, virtual hosting configurations, and web server bugs. If you can compromise an administrative interface, review its capabilities to see whether it can be used to attack the target application.
      12. Miscellaneous Checks
        Other attacks options you can test for include: Document Object Model (DOM) based attacks based on XSS or redirection vulnerabilities within JavaScript received from the application, frame injection, local privacy vulnerabilities, information leakage, or weak SSL ciphers. OWASP is a good reference to ensure that you have tested all key weaknesses (e.g., the OWASP Top 10.)

By simulating a real-world attack by a determined hacker, hands-on web application penetration testing is a great mechanism to assess the level of risk your organization faces. It can detect vulnerabilities to SQL injection, broken authentication and session management, insecure DOM references, cross-site scripting, and others. Contact Pivot Point Security to discuss how penetration testing can benefit your company.