XSS

REFLECTED XSS

Entry points:

- URL Parameters: User-supplied data passed via query parameters in the URL.
- Search Queries: Search queries that are reflected in the response, often seen in search result pages.
- Form Fields: User input reflected in the response after submitting a form.
- Error Messages: Error messages generated by the application that include unvalidated user input.
- Headers: HTTP headers such as Referer, User-Agent, or custom headers that are reflected in the response.
- Cookies: Unescaped cookie values included in the response.
- Referrer Values: The referrer URL value passed by the user's browser and reflected in the response.
- User-Agent Values: The user-agent string provided by the user's browser and included in the response.
- Hidden Form Fields: Hidden fields in HTML forms that include unvalidated user input.
- AJAX Responses: Responses from AJAX requests that include unvalidated user input and are directly rendered in the page.
- Pagination Parameters: Parameters used for pagination, where user input is included in the response.
- Hash Fragments: Data passed via the URL hash fragment (e.g., #) that is reflected in the response.
- Language Parameters: Language selection parameters that are reflected in the response.
- File Upload Names: File names provided by the user during file uploads, which are then reflected in the response.
- Referenced JavaScript or CSS Files: File names or paths referenced in HTML, JavaScript, or CSS that are based on user input and are included in the response.
- QR Codes or Barcodes: QR codes or barcodes that contain user input and are decoded by the application, with the decoded data being reflected in the response.
- Custom URL Schemes: Custom URL schemes used by the application that reflect user input in the response.
- Custom Application-Specific Parameters: Custom parameters used by the application that reflect user input in the response.

Exit points:

STORED XSS

Entry points:

- User-Generated Content: Any part of the web application that allows users to submit content, such as comments, messages, reviews, or posts
- Input Fields: Form input fields, including text fields, text areas, and file uploads
- User Profiles: User profiles that allow users to enter personal information, bios, or descriptions can be an entry point
- Content Management Systems (CMS): CMS platforms that allow content authors to create and manage pages can become entry points
- Message Boards, Blogs and Forums: If a web application includes message boards, forums, or chat functionalities, user-generated content posted in these areas
- User-Generated URLs: If users can create URLs that contain dynamic content or parameters, those URLs can become an entry point for stored XSS
- User-Generated File Uploads: If the application allows users to upload files (e.g., images, documents), and these files are later accessed by other users
- Content Sharing Platforms: Platforms that allow users to share content (e.g., videos, articles) can be entry points

Exit points:

DOM XSS

Entry points:

- URL parameters: passes it to a sink that supports dynamic code execution, such as eval() or innerHTML, which is typically accessed with the window.location object. https://example.com/page?name=<script>alert('XSS');</script>
- Form Inputs: If a web application directly injects user-supplied content into the DOM without proper sanitization, an attacker can exploit this to execute malicious scripts.
- HTML5 Attributes: Certain HTML5 attributes, such as data-*, aria-*, and others, can be manipulated by an attacker to trigger DOM XSS if the application doesn't validate or sanitize these attributes properly. <div data-user-input="<script>alert('XSS');</script>"></div>
- Event Handlers: If an application dynamically sets event handlers, attackers may inject malicious scripts into these handlers.
- JavaScript Functions: When an application executes JavaScript functions based on user-supplied data without proper validation, it becomes vulnerable to DOM XSS.
- Client-Side Templating: If a web application uses client-side templating engines (e.g., Handlebars, Mustache) and injects unsanitized user input into the templates, it can lead to DOM XSS.

Exit points:

🔹 Automated Tools🔹

GitHub - hahwul/dalfox: 🌙🦊 DalFox is an powerful open source XSS scanning tool and parameter analyzer, utilityGitHub

GitHub - s0md3v/XSStrike: Most advanced XSS scanner.GitHub

• Burp Suite: Proxy, Repeater

• JS-Scan: Endpoint discovery through JS files

• LinkFinder: Endpoint discovery through JS files

• XSS Hunter: Blind XSS discovery

• Parameth: Bruteforce GET and POST parameters

🔹BURP: DOM Invader🔹

Miscellaneous DOM Invader settingsBurp_Suite

• Message filtering by stack trace: OFF

• Auto-fire events: ON

• Redirection prevention: OFF

• Add breakpoint before redirect: ON

• Inject canary into all sources: ON

• Remove Permissions-Policy header: OFF

DOM Invader: Prototype Pollution

Testing for client-side prototype pollutionBurp_Suite

DOM Invader: DOM clobbering

Testing for DOM clobbering with DOM InvaderBurp_Suite

DOM Invader: Web messages

Testing for DOM XSS using web messagesBurp_Suite

🔹Manual Code Reviews and Testing🔹

REFLECTED XSS

How to Find XSS VulnerabilityComparitech

WSTG - v4.1 | OWASP Foundation

1. Identify / Analyze code that outputs user input: Codes that output user input without proper sanitization risk XSS vulnerability.

• Press Ctrl + U (to view the page output source from the browser to see if your code is placed inside an attribute.) If it is, inject the following code and test to view the output: “onmouseover= alert(‘hello’);”

• I search for the word "XSS" and there is no reflection, meaning there isn't a injection point

• you first need to make sure the value you sent to the server gets reflected in the response, otherwise you are only trying payloads like crazy when there is actually no injection point

1. Check Impact: Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML.

If i enter xss"> i get xss"> 
The key HTML entities to identify are:
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
“>< 
xss">

However, a full list of entities is defined by the HTML and XML specifications.
\n (new line)
\r (carriage return)
' (apostrophe or single quote)
" (double quote)
\ (backslash)
\uXXXX (unicode values)

1. Trying in every parameter you see:

https://github.com/lutfumertceylan/top25-parameter/blob/master/xss-parameters.txt

1. URL Parameters: Data passed in the query string of a URL, typically after the ? symbol. For example,

https://example.com/page?name=<malicious_code>

1. Form Fields: Data submitted through HTML forms. For example,

< input type="text" name="comment" >

1. Cookies: Data stored in cookies and sent with each request to the server. Malicious code in cookies can be used to execute when a user visits a page.

2. HTTP request parameter: Certain HTTP headers, such as the Referer header, can also contain user-provided data that might be used in the application.

3. POST data: JSON

TIP: create a bash script to automate javascript static analysis, only 3 goals:

1. Gather the javascript file links present in a domain.

2. Discover the endpoints present in those javascript

3. Then save those javascript files for further static analysis where we can look for hardcoded credentials and stuff

Common injection parameters:

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect#fuzzing

https://github.com/lutfumertceylan/top25-parameter/blob/master/xss-parameters.txt

?q={payload} 
?s={payload} 
?search={payload} 
?id={payload} 
?lang={payload} 
?keyword={payload} 
?query={payload} 
?page={payload} 
?keywords={payload} 
?year={payload} 
?view={payload} 
?email={payload} 
?type={payload} 
?name={payload} 
?p={payload} 
?month={payload} 
?image={payload} 
?list_type={payload} 
?url={payload} 
?terms={payload} 
?categoryid={payload} 
?key={payload} 
?login={payload} 
?begindate={payload} 
?enddate={payload}
/{payload} 
?next={payload} 
?url={payload} 
?target={payload} 
?rurl={payload} 
?dest={payload} 
?destination={payload} 
?redir={payload} 
?redirect_uri={payload} 
?redirect_url={payload} 
?redirect={payload} 
/redirect/{payload} 
/cgi-bin/redirect.cgi?{payload} 
/out/{payload} 
/out?{payload} 
?view={payload} 
/login?to={payload} 
?image_url={payload} 
?go={payload} 
?return={payload} 
?returnTo={payload} 
?return_to={payload} 
?checkout_url={payload} 
?continue={payload} 
?return_path={payload}

1. Check that output is encoded:

Check that HtmlEncode is used to encode HTML output that includes any type of input. Also, check that UrlEncode is used to encode URL strings. Input data can come from query strings, form fields, cookies, HTTP headers, and input read from a database, particularly if other applications share the database. If these encodings are missing, your application is at risk of XSS vulnerability. In addition, by encoding the data, you prevent the browser from treating the HTML as an executable script. However, if the code you are reviewing filters for characters, then test using the following script instead:

&{alert(‘hello’);}

1. Identify code that handles URLs:

Code that governs URLs can risk XSS and other vulnerabilities. Review your code and systems as follows:

• Check that your webserver is updated. If your webserver is not up-to-date with the latest security patches, it could be vulnerable to directory traversal attacks

• If your code filters for “/”, an attacker can easily bypass the filter by using URL encoding (percent-encoding) for the same character.

For example, the percent-encoding for “/” is “%c0f%af”, 
which could be used to bypass the filter as shown in the following URL: 
http://www.abc.com/..%c0f%af../winnt.

• If your code processes query string input, check that it constrains the input data and performs bounds checks. Also, check that the code is not vulnerable if an attacker injects a massive amount of data through a query string parameter like the URL shown here:

http://www.abc.com/test.aspx?var=InjectHugeAmountOfDataHere.

1. Unit test your codes:

Unit testing is a software testing method by which individual units of source code are tested to determine whether they are fit for use. Unit testing aims to isolate each part of the program and show that the individual components are correct. Use unit testing to make sure that a particular bit of data is correctly escaped. Unit testing helps to identify XSS and other flaws early in the development cycle. If possible, unit test every place where user-supplied data is displayed. After you find and fix an XSS bug in your code, consider adding a regression test for it.

1. Perform these basic tests on your application:

Create a test user profile and use that profile to interact with your application. Insert strings that contain HTML and JavaScript metacharacters such as, into all application inputs, such as forms, URL parameters, hidden fields, or cookie values.

 >’>”><img src=x onerror=alert(0)>

If your application doesn’t correctly escape this string, you will see an alert and know that something isn’t right. Wherever your application handles user-supplied URLs, enter the following javascript code:

alert(0) or data:text/html,<script>alert(0)</script>

🔹Manual Code Reviews and Testing🔹

Stored XSS

WSTG - v4.1 | OWASP Foundation

TOOLS:

• PHP Charset Encoder(PCE) PCE helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.

• Hackvertor Hackvertor is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).

• BeEF BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.

• XSS-Proxy XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.

This type of attack can also be exploited with browser exploitation frameworks such as BeEF and XSS Proxy. These frameworks allow for complex JavaScript exploit development.

Input Forms

• User/Profiles page: the application allows the user to edit/change profile details such as first name, last name, nickname, avatar, picture, address, etc.

• Shopping cart: the application allows the user to store items into the shopping cart which can then be reviewed later

• File Manager: application that allows upload of files

• Application settings/preferences: application that allows the user to set preferences

• Forum/Message board: application that permits exchange of posts among users

• Blog: if the blog application permits to users submitting comments

• Log: if the application stores some users input into logs.

Analyze HTML Code

Leverage Stored XSS with BeEF

File Upload

🔹Manual Code Reviews and Testing🔹

DOM XSS

WSTG - v4.1 | OWASP Foundation