Home

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

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

Fuzzing Sub-domains

Fuzzing VHOSTs

Fuzzing Directories Files Parameters

Be sure to test both http and https

Extensions

Directories

Files

Parameters

GET

POST

Values

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

Random

Response Headers

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

Command Injection

Local File inclusion

Linux

Windows

Remote File inclusion

SQL injection

Authentication Bypass

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

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

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

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.
the page should look as follows when we visit the malicious URL

Session Hijacking

Write this js into a "script.js" file. You will need to serve this in a PHP server.
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

PreviousDomain Name ServiceNextInternet Message Access Protocol / Post Office Protocol

Last updated