Cross Site Scripting (XSS) + CSP

XSS Attacks, CSP

Objectives

Cross Site Scripting

Catagorizing CSS Attacks - Stored | Reflected | DOM Based Attacks
XSS Mitigation

Content Security Policy

Writing CSP Policy Examples
Implementing CSP - Testing Policy and Report Enabling

Cross Site Scripting XSS

A type of injection, in which malicious scripts are injected into websites

Stored XSS Attacks

Where the injected malicious script is permanently stored on the target servers [Persistant]

Reflected XSS Attacks

Where the injected malicious script is reflected off of a web application to the victim’s browser. [None Persistant]

Other XSS Attacks:

DOM Based XSS-attackers smuggle malicious JS into a user's web page via the URI fragment.

Cross Site Scripting Attacks are when attackers inject malicious JavaScript into the browser. Without the proper security measures implemented for the client, the server and even the application, a browser will obediently execute any Javascript code that appears in a web page. So what are the possible dangers. It's possible to steal login credentials or other sensitive informatin like credit card numbers as a user types them in. There's the possibility of disclosing files, installation of Trojan horse programs, redirecting the user to some other page or site, or modify content or HTML code. If JavaScript can read the HTTP session information. And we'll talk sessions in the comming weeks, but if they are able to read the session information an attacker can hijack a user's session entirely this is called Session Hijacking. Theres two primary categories. Stored and Reflected Cross Site Scripting Attacks. On the slide, you will see the word persistant for stored Cross site scripting attacks and non-persistant. With stored attacks, these are saved on the server, more specifically the database. An example of a possible attack would be submitting a link that contains some JS code using the script tags into the comment section of an app. Typically the chat session data is saved to a database and rendered back to the client as a clickable link. Once the link is clicked, the browser interprets the JavaScript. So what we put into the text box was actually javascript code, but when rendered back in the chat view, the browser will interepet are code and execute the code. This code is saved to the database and anyone who is also on the thread will be able to see the code and may be tempted to click the link also. With reflected, Typically, an attacker would first test the site to see if they can execute a script in a input field. The input field you might put the opening and closing script tag and try to initiate an alertbox. If you are able to initiate an alertbox, you now know that the site does not have the correct security measures implemented.

Good Video on XSS

Example 1 (Reflected XSS)

Data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker’s content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user’s machine to the attacker or perform other nefarious activities.

Example 2(Stored XSS)

The application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker’s perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

Performing Reflected Cross Scripting Attack

We can do this using default parameters, where we add an equal sign and the default value at the end of the parameter or structure the URL to execute JS code that makes a HTTP request to desired location.

								
								// 1) test browser for execution of JS code
								// 2) Formulate URL to execute JS code as endpoint
								
								
								<script type="text/javascript">
									var information = '../hackinfo?getCookies=' + escape(document.cookie);
								</script>

Mitigating both Reflected and Stored

Escaping control characters in dynamic content that the website interpolates into HTML

Modern templating and front-end frameworks implement this feature

Helpful tips for finding XSS Attacks

Test URL Endpoints
Test the attack in a browser

Implement a Content Security Policy!!

When mitigating Cross Site Scripting attacks, there are a number of things we can do. Some are small measures, but helpful. Limiting the number of characters that are allowed in input fields. Although this can be altered, it is still a good practice. Health Insurance provider Blue Cross Blue Shield always cuts my name off and I want to think that this is a small measure of security that is being implemented. Escaping content is key, whether dynamic content comes from the backend database or the HTTP request, you need to escape it in the same way. For testing URL Endpoints - Submit a unique random value and determine whether the value is reflected in the response For testing in the browser - execute some simple JavaScript like alert(document.domain) which will trigger a visible popup within the browser if the attack succeeds.

Content Security Policy (CSP)

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts

What Does CSP Prevent??

XSS - CSP automatically blocks the code from sending sensitive information to the hacker's domain.
Browser Hijacking & Ad Injection - Client-side malware causes unwanted ads to appear on your users' browsers. A CSP prevents these ads from loading when affected users go on your website.
Unauthorized Piggyback Tags - One tag could also be loading multiple tags from vendors you have not authorized. A CSP eliminates this security risk..

Implementing a CSP

							
							// 1) Via the server: Example Below
							Content-Security-Policy: default-src 'self' trusted.com *.trusted.com
							
							// 2) Meta tag with head of site
							<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; img-src https://*; child-src 'none';" />
							
							// 3) We can use the set method of the Express Response object
							res.set("Content-Security-Policy", "default-src 'self'");

Consideration 1
Implement via the server. If you have access

Consideration 2
Use of Meta Tag within HTML

Consideration 3
Use within Middleware Configuration with Express.js

Enabling Reporting on CSP

							
							// 1) Server Implementation: 
							Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/

Implementation
Implemented via the server. You will need to set up your server to receive the reports; it can store or process them in whatever manner you determine is appropriate.

Sample Output of Report

							
							{
						    "csp-report": {
						        "document-uri": "https://mplsrenters.com/",
						        "referrer": "",
						        "violated-directive": "script-src",
						        "effective-directive": "script-src",
						        "original-policy": "default-src 'none'; form-action 'none'; frame-ancestors 'none'; report-uri https://mplsrenters.com/r/d/csp/wizard",
						        "disposition": "report",
						        "blocked-uri": "inline",
						        "line-number": 4,
						        "source-file": "https://mplsrenters.com/",
						        "status-code": 0,
						        "script-sample": ""
						    }
						}