What is Client-Side Testing?
Client-side testing is the process of testing web applications or software that is carried out on the client side, namely on the browser or client. The goal is to ensure that the application or software functions properly and in accordance with the specified specifications.
let’s look at the controls from owasp, there are 13 checklists
13 checklist from owasp about Client Side Testing
Here I will give some examples of testing on client side testing, using the website http://testphp.vulnweb.com/
- Testing for DOM-Based Cross Site Scripting
The following is a basic example of a DOM-based Cross-site Scripting vulnerability. The http://www.example.com/userdashboard.html page is customized based on the user name. The user name is encoded in the URL and used directly on the resulting page:
<html>
<head>
<title>Custom Dashboard </title>
...
</head>
Main Dashboard for
<script>
var pos=document.URL.indexOf("context=")+8;
document.write(document.URL.substring(pos,document.URL.length));
</script>
...
</html>For example,
http://www.example.com/userdashboard.html?context=users is a dashboard customized for users. It contains the string Main Dashboard for users at the top.
Here is how a DOM-based XSS attack can be performed for this web application:
- Attacker embeds a malicious script in the URL:
http://www.example.com/userdashboard.html#context=<script>SomeFunction(somevariable)</script>.
2. The victim’s browser receivers this URL, sends an HTTP request to http://www.example.com, and receives the status HTML page.
3. The browser starts building the DOM of the page and populates the document.URL property with the URL from step 1.
4. The browser parses the HTML page, reaches the script, and runs it, extracting the malicious content from the document.URL property.
5. The browser updates the raw HTML body of the page to contain: Main Dashboard for <script>SomeFunction(somevariable)</script>.
6. The browser finds the JavaScript code in the HTML body and executes it.
try to testing DOM-Based XSS in testhtml5.vulnweb.com/
- using the following payload
http://testhtml5.vulnweb.com/#/redir?url=javascript:alert("DOM XSS on: “ + document.domain)
and response on browser like this :
Testing for Reflected XSS in testphp.vulnweb.com
using payload <script>alert<’XSS’)</script>
2. Testing for JavaScript Execution
3. Testing for HTML Injection
HTML injection is a type of injection vulnerability that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user’s session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims.
This vulnerability occurs when user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) legitimate parts from malicious parts of the page, and consequently will parse and execute the whole page in the victim’s context.
example, try to testing HTML Injection on testphp.vulnweb.com
and response this web like this
this proves that the testphp.vulnweb.com website can be injected with HTML tags
4. Testing for Client-side URL Redirect
5. Testing for CSS Injection
6. Testing for Client Side Resource Manipulation
7. Testing Cross Origin Resource Sharing
Cross origin resource sharing (CORS) is a mechanism that enables a web browser to perform cross-domain requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy.
Cross-origin requests have an origin header that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. HTTP headers are used to accomplish this.
8. Testing for Cross Site Flashing
Attackers can trick victims into executing Flash documents that pass commands or calls to the Flash player browser plugin, allowing the attacker to exploit native Flash functionality in the client browser. This attack pattern occurs where an attacker may provide a crafted link to a Flash document (SWF file) that, if followed, will cause additional malicious instructions to be executed. The attacker does not need to present or control the Flash document. This attack takes advantage of the fact that Flash files can reference external URLs. If the variable that serves as the URL referenced by the Flash application can be controlled via a parameter, then by creating a link that includes a value for that parameter, the attacker can cause arbitrary content to be referenced and possibly executed by the targeted Flash application.
using the wappalyzer extension to check if there is adobe flash:
9. Testing for ClickJacking
Clickjacking is a type of security attack where an attacker hides an invisible link or button under another element on a web page. When users click on these elements, they inadvertently trigger unwanted actions such as sharing personal information or installing malware. Clickjacking attacks take advantage of users’ trust in what they see on a web page and lead them to perform harmful actions.
example :
create a script HTML and add iframe tag in HTML code
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test page</title>
</head>
<body>
<p style="text-align: center;">ClickJacking PoC</p>
<iframe src="http://testphp.vulnweb.com" width="750" height="700"></iframe>
</body>
</html>here, i used Laragon
and try to open the html file that was created into the browser
10. Testing WebSockets
WebSocket is an advanced technology for establishing a connection between a client and a server (browser and server) and enabling communication between them in real-time. The main difference with WebSocket is that it allows you to receive data without having to send a separate request, as happens in HTTP. Once the connection is established, the data will come by itself without the need to send a request.
11. Testing Web Messaging
Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. Before the introduction of web messaging, the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser. Developers used multiple hacks in order to accomplish these tasks, and most of them were mainly insecure.
12. Testing Browser Storage
Testing should be conducted to determine whether the website is storing sensitive data in client-side storage. The code handling of the storage objects should be examined for possibilities of injection attacks, such as utilizing unvalidated input. JavaScript in particular should be examined to determine if scripts or third party libraries are introducing vulnerabilities.
Browsers provide the following client-side storage mechanisms for developers to store and retrieve data:
- Local Storage
- Session Storage
- IndexedDB
- Web SQL (Deprecated)
- Cookies
I’m trying to see if there is browser storage using inspect elemets.
maybe this testing method can be done further using some tools for example Burpsuite to find out more information.
13. Testing for Cross Site Script Inclusion
XSSI designates a kind of vulnerability which exploits the fact that, when a resource is included using the script tag, the SOP doesn’t apply, because scripts have to be able to be included cross-domain. An attacker can thus read everything that was included using the script tag.
This is especially interesting when it comes to dynamic JavaScript or JSONP when so-called ambient-authority information like cookies are used for authentication. The cookies are included when requesting a resource from a different host.
