4.11 Client-side Testing

4.11.1

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

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

Evidence:

4.11.3

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:

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:

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

Evidence:

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:

Check if the application has Flash source code

Evidence:

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:

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.
Origin.
Confidentiality and Integrity.
- Check that the WebSocket connection is using SSL to transport sensitive information wss://.
Authentication.
Authorization.
Input Sanitization.

Evidence:

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

Evidence:

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:

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

Evidence:

Last updated 4 months ago

4.11.1

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

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

Evidence:

4.11.3

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

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

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

Evidence:

4.11.6

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

Check if the application has Flash source code

Evidence:

4.11.9

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

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 WebSocket tab.
Origin.
- Using a WebSocket client (one can be found in the 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 section of this guide.
Authentication.
- WebSockets do not handle authentication, normal black-box authentication tests should be carried out. Refer to the sections of this guide.
Authorization.
- WebSockets do not handle authorization, normal black-box authorization tests should be carried out. Refer to the sections of this guide.
Input Sanitization.
- Use WebSocket tab to replay and fuzz WebSocket request and responses. Refer to the sections of this guide.

Evidence:

4.11.11

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

Evidence:

4.11.12

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

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

Evidence:

4.11.4

4.11.5

4.11.6

4.11.8

4.11.9

4.11.10

Use WebSocket tab.

Using a WebSocket client (one can be found in the 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.

Check the SSL Implementation for security issues (Valid Certificate, BEAST, CRIME, RC4, etc). Refer to the section of this guide.

WebSockets do not handle authentication, normal black-box authentication tests should be carried out. Refer to the sections of this guide.

WebSockets do not handle authorization, normal black-box authorization tests should be carried out. Refer to the sections of this guide.

Use WebSocket tab to replay and fuzz WebSocket request and responses. Refer to the sections of this guide.