Web Security Vulnerability & Prevention Mechanism

Type of Attacks

ClickJacking

The victim visits the attacker's website and clicks on Play but actually, the victim clicks on Pay which is from the bank.com website.

The attacker has added the iframe of the bank.com website at the top z-index and made it transparent by setting opacity to 0. Play is just a simple component that is just below the iframe but it’s visible due to the iframe opacity being 0.

As a user, you shouldn’t visit any malicious sites and especially shouldn’t click anywhere. Users may use a different browser for using such websites which don’t have cookies of sites.

Cross-site Scripting Attack

Cross-Site Scripting (XSS) is a security vulnerability that allows an attacker to inject malicious scripts or code into a website, which can then be executed by unsuspecting users who visit the site. There are multiple ways through which this can happen

Reflected XSS

Step1 - Attacker share URL (which contains script)

Step2 - Victim clicks on the url

Step3 - Browser Request webserver

Step4 - Webserver return the page with the same script

Step5 - The script gets executed and the script starts sharing website data with attackers.

Stored XSS

Step1 - The attacker uploads script on the Website

Step2 - Website store the script

Step3 - Victim opens the website

Step4 - Webserver returns a page with the same script

Step5 - The browser executes the script and starts sharing user data with the Attacker.

Mime Sniffing Attack

MIME sniffing is a security vulnerability that can occur when a web browser attempts to determine the correct MIME type (file type) of a resource based on its content, rather than relying on the server-provided Content-Type header.

For example, an attacker could upload a malicious script to a website with a fake file extension that looks harmless (such as a .jpg or .gif file) but contains JavaScript code. If the server does not properly set the Content-Type header, the browser may attempt to "sniff" the file type and execute the script, allowing the attacker to execute arbitrary code or steal sensitive information.

Cross-Site WebSocket Hijacking

Cross-Site WebSocket Hijacking (CSWSH) is a type of attack that exploits WebSocket connections to allow an attacker to execute arbitrary code or steal sensitive information from a victim's browser.

Security Practices can prevent these attacks

Add HTTP Response Header - X-Frame-Options

Web developers can use the X-Frame-Options header to instruct the browser not to display their website in an iframe. The header can be set to one of three values: "DENY", "SAMEORIGIN", or "ALLOW-FROM uri".

X-Frame-Options: SAMEORIGIN

This prevents ClickJacking attacks.

Add HTTP Response Header - Content-Security-Policy

Content Security Policy (CSP) can use to control which resources (such as images, scripts, stylesheets, and fonts) are allowed to be loaded by their web application on the browser.

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://example.com;

This prevents Cross Site Scripting attacks.

Add HTTP Response Header - X-Content-Type-Option

The X-Content-Type-Options header guide browser on whether it should determine the mime type automatically or not.

By setting the header to "nosniff" developers can ensure that the browser always uses the specified MIME type, and prevent attackers from exploiting vulnerabilities that rely on MIME sniffing.

X-Content-Type-Options: nosniff

This prevents Mime Sniffing attacks.

Add HTTP Response Header - Referer Policy

The browser sends referer information to a new page/site when the user navigates to a new page. This feature can lead to security issues For example if a website has a lax Referer Policy that allows the Referer header to be sent to all third-party sites, an attacker could potentially use this information to track users across multiple sites or to collect sensitive information about the user's browsing habits.

By setting an appropriate Referer Policy, website owners can reduce the risk for users:

1. no-referrer: This value tells the browser not to send the Referer header at all when navigating to another website. This means that the target website will not know which page the user came from.

2. no-referrer-when-downgrade: This value tells the browser to send the Referer header when navigating to a website that uses HTTPS, but not when navigating to a website that uses HTTP.

3. same-origin: This value tells the browser to send the Referer header only when navigating to another page on the same origin (i.e., same scheme, hostname, and port).

4. strict-origin: This value tells the browser to send the Referer header when navigating to a page on the same origin, but not when navigating to a different origin.

5. origin: This value tells the browser to send the Referer header with just the scheme, hostname, and port of the referring page, but not the path or query string.

6. strict-origin-when-cross-origin: This value is similar to strict-origin, but it allows the Referer header to be sent when navigating from one origin to another if and only if the HTTP method is safe (i.e., GET, HEAD, or OPTIONS).

Always do WebSocket Origin Validation

Cross-Origin Validation is not being done by the browser when it's WebSocket connection. And hence Validating the origin of WebSocket connections is an important security measure to prevent unauthorized access and protect against Cross-Site WebSocket Hijacking (CSWSH) attacks.

If the server does not validate the Origin header, an attacker could potentially use a malicious webpage to establish a WebSocket connection to the server and execute arbitrary code or steal sensitive information.

Reference