Contact Project Developer Ashish D. Tiwari [astiwz@gmail.com]
Download Synopsis Abstract
Websites Mobile Apps PHP Java Android BE-Engineering(CO/IT) ME-Engineering(CO/IT) BCS MCS BCA MCA MCM BSC Computer/IT MSC Computer/IT BE E&TC / ECE ME E&TC / ECE Diploma (CO/IT) Diploma E&TC / ECE IEEE-2016 Security

Mitigating Cross-Site Scripting Attacks with a Content Security Policy

A content security policy (CSP) can help Web application developers and server administrators better control website content and avoid vulnerabilities to cross site scripting (XSS)
Abstract-Synopsis-Documentation

Mitigating Cross-Site Scripting Attacks with a Content Security Policy.

ABSTRACT

A content security policy (CSP) can help Web application developers and server administrators better control website content and avoid vulnerabilities to cross site scripting (XSS). In experiments with a prototype website, the authors’ CSP implementation successfully mitigated all XSS attack types in four popular browsers. Among the many attacks on Web applications, cross site scripting (XSS) is one of the most common. An XSS attack involves injecting malicious script into a trusted website that executes on a visitor’s browser without the visitor’s knowledge and thereby enables the attacker to access sensitive user data, such as session tokens and cookies stored on the browser.1 With this data, attackers can execute several malicious acts, including identity theft, key logging, phishing, user impersonation, and webcam activation. Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP is designed to be fully backward compatible; browsers that don't support it still work with servers that implement it, and vice-versa. Browsers that don't support CSP simply ignore it, functioning as usual, defaulting to the standard same-origin policy for web content. If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy.Enabling CSP is as easy as configuring your web server to return the Content-Security-Policy HTTP header. (Prior to Firefox 23, the X-Content-Security-Policy header was used). See Using Content Security Policy for details on how to configure and enable CSP.

IMPLEMENTATION

An XSS attack can be persistent or nonpersistent, or it can be based on a document object model (DOM).

MODULES

Persistent XSS

2.Nonpersistent XSS

3.DOM-based XSS

1. Persistent XSS

A persistent XSS attack, also known as a stored XSS or Type-I XSS attack. This attack type involves injecting malicious script into a website, which stores the script in its database. If the script is not correctly filtered, it will appear to be a part of the Web application and run within a user’s browser under the application’s privileges. 

A persistent XSS attack does not need a malicious link for successful exploitation; simply visiting the webpage will compromise the user. Persistent XSS is often difficult to detect and is considered more harmful than the other two attack types. Because the malicious script is rendered automatically, there is no need to target individual victims or lure them to a third party website. 

Consequently, attackers can easily hide their activity; for example, in a blog, they could embed the script in a seemingly innocuous comment. All visitors to that site would then unknowingly put their browser—and the sensitive data stored on it—at risk.


 2. Nonpersistent XSS

 A nonpersistent, or reflected, XSS attack , which occurs when a website or Web application passes invalid user inputs. Usually, an attacker hides malicious script in the URL, disguising it as user input, and lures victims by sending emails that prompt users to click on the crafted URL.

 When they do, the harmful script executes in the browser, allowing the attacker to steal authenticated cookies or data. In the figure, we assume that victims have authenticated themselves at the vulnerable site.


 3. DOM-based XSS 

A webpage is composed of various elements, such as forms, paragraphs, and tables, which are represented in an object hierarchy. To update the structure and style of webpage content dynamically, all Web applications and websites interact with the DOM, a virtual map that enables access to these webpage elements. 

Compromising a DOM will cause the client-side code to execute in an unexpected manner. A DOM-based, or Type-0, XSS attack executes in the same manner as a nonpersistent XSS attack except for step 3.In a DOM-based attack, rather than having the server carry the malicious payload in its HTTP response, the attacker encodes a malicious value in a URL and sends it to the victim. 

The attack occurs when the victim’s browser executes the malicious code from the modified DOM. On the client side, the HTTP response does not change but the script executes maliciously. This exploit works only if the browser does not modify the URL characters.A DOM-based XSS attack is the most advanced type and is not well known. Indeed, much of the vulnerability to this attack type stems from the inability 


Comment is Only Available for registered users! Create Account or Login Now!