In this article we will introduce some basic concepts to understand the hacking techniques used against browsers focused on their “Client-Side”.
JavaScript is a programming language that is commonly used in web development. It is a client-side scripting language, which means that it is executed by the user’s web browser rather than on a server. JavaScript is used to add interactivity and dynamic behavior to websites, and is an essential part of building modern web applications. It is a high-level, interpreted language that is easy to learn and is commonly used in conjunction with HTML and CSS to build web pages
JavaScript is a powerful and widely-used programming language, but like any other language, it has its limitations when it comes to security. Some of the main security limitations of JavaScript include:
JavaScript is client-side: Because JavaScript is executed by the user’s web browser, it is inherently limited in what it can do on the server-side. This means that JavaScript cannot be used to access sensitive information or perform sensitive operations that are stored on the server.
JavaScript can be exploited: Despite the efforts of web browser vendors to secure their products, vulnerabilities can still be found in JavaScript engines and client-side software. Attackers can exploit these vulnerabilities to inject malicious code into web pages or steal sensitive information.
JavaScript is vulnerable to attacks such as cross-site scripting (XSS): XSS attacks involve injecting malicious code into a web page that is then executed by the user’s browser. This can be used to steal sensitive information, manipulate web pages, or install malware on the user’s device.
JavaScript can be disabled: Some users may choose to disable JavaScript in their web browser for various reasons, such as privacy concerns or to improve performance. This can limit the functionality of web pages and applications that rely on JavaScript.
Despite these limitations, JavaScript is still an essential and widely-used language for building modern web applications. By following best practices for security and staying up to date with the latest security developments, it is possible to build secure and reliable applications using JavaScript.
THE CLIENT SIDE
In the context of web development, “client-side” refers to operations that are performed by the user’s web browser, as opposed to operations that are performed on the server.
Client-side technologies, such as JavaScript, HTML, and CSS, are responsible for the rendering and behavior of a web page. When a user requests a web page from a server, the server sends the HTML, CSS, and JavaScript files to the user’s browser. The browser then parses these files and renders the page according to the instructions contained within them. Any interactive or dynamic elements of the page, such as form validation, animations, and data manipulation, are handled by the client-side scripts.
The Document Object Model (DOM) is a programming interface for HTML and XML documents. It represents the structure of a document as a tree of objects, with each object representing a part of the document (such as an element, an attribute, or a piece of text). The DOM allows programs to manipulate the content, structure, and style of a document.
In the context of web development, the DOM is used by client-side scripts to access and manipulate the content of a web page. When a web page is loaded, the browser creates a DOM representation of the page, which can be accessed and modified by JavaScript code. This allows scripts to change the content of a page, add or remove elements, and apply styles dynamically, as well as respond to user input and other events.
The DOM is an essential part of modern web development, and is supported by all modern web browsers. It is an important interface for building interactive and dynamic web applications.
The BOM (Browser Object Model) consists of the objects navigator, history, screen, location and document which are children of window. In the document node is the DOM (Document Object Model), the document object model, which represents the contents of the page. You can manipulate it using javascript.
ATTACK VECTORS:
[+] XSS (Or any type of HTML, JS, CSS code inyection)
[+] CSRF
[+] HTTP SMUGGLING
[+] OPEN REDIRECT
[+] FILE UPLOADING (.html, .pdf, …)
[+] MITM/Malicious Extensions.
[+] Post-Explotation contexts…
Some of the most basic and traditional techniques when it comes to using JavaScript in an offensive way are:
- Alter browsing result. ( social eng., phishing… )
- Alter DOM ( form sniffing )
- Capture events ( keyloggin, media capture.. )
- Get local storage
- Get cookies ( session hijacking )
- Get Browser Info,
- Brwosing Sniffing
- Run CRSF
- Do requests in client-side
WS vs PLL
Regarding the ways that the browser has to communicate with other services and resources, we are going to highlight two methodologies that are useful to understand how communications are performed by means of JavaScript. XRH POLLING and WEBSOCKETS.
- XRH POLLING works best in various browsers, being a viable option in different cases. But do lot of requests can be suspicious for an IDS and can overload the browser and you will find problems like CORS. (CORS-Everywhere-proxy)
- Websockets are fast. Although it may give some compatibility problems but today it is a standard and it maintains the connection once established.
TRACKING
Another important point when dealing with browsers from a security point of view is Tracking. This can be considered as the fingerprinting part of browser hacking, since this is where you can obtain all the technical information that identifies the browser and its user. There are also ways to abuse external APIs to get even more and juicier information, but, to start with, the native browser components that can be obtained from the Client-Side are the following:
Canvas: A part of HTML5 Canvas element displaying graphics on the webpage, which is widely used to identify users by the features of their video system
Fonts: Another element that can be used to identify users
Plugins: Installed and enabled plugins help to identify users
Audio (Acoustic) Fingerprint: The role of an audio fingerprint is to capture the signature of a piece of sound, which allows it to be differentiated from other sounds
WebGL: Javascript API for work in 3D graphics in the web browser without the use of plugins
Geolocation: Anti-fraud system can compare users’ IP addresses and their physical geolocation
ClientRects: A method of identifying users using hashes obtained as a result of image scaling
Ubercookie(s): A hash of ClientRects and Audio fingerprints allowing the device to be identified
Web Real-Time Communication (WebRTC) (Including Device Hashes): A technology that is used for device-direct connection to media services such as microphones or cameras, and allows WebRTC to obtain a real IP address by bypassing VPN and proxy services; cameras and microphones have their own location indicators which also need to be changed
Cascading Style Sheets (CSS): A method used to identify a real extension of the window using CSS technology
Touch Emulation: A method allowing touch screen emulation without showing a mouse cursor; after setting up a user agent as a portable device, the anti-fraud system can still detect mouse cursor since it is still on a display
JS Navigator (JavaScript Windows Navigator): Contains time, language, and extensions; the parameters of the web browser that are transmitted with the information about the program
HTTP Headers: One of the primary browser fingerprints that allows anti-fraud defenses to identify users
**Domain Name System (DNS): Ability to use own DNS for each session
Local IP Address: An indicator that helps to reveal the user’s possible real location
You can make a simple fingerprint of your own browser at: https://amiunique.org/
PoC’s
Here are some proofs of concept of how to use vanilla JavaScript to have classic functionalities for an offensive security operator, such as a keylogger, a port scanner, a flooder or other tests such as forcing the browser to download files. Note that these proofs of concept are very simple, and depending on the environment can be more or less effective. There are more complex ways to perform proofs of concept that we will study later.
JS KEYLOGGER
SIMPLE FLOODING && FORCE FILE DOWNLOAD
TIME-BASED IMG TAG PORT SCANNER
PERSIST IN THE SANDBOX
It is very complicated to talk about persistence in client-side attacks as it is understood in attacks on conventional systems. It depends very much on the type of attack. In the most classic environment that we are going to find, by itself, when closing a browser tab, all the JavaScript code that is running in that tab will stop running, which can cause problems. Introductory, we will have to use some social engineering to persist in the active session of the user’s tab as long as possible. Some techniques such as abuse “onclick” event for restricted functions for example, to trigger the windows.open() function to open a tiny window that is running without the user noticing. Other techniques can be to create an html iframe tag that occupies the entire browser screen by impersonating the original page (this is known as clickjacking, but I don’t like the modern names for vulnerabilities).
Problems:
Web browsers have various built-in security measures in place to protect users against JavaScript risks and other types of online threats. Some of the ways that browsers protect users include:
Sandboxing: Many web browsers use sandboxing to isolate web pages and prevent them from accessing sensitive information or interacting with other parts of the system. This helps to protect against malicious code that might try to steal sensitive information or perform unauthorized operations.
Content Security Policy (CSP): CSP is a security feature that allows web developers to specify which sources of content are allowed to be loaded by a web page. This can help to prevent cross-site scripting (XSS) attacks and other types of malicious code injection.
Same-origin policy: The same-origin policy is a security feature that prevents web pages from making requests to a different domain than the one that served the page. This helps to prevent attackers from using one website to access sensitive information or resources on another website.
Input validation: Web browsers often have built-in input validation checks to prevent malicious code from being injected into web pages. This can help to protect against attacks such as cross-site scripting (XSS) and SQL injection.
Automatic updates: Many web browsers have an automatic update feature that ensures that users are always running the latest version of the software. This is important because new security vulnerabilities are often discovered and patched in new versions of the browser.
We will face the different limitations that the “Client-Side” will put on us at the moment of exploiting it, for it we will be developing different concepts that we have to take into account at the moment of developing our payloads:
CORS
Cross-Origin Resource Sharing (CORS) is a mechanism that allows web pages to make requests to a server from a different domain than the one that served the page. This is necessary because of the same-origin policy, which is a security feature implemented by web browsers that prevents web pages from making requests to a different domain than the one that served the page.
The same-origin policy is in place to prevent malicious web pages from making requests to other sites and potentially accessing sensitive information. However, it can also be a hindrance to legitimate web developers, who may need to make requests to APIs or other resources that are hosted on a different domain.
CORS allows web servers to specify which domains are allowed to make requests to their resources. When a web page makes a request to a server that has CORS enabled, the server includes specific headers in its response that allow the browser to determine whether the request is allowed. If the request is allowed, the browser will allow the web page to access the response from the server.
CORS is an important security feature that helps to protect web servers and users from cross-site request forgery (CSRF) attacks and other types of malicious activity. It is supported by all modern web browsers.
It is generally not advisable to bypass CORS restrictions, as they are in place to protect against malicious activity and unauthorized access to resources. However, there are a few options you can consider:
Use a CORS proxy: A CORS proxy is a server that sits between your web application and the server you are trying to access. It makes requests to the server on behalf of your application, and includes the appropriate CORS headers in its responses. This allows your application to access the resources from the server, without the need to bypass CORS restrictions.
Enable CORS on the server: If you have control over the server that you are trying to access, you can enable CORS by adding the appropriate headers to its responses. This will allow your application to make requests to the server without being blocked by the browser.
Use JSONP: JSONP (JSON with Padding) is a technique that allows web pages to make requests to a server from a different domain by injecting a script tag into the page. JSONP is supported by most modern web browsers, and can be used as an alternative to CORS when making requests to a server from a different domain.
COOKIES SECURITY FLAGS
Cookies are small pieces of data that are stored by a web browser and sent to a server with every request. They are often used to store information about a user’s preferences or to track the user’s activity on a website.
Cookies can be set with various security flags that control how they are used and transmitted. Some of the most common security flags are:
- Secure: This flag indicates that the cookie should only be sent to the server over a secure (HTTPS) connection.
- HttpOnly: This flag indicates that the cookie should not be accessible to client-side scripts, such as JavaScript. This helps to prevent attacks such as cross-site scripting (XSS), where an attacker injects malicious code into a web page that is then executed by the user’s browser.
- SameSite: This flag controls whether the cookie should be sent with requests made to a different domain than the one that set the cookie. There are several values that can be set for the SameSite flag, including Strict, Lax, and None.
It is generally not advisable to bypass security flags on cookies, as they are in place to protect against malicious activity and unauthorized access to sensitive information. However, if you are developing a web application and need to bypass a security flag for testing purposes, you may be able to do so by using a tool such as a web debugger or a browser extension.
It is important to note that bypassing security flags on cookies can potentially expose your application and users to security risks, and should be done with caution. It is generally better to use appropriate security flags and follow best practices for handling cookies, in order to protect the security and privacy of your users.
So much for this first post about client-side hacking. I hope you liked it, I have a lot of material and things that I keep looking at now that I would like to show in this blog.
A hug to all hackers ^^