1. Webapp Checklist

Webapp Penetration Test Checklist

todo - add explainers for the major tools and methods described here. Maybe as separate Obsidian docs linked in here with the double-brackets notation. Just go for it and let us know what you add once you’ve added it.

---

One week before the test

• Verify that you have access to the sites being tested.
• Verify that any test credentials are good and cover the expected roles
• Start the report in SharePoint by using the “New…” button in the project’s folder and choosing the pentest report template. Update the filename to match the standard: ${CustomerName}-${TestType}-${Date}.docx
• Start the “Web Application Penetration Test” section with a brief description of the webapp (its name, what service it offers, who uses it, whether you’re testing in prod or some other region) the starting URL, and…
  • a screenshot of the site’s landing page.
    • not a bare login form - you want something so that a reader who knows the application by another name can quickly see what it was you tested.

Day One - Webapp Recon

• Review the ROE notes to be sure you meet customer expectations for the test and for communication during the test.
• Identify all listening network services on the web servers. Investigate anything that’s not HTTP/HTTPS
  • Something like nmap -sV -sC -oA nmap_results --resolve-all -v example.com
• • Run Nikto to discover misconfigurations or common weaknesses
    • Do not run Nikto on Kali as it is broken; always use the GitHub version: https://github.com/sullo/nikto
    • Know how the server responds to “file not found” requests so you can tune nikto as needed by using -404code or -404string if necessary.
    • The following command will run against the target, create an output HTML named with the target information, and create a “savedir” that will have the full request/response (JSON) for any findings: ./nikto.pl -h https://example.com/ -o . -S . -F htm
    • During the scan, status can be seen by pressing the space bar, verbose mode enabled/disabled by pressing v, or debug mode enabled/disabled by pressing d
• Scan for TLS configuration weaknesses. Use Qualys SSL Server Test or testssl.sh or similar.
• Identify third party components in use. If you use Wappalyzer for this, be sure that you have it set to NOT phone home with every URL you visit.
• Look at Nuclei here, too.
• Make note of any Security Headers (and remember that they can be different on different resources: a public scanner won’t notice what happens after authentication.)

User Accounts, Authentication, Session Management

• By process of elimination, determine which cookie or request header identifies the user’s session (i.e. the thing that, when omitted, sends you back to the login page or similar). It may not be a cookie, and there may be more than one.
• Document the session timeout duration.
• Test any account recovery / “forgot my password” functions.
• Establish what the password policy is
  • then make sure it is enforced
• Test for rate limiting, captcha, or other login brute-force prevention mechanism.
• Try password spraying, credential stuffing (if creds available from breach data / wherever)
• Test the login sequence.
• Check for username enumeration.
• Check whether session tokens have any embedded meaning or patterns that could be exploited in any way.
• Check for session fixation. When you manually set a session token, be sure it follows the syntax of a real token (e.g. if the app uses 32-character lower-case strings, then you should use a 32-character lower-case hex string, too. Try one you get from the server in an unauthenticated session and also try just making one up that fits the pattern.)
• Test any features related to creating or modifying user accounts.

Test Authorization / Privilege Separation

• Make sure restrictions are enforced, and enforced on the server.
• Include all privilege levels, INCLUDING unauthenticated.
• Autorize and AuthMatrix can help with coverage, here.

Understand the Application

• “Click every link and submit every form” (within reason - you don’t need to add every single product to your shopping cart.)
• Use the application as a normal user would in order to understand what it does and how it works.
  • Proxy thru Burp Suite during this phase so you have a record of all the traffic for a baseline.
• Make note of any “risky” or “expensive” operations to return to later for testing.
  • Risky includes changes in privilege levels, file uploads, adding user-generated content, etc.
  • Expensive includes things that take a lot of processing time or power, things that move monetary value around, things that cost real money, etc.
• Look for unique or unusual functions and behaviors.
  • Also third-party components, frameworks. Wappalyzer may help identify some of these.
    • example: Telerik
  • Also, where the UI varies - maybe old code / new code, maybe “this is client-side JS, and that is not”
• Look for enumerable identifiers (integers, usernames, dates, “business function names”) as a target for IDOR and others.
  • High-entropy GUIDS are not a security control. Just ‘cause you can’t guess it, doesn’t mean it’s not IDOR.
    • If the GUID is as protected as the session cookie is, then maybe it’s OK. But that’s rare.
• Determine the technology stack in use so you can target future attacks
  • Server-side attacks depend on server-side functionality, as one example

Content Discovery

Do this AFTER “Understand the application” (else, how do you know you’re “discovering” something?)

• Gobuster, dirbuster, feroxbuster … Intruder w/ a raft list… use what you like.

Test What You Found

• Review your list of risky or expensive operations and test them.
• Use targeted vulnerability scans in Burp Suite by way of Intruder’s “Scan Defined Insertion Points” function in the context menu.
• Run AppScan against the site (or key sections of the site) once you know how the site works. Try to have a separate set of credentials for this to avoid side-effects of using the same account in different contexts.
• Weed out false positives from scanning results.

File Upload

• If the app has file upload capability…
• Understand how it is used: what kinds of files are expected? How are those files used? Who does what with those files afterwards?
• If it’s retrievable but not in web_root, is there LFI?
• Check for file type restrictions (not just by extension or mime type)
  • Try to bypass those
• Can you access an uploaded file, as auth or unauth user?
  • Burp Upload Scanner is nice, (and very comprehensive … LOTS of traffic, here, may need a video or detailed explanation)
• Look for interesting / dangerous file types
  • CSV? Formula Injection, maybe
  • Executables? Malware
• Ask customer to participate in these, if the file is used by some back-end service or person.
  • Upload a “poisoned” file, (whatever that means in your context) and ask them to open it. See if you get callbacks, etc.

Do you need special tools?

• WPScan for WordPress, for example.
• Know the technology stack. Investigate each part.
  • What tools are there for those?
  • Look for CVEs, and recent exposures
  • Share what you learn! Maybe even right here!
• Does it generate a PDF?
  • maybe include HTML or JS that gets included in the file
    • Server may use headless Chrome to render as HTML then save as PDF.
    • So, try HTML and JavaScript stuff here.

Exploiting Vulnerabilities

• “Show the impact” of any vulnerability as best you can in the time you have.
  • BUT - constrain yourself to the webapp, unless the customer has asked you to go farther.
    • Your customer is usually the dev team who builds the webapp.
    • Don’t waste time exploiting infrastructure or poking at things that a dev team would not be in a position to fix.
• Understand the control you’re trying to bypass. Don’t jump to a full exploit before you know what the “rules” are meant to be.
  • e.g. filters: what do they accept? what do they reject?
  • e.g. Burp Collaborator - what kinds of requests do you see? What can you do with those? (if just DNS, probably not much) but see how far you can go, step by step.
• Can you create your own local instance of the technology?
  • this tells you a TON about what’s in the app, what to target (e.g. what files exist that aren’t obvious)
  • Basic one: install WordPress
    • Make a list of every file it installs
    • Look for each of those on your target