Phishing by Navigating Browser Tabs

Phishing by Navigating Browser Tabs occurs when Open windows with normal hrefs with the tag target="_blank" can modify window.opener.location and replace the parent webpage with something else, even on a different origin.

it allows phishing attacks that silently replace the parent tab. If the links lack rel="noopener noreferrer" attribute, a third party site can change the URL of the source tab using window.opener.location.assign and trick the users into thinking that they’re still in a trusted page and lead them to enter their sensitive data on the malicious website.

You should add rel=noopener to the links to prevent pages from abusing window.opener. This ensures that the page cannot access the window.opener property in Chrome and Opera browsers.

For Example -

<a href="..." target="_blank" rel="noopener noreferrer">...</a>

Passive Mixed Content over HTTPS

Passive Mixed Content over HTTPS occurs when a mixed content loaded over HTTP within an HTTPS page.If the HTTPS page includes content retrieved through regular, cleartext HTTP, then the connection is only partially encrypted.

There are two technologies that helps the mixed content issues -

1. Using HTTP Strict Transport Security (HSTS), that enforces secure resource retrieval, even in the face of user mistakes (attempting to access your web site on port 80) and implementation mistake.

Set htacess Rule as -  

Header set Strict-Transport-Security "max-age=10886400; includeSubDomains;"


2. Content Security Policy (CSP) can be used to block insecure resource retrieval from third-party web sites.

Set htacess Rule as -  

Header set Content-Security-Policy "'self' domain.com"

Cookie Not Marked as Secure

when session cookie not marked as secure, and transmitted over HTTPS. This means the cookie could be stolen by attacker who can successfully intercept the traffic.

This cookie will be transmitted over a HTTP connection, therefore an attacker might intercept it and hijack the session.

If the attacker can carry out a attack, the he can force the user to make an HTTP request to your website in order to steal the cookie.

So you should mark all cookies used within the application as secure.

htaccess rule -

Header set Set-Cookie Secure

Similary, rule for web.config  - 

<rule name="Add Secure">
 <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" />
 <conditions>
<add input="{R:0}" pattern="; Secure" negate="true" />
</conditions>
<action type="Rewrite" value="{R:0}; Secure" />
</rule>

Cross Site Request Forgery

Cross Site Request Forgery or CSRF is a very common vulnerability. It forces the user to execute unwanted actions on a web application.

An attacker can mount any of the actions that can be done by the logged in user such as modifying content, deleting data. All the actions that are available to the user can be used by the attacker.

To avoid this, you can send additional information in each HTTP request that can be used to determine whether the request came from an authorized source. If a request is missing a validation token or the token does not match the expected value, the server should reject the request.

If you are posting Form in ajax request, custom HTTP headers can be used to prevent CSRF.

For JQuery, if you want to add a custom header to -

a. individual request

$.ajax({

    url: 'xyz/',

    headers: { 'my-custom-header': 'somevalue' }

});

b. every request

$.ajaxSetup({

    headers: { 'my-custom-header': 'somevalue' }

});

Cross Site Scripting

Cross-site Scripting, which allows an attacker to execute a dynamic script (JavaScript, VBScript) in the context of the application.This allows hijacking the current session of the user or changing the look of the page by changing the HTML.This happens because the input entered by a user has been interpreted as HTML/JavaScript/VBScript by the browser.

Cross-site scripting targets the users of the application instead of the server.There are many different attacks that can Hijack user's active session.Mounting phishing attacks.Intercepting data and performing man-in-the-middle attacks.

To avoid this, output should be encoded according to the output location and context. You should implement a strong Content Security Policy (CSP) as a defense-in-depth measure if an XSS vulnerability is mistakenly introduced.

CSP will act as a safeguard that can prevent an attacker from successfully exploiting Cross-site Scripting vulnerabilities.