4.11 Client-side Testing

Client-side Testing

4.11.1 Testing for DOM-Based Cross Site Scripting

Append the payload #"><script>alert('xss')</script> into the URL on different endpoints of the application.
Indetify sources:

document.URL|document.documentURI|document.URLUnencoded|document.baseURI|location.search|document.cookie|document.referrer|location.

Identify DOM sinks.

document.write\(|document.writeln\(|document.domain|\w\.innerHTML|\w\.outerHTML|\w\.insertAdjacentHTML|\w\.onevent

Use Burp Suite DOM-Invader to identify/exploit id there is DOM-Based XSS

Evidence:

4.11.2 Testing for JavaScript Execution

Because the latter section was focused on JavaScript execution, there is no need to check it again.

Evidence:

4.11.3 Testing for HTML Injection

Most of the reflected, stored , DOM-Based XSS can also be considered HTML injection
Identify HTML injection points and assess the severity of the injected content.

Evidence:

4.11.4 Testing for Client-side URL Redirect

Identify injection points that handle URLs or paths.

[?&](url|link|redirect|target|site|page|navigate|ref|callback|host|return|next|returnurl|redirectUrl)=

Assess the locations that the system could redirect to.

Evidence:

4.11.5 Testing for CSS Injection

Identify JavaScript injection points that manages CSS Styles.
Assess the impact of the injection.

Evidence:

4.11.6 Testing for Client-side Resource Manipulation

Identify sinks with weak input validation that are used to retrieve resources.
Assess the impact of the resource manipulation.

[?&](file|path|document|folder|dir|download|resource|view|load|template|img|image)=|.src=

Evidence:

Check that the value of Access-Control-Allow-Origin is not set to * or null. Except in the case of a public API that is intended to be accessible by everyone.
Check that the header Access-Control-Allow-Credentials is not in used with Access-Control-Allow-Origin: * on a private API.
Check for reflection on the Allow-Origin header, based on the input of the Origin header.

Evidence:

4.11.8 Testing for Cross Site Flashing

Check if the application has Flash source code

Evidence:

4.11.9 Testing for Clickjacking

Perform a simple clickjacking attack:

<!-- clickjacking.html: -->
<html>
   <head>
     <title>Clickjack test page</title>
   </head>
   <body>
     <h1>Website is vulnerable to clickjacking attacks!</h1>
     <p>Embebed in a iframe for clickjackings attacks</p> 
     <p>Authenticated page with privilege actions</p> 
     <input type="button" value="Vulnerable" style="position:absolute;top:280;left:450;background-color:red;color:white;padding: 10px 15px;">
     <iframe src="https://example.com/" style="opacity:0.5; filter:alpha(opacity=30)" width="1500" height="1000"></iframe>
   </body>
</html>

Check the response headers for X-Frame-Options: SAMEORIGIN. If exists, the attacks below most of the won't work.
Check for "Frame Busting" scripts
Try to perform a "Double Framing".

<!-- Attacker’s top frame (pre-clickjacking.html): -->
<h1>Double Framing Attack (First Frame)</h1>
<iframe src="clickjacking.html" width="3000" height="2000"></iframe>

Try disabling Javascript:

<iframe src="http://example.org" security="restricted"></iframe>

Try using sandbox attributte:

<iframe src="http://example.org" sandbox></iframe>

OnBeforeUnload Event

<h1>www.fictitious.site</h1>
<script>
    window.onbeforeunload = function()
    {
        return " Do you want to leave fictitious.site?";
    }
</script>
<iframe src="http://example.org">

Evidence:

4.11.10 Testing WebSockets

Identify that the application is using WebSockets.
- Inspect the client-side source code for the ws:// or wss:// URI scheme.
- Use Google Chrome’s Developer Tools to view the Network WebSocket communication.
- Use ZAP’s WebSocket tab.
Origin.
- Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If a connection is established the server may not be checking the origin header of the WebSocket handshake.
Confidentiality and Integrity.
- Check that the WebSocket connection is using SSL to transport sensitive information wss://.
- Check the SSL Implementation for security issues (Valid Certificate, BEAST, CRIME, RC4, etc). Refer to the Testing for Weak Transport Layer Security section of this guide.
Authentication.
- WebSockets do not handle authentication, normal black-box authentication tests should be carried out. Refer to the Authentication Testing sections of this guide.
Authorization.
- WebSockets do not handle authorization, normal black-box authorization tests should be carried out. Refer to the Authorization Testing sections of this guide.
Input Sanitization.
- Use ZAP’s WebSocket tab to replay and fuzz WebSocket request and responses. Refer to the Testing for Data Validation sections of this guide.

Evidence:

4.11.11 Testing Web Messaging

Identify addEventListener|postMessage events.
Try to exploit those events.

Evidence:

4.11.12 Testing Browser Storage

Check if there is sensitive data stored on the browser's local or session storage.
Determine whether the website is storing data in client-side storage window.localStorage|window.sessionStorage.
The code handling of the storage objects should be examined for possibilities of injection attacks, such as utilizing unvalidated input or vulnerable libraries.

Evidence:

4.11.13 Testing for Cross Site Script Inclusion

Detect if there is sensitive data on JS files. You can use extensions as JS Miner.

Evidence:

Last updated 1 year ago

Client-side Testing

4.11.1 Testing for DOM-Based Cross Site Scripting

4.11.2 Testing for JavaScript Execution

4.11.3 Testing for HTML Injection

4.11.4 Testing for Client-side URL Redirect

4.11.5 Testing for CSS Injection

4.11.6 Testing for Client-side Resource Manipulation

4.11.7 Testing Cross Origin Resource Sharing

4.11.8 Testing for Cross Site Flashing

4.11.9 Testing for Clickjacking

4.11.10 Testing WebSockets

4.11.11 Testing Web Messaging

4.11.12 Testing Browser Storage

4.11.13 Testing for Cross Site Script Inclusion