aex.red

Web Application

Test Details

  • Project Number:

  • Target List:

  • Date of Test:

Test Accounts

user1:password1 admin1:password1

Notes

Using SublimeText3 .txt files with colour theme set:

  • vulnerabilities are highlighted red (anything that follows a *space or *tab)
  • vulnerabilities that have been resolved/false positives investigated ! warnings are highlighted orange (anything that follows a !space or !tab) ? questions or things you need to get back to have a yellow background (anything that follows a ?space or ?tab)

Scope

Paste scope here

Tools

https://github.com/fuzzdb-project/fuzzdb https://github.com/projectdiscovery/nuclei

Pre Test Checks

  • Check the SOW/quote for additional details on the test:

  • Read all previous emails related to test:

  • Check previous year’s report if exists:

  • Ensure logging is enabled on all relevant tools:

Reconnaissance

  • robots.txt:

  • ffuf/dirbuster/gobuster/dirb: 80/tcp

    443/tcp

ffuf -w /path/to/wordlist -u https://target/FUZZ

https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content

  • Manually walk the web application (unauthenticated) and view in Burp: Notes, general functions, search functions, interesting inputs/parameters/cookies

Scanning

  • Burp Scanner:

  • Qualys:

  • Nessus:

  • Nikto: 80/tcp

    443/tcp

  • nmap (with URL): TCP

    UDP

  • SSLScan/TestSSL:

  • CMS Scan:

  • Nuclei:

Information Gathering

  • Identify the IP Address of the Server (ping):

  • Spider the application: Target > Sitemap > Right click, Scan > Crawl, leave running for 1 hour at the start of the test while you are walking the application

  • Server Response Headers: Unauthenticated:

    Authenticated:

  • Missing or Misconfigured Security Headers: output: headers set by the app and headers not set by the app

  • Identify Authentication Types (Admin, User, etc.):

  • Analyse Error Application Messages (Check for Default error messages and information disclosure): output: error code, path to replicate error

  • Inspect Source Code for Information Leakage (View page source, search for comments, username, password etc. Do this also for custom scripts): output: path of code analyzed, information leaked

  • Look for sensitive information in hidden fields (View page source, search for hidden fields): output: path to form, hidden parameter name

  • Look for form auto complete (Register, Login and Forgot Password forms username field): output: path to form

  • Enumerate HTTP Methods (OPTIONS):

  • Manually attempt to exploit insecure HTTP Methods (e.g. PUT, TRACE - Qualys):

  • Any third party scripts (Burp):

  • Review all JS files on the server Proxy > HTTP History > Change filter to only show js files

  • Look for any software versions:

  • Of the software versions found, are any outdated or obsolete, any vulnerabilities:

  • Any insecure protocls/ciphers (sslscan):

  • Contact Form spammable?

  • Any input reflection?

  • If registration page exists register with a pentest@burpcollaborator.net url Check to see if the SMTP request reveals any sensitive information like software version, internal ip addresses etc

  • If registration exists, can you register an existing account and hijack? Only useful if you know the target account name

Authentication

  • Ensure Authentication is over an encrypted connection (HTTPS?):

  • Check for default passwords (Google the software default creds, and try Admin / Admin etc.):

  • Test for fail open (Send request without password field using Burp, delete password field): output: BR number

  • Test for enumeration on login, forgot password and register (Different errors when an account exits / doesn’t. Burp Comparer also): output: path to form

  • Check Open Redirect https://www.example.com/login.html?RelayState=http%3A%2F%2Fevilsite.com%2Fnext

  • Test that the forgot password link sends new password over encrypted connection:

  • Test validity of time and number of uses on forgot password link:

  • Check password strength and entropy of unique characters (Minimum 10 characters, also suggest using a passphrase): output: password policy

  • Check for forced browsing (attempt to find sensitive areas of application via URLS for example without having to authenticate): output: path to URL accessible through forced browsing, authentication used

  • Test CAPTCHA replay and fail-open if CAPTCHA is enabled: output: BR number

  • Look for ‘Remember Me’ function (if found, login then close and reopen the browser to see if you’re still logged in):

  • Check current password is required to change password:

  • Brute force own account to test lockout (leave until the end, Burp Intruder): output: number of requests before lockout

Session Management

  • Identify the session cookie(s):

  • Analyze cookies and check no sensitive information is passed in them (username, email etc.):

  • Check for predictable session cookies (sequencer): Send a cookie that is set upon login to sequencer and run for at least 10000 requests, entropy needs to be over 100

  • Check session cookie attributes: secure, HTTPOnly, samesite, domain and path: output: cookie name, attributes set

  • Check for session fixation, including remote session fixation (Whether or not the cookie value changes dependant on the user authenticating or not): output: BR numbers

  • Check for Persistent sessions via Cookies (is cookie set with an expiry date that results in user getting automatically re-logged into app upon closing and reopening browser?)

  • Test for Cross Site Request Forgery: output: path to form with CSRF, Request in repeater

  • What happens if you remove / send blank CSRF token or one with the same length?

  • Send CSRF tokens to Burp Sequencer

  • Test for On-Site Request Forgery (user input reflected inside a hyperlink or img tag):

  • Test for Cross-Origin Resource Sharing (access-control-allow-origin header in responses):

  • Check sensitive information is not transmitted via GET requests (Sensitive info in URL): output: BR number, parameter

  • Check logout button exists on all authenticated pages:

  • Can you place a URL in your profile? Malicious embedded URL or even stored XSS?

  • Test for concurrent user sessions:

  • Check idle timeout duration: output: how long it was left for

  • Ensure cache controls are sufficient (Client side caching etc):

  • Test forced browsing between users and user types: output: BR number, path for forced browsing, authentication used

  • Test for other horizontal and vertical privilege escalation: Can you update another users account with IDOR? What happens when you change your email to an account that already exists?

  • Check access controls are not implemented through GET or POST parameters: output: BR number

  • Check access controls are not implemented through referer header: output: BR number

  • Check access controls are not implemented through hidden fields:

  • Use Burp Search to look for any hidden elements by using type=“hidden” or display=“none”:

  • Check that session token is deleted client and server side after logout: output: BR number

Access Logic

  • Use Burp Compare Sitemaps as two different users Check inconsitencies, especially anything potentially sensitive

  • Use Burp Autorize plugin (only if admin access has been provided.) Login to the target application as a low privileged user, go to authorize tab in burp - autorize should be off Click Configuration Click Fetch cookies from last request Open incognito window Login as high privileged user Click Autorize is off to turn it on Go to areas of site that are admin only Look for orange/green in the columns Request unique URLs within the browser for the low privilidged user

  • Test for IDOR (Burp Target Analyser) Target> Right click, Engagement Tools> Analyse Target Are there any values like uid=1, id=1234, paths such as /profile/user/51231

JWT Tests

  • Test token expiration (exp field) - Check suitable expiration time is set.

  • NONE hashing algorithm - test via Burp json-web-tokens extension

  • Token Sidejacking - check for user context inside the token

  • Token explicit revocation by the user - Check if the token is invalidated on logout.

  • Token information disclosure - Check for any sensitive user information disclosed inside the token.

  • Token storage on client side - Check browser storage to see how token is stored.

  • Token weak secret - Brute-force JWT private keys (when signed with HS256 (HMAC) hashing algorithm)

  • Key confusion - attempt to change algorithm from RS256 to HS256 using Burp JOSEPH extension

    • RSA key pair might be the same as the TLS web server. Use this to retrieve: openssl s_client -connect target.com:443 | openssl x509 -pubkey -noout

  • Check that tokens are signed on the server-side and not client-side code (i.e. where the token originates)

    • If client side this suggests a hard-coded key

  • Check decrypted JWT for ‘jku’ header - If found browse to URL for public key that verifies the token

  • Check for the ‘kid’ header. If found try looking for the key name/id in the webroot (domain/kid)

OAuth Tests

  • Check SSL/TLS is in place for all OAuth requests output: BR number

  • Check whether service provider’s Authorisation server is checking value of “redirect_uri” parameter before redirecting output: BR number

  • Check lifetime of Temporary Authorisation Code

  • Check for CSRF linking of client app and service-provider accounts output: BR number / repeater request

  • Check whether Temporary Authorisation Token can be replayed to authorisation server to gain new access token output: BR number

  • Check expiry of Refresh Token and Access Token

  • Check whether the authorisation server is vulnerable to a Grant-Type “Downgrade” attack (change response_type parameter to token)

  • Check that the state parameter is set on the request to authorisation server (random string for validation)

  • Check for the existence of handle-based tokens (random strings) over self-contained tokens (JWTs) - handle-based is prefered

  • Check storage method for any tokens that are issued (cookies vs local storage vs browser memory)

  • Check for the existence of rate-limiting on the token/exchange endpoint

  • Check that the client_ID is bound to the authorisation code (attempt to change client ID in the request to the authorisation server)

  • Check for the existence of a code_verifier (for authorisation server to validate integrity of authorisation code)

File Upload Tests

! Not all tests apply, these are just to get you thinking.

  • Check for file upload facility and upload all standard test files output: path to file upload, list of test files successfully uploaded

  • Use the mime type wordlists along with the mime type file extension wordlist to check if only certain file types are being blacklisted Place payload markers on the file extension of the file and also the mime type, ie it should be .html and text/html for example. Select the wordlists in burp and iterate through all payloads. If any are allowed, it may allow for some obscure files types to be uploaded to the server and exploited

  • For the files successfully uploaded: Find the path on the app for the uploaded files, try to execute them output: file paths, files executed

  • Try renaming ‘altered’ files after upload, and changing the content type to see you can execute. output: BR number

  • Try uploading a file when another file with the same name already exists. output: BR number

  • Try uploading a file when another folder with the same name already exists. This may show interesting error messages that can lead to information disclosure. output: BR number

  • Try uploading a file with a long name. This may show interesting error messages that can lead to information disclosure. output: BR number

  • Try uploading a file multiple times at the same time. This may show interesting error messages that can lead to information disclosure.

  • Try uploading a file with ”.”, ”..”, or ”…” as its name. output: BR number

  • Try uploading a file with ”../../../../file.txt” as its name.

  • Try uploading a file in Windows with invalid characters such as |<>*?” in its name. This may show interesting error messages that can lead to information disclosure. output: BR number

  • Try uploading a file in Windows using reserved (forbidden) names output: BR number

  • Upload .html file containing JavaScript, can you execute?

Checkout Tests

  • Check logic throughout the application, special attention to checkout

  • Check if promotional codes can be bruteforced output: path, repeater

  • Price manipulation output: BR number, parameter

  • Negative Sales output: BR number

  • Interesting Parameters tested

  • Cross Site Request Forgery to change order/ address output: BR number / repeater request, parameter

  • Order history/ force browsing output: BR number / URL

  • Caching of details

  • Merge accounts with existing users/ username enumeration

  • Fail open on credit card details output: BR number

  • Submit order with fake credentials output: BR number, credentials used

Data Validation Tests

  • Look for injection points and look for information disclosure:

  • Test for XSS (where XSS cannot be injected, refer to testing On-Site request forgery and HTML Injection): output: BR number / repeater request, path, parameter name, injection string used, authentication type

  • Test for SQLi. If SQLi found, exploit with SQLmap: output: path, parameter name, injection string used, output, authentication type

  • Test for HTML Injection (Burp): output: BR number / repeater request, path, parameter name, injection string used, authentication type

  • Test for Path Traversal (../../../../../../etc/passwd): output: BR number / repeater request, path, parameter name, path traversal used, output, authentication type

  • Test for Command Injection (if able to delete, can you delete something you shouldn’t be?): output: BR number / repeater request, path, parameter name, command used, output, authentication type

  • Test for SSTI Submit SSTI payloads such as {{1337*1337}}, if the calculation comes back then you can get RCE

  • Test for Remote and Local file inclusion vulnerabilities: output: BR number / repeater request, path, parameter name, local/remote file used, output, authentication type

  • Test for HTTP Splitting and Smuggling (Burp Scanner): output: BR number / repeater request, path, parameter name, malicious string used, output, authentication type

  • Test for HTTP Parameter Pollution (Burp Scanner): output: BR number / repeater request, path, parameter name, malicious string used, output, authentication type

  • Test for Rare Injection Methods (LDAP, SSI, XML - Burp): output: BR number / repeater request, path, parameter name, injection string used, output, authentication type

  • Test for Reflected File Download: output: BR number / repeater request, path, parameter name, supplied string used, output, authentication type

CORS

  • Test for CORS support:
    • Add Origin: [https://abritrarydomain.com](https://abritrarydomain.com/) as a HTTP header to a request. If the server returns Access-Control-Allow-Origin: check if it reflects your arbitrary domain value.
  • Test for the extent of CORS support
    • If the response contains an ‘*’, any other page from any other domain can read data from this URL, so check for sensitive information (public pages likely don’t need reporting.)
    • If the application returns the originating domain (literally returns itself), check this is not being used for any access control by replacing the **Origin** header with something and seeing what is returned as this can be spoofed.
  • Test for Credentials Support:
    • Does the application’s response contain **Access-Control-Allow-Credentials: true**
    • This could lead to cookies leaking through XHR/AJAX responses.
  • Test for Authentication/Session Type:

    • Does the app use use cookies when XHR/AJAX requests are made? If so then may be vulnerable to CSRF.

      OAuth bearer tokens inside **Authorisation** header do not automatically get sent by the browser and is therefore not vulnerable to CSRF.

  • Test for Accepted Content-Type:
    • Almost all XHR/AJAX requests include the **application/json** content type. Confirm the the type is being validated server-side - if forged the server should force a pre-flight **OPTIONS** check to take place, preventing the CSRF attack flow.
  • Test for Secure Communications:
    • Applications should only accept CORS requests over TLS connections.
  • Test for Pre-flight Response Caching:
    • The whole point of the CORS pre-flight **OPTIONS** request is to make sure the request is safe to send and in the expected format.
    • Developers may use the **Access-Control-Max-Age** to improve the browser overheads, but overly permissive times may allow an attacker to bypass other checks during a state change.

Misc Tests

  • Clickjacking possible? X-Frame + CSP missing (Burp should report)
<pre lang="JavaScript" line="1">
<html>
<head>
<title>ClickJacking PoC</title>
</head>
ClickJacking PoC
<h2>Your Web Application Can be Mounted within an iFrame which makes it vulnerable to ClickJacking!</h2>
<iframe src="https://ADDURLHERE/" height="450" width="1000"></iframe>
</body>
</html>
</pre>

  • If flash movies exist, check for crossdomain.xml and analyse:

  • If flash movies exist, test with SWFScan:

  • Check for parameter redirection to external sites: output: BR number, path, parameter

  • Check all application generated emails for sensitive information:

  • Check for application search cache poisoning:

  • Nmap slow loris: Start: End:

  • BREACH attack:

Graph View

Backlinks