Web Security Vulnerability & Prevention Mechanism
Table of contents
- Type of Attacks
- Security Practices can prevent these attacks
Type of Attacks
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
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.
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.
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".
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'
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.
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:
no-referrer: This value tells the browser not to send the
Refererheader at all when navigating to another website. This means that the target website will not know which page the user came from.
no-referrer-when-downgrade: This value tells the browser to send the
Refererheader when navigating to a website that uses HTTPS, but not when navigating to a website that uses HTTP.
same-origin: This value tells the browser to send the
Refererheader only when navigating to another page on the same origin (i.e., same scheme, hostname, and port).
strict-origin: This value tells the browser to send the
Refererheader when navigating to a page on the same origin, but not when navigating to a different origin.
origin: This value tells the browser to send the
Refererheader with just the scheme, hostname, and port of the referring page, but not the path or query string.
strict-origin-when-cross-origin: This value is similar to
strict-origin, but it allows the
Refererheader 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.