Spread the love

CSP – Content Security Policy

CSP is a W3C specification offering the possibility to instruct the client browser from which location and/or which type of resources are allowed to be loaded/ executed.

The supported directives are:

  • default-src : Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),
  • script-src : Define which scripts the protected resource can execute,
  • object-src : Define from where the protected resource can load plugins,
  • style-src : Define which styles (CSS) the user applies to the protected resource,
  • img-src : Define from where the protected resource can load images,
  • media-src : Define from where the protected resource can load video and audio,
  • frame-src : Define from where the protected resource can embed frames,
  • font-src : Define from where the protected resource can load fonts,
  • connect-src : Define which URIs the protected resource can load using script interfaces,
  • form-action : Define which URIs can be used as the action of HTML form elements,
  • sandbox : Specifies an HTML sandbox policy that the user agent applies to the protected resource,
  • script-nonce : Define script execution by requiring the presence of the specified nonce on script elements,
  • plugin-types : Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
  • reflected-xss : Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
  • report-uri : Specifies a URI to which the user agent sends reports about policy violation

HTML5Rocks has a very good explanation of CSP.

The main aim of this post is to explain the CSP in a Real Time Example which shall explain the importance of it and how to mitigate attack vectors like XSS, ClickJacking, Code Injection etc.

Real Time Example:

In order to understand CSP in a real time, I shall be referring LinkedIn.

Scenario:

Before Jan 2018, LinkedIn Publishing Platform, also popularly knows as the Articles/ Posts feature for every user in LinkedIn had a HTML Code Injection Vulnerability/ Flaw.  The vulnerability enables an attacker to inject another website’s code as a frame in it resulting in the users viewing the article to be easily deceived.

The vulnerability was RESPONSIBLY disclosed to LinkedIn’s Security Engineering Team through their Bug Bounty Program. Even though LinkedIn DID NOT AWARD us a BugBounty, they did acknowledge the issue and assured the fix back in March 2017.

NOTE: LINKEDIN DOES HAVE A BUG BOUNTY PROGRAM THOUGH IS CURRENTLY NOT OPEN TO PUBLIC. BELOW IS THE MAIL ACKNOWLEDGING THE SAME.

Please find the Vulnerability Execution in the Video Below:

Email Acknowledgement:

Exploit Steps:

Step#1:

We created 2 webpages as shown below:

Page#1: log.html
========================
<html>
<title>
<script>alert(1)</script>
</title> 
<head>
<script>alert(“You are logged out of LinkedIn! Please login now”); location=”/login.html”</script>
</head>
</html>

Page#2: login.html

================

<html>
Login : <input name=”user”>Password : <input name=”pass”>
<button>Submit</button>
</html>

================

Step#2:

In the Article, embed the link which is https://amisafe.secops.in/log.html and automatically <head> data is parsed and displays it on the page as shown below:

Step#3:

When a User clicks on the page, it first gives the Alert “You are logged out of LinkedIn! Please login now“:

Step#4: Automatically follows:

When the User clicks “OK”, the article is displaying the next page that has the login credentials as shown below. Since there is is no sign of user being logged in on the page on the right hand side corner as per LinkedIn standard display pages, the possibility of a user to input their username/password to view the secure content is very high!

FIX? Content Security Policy (CSP):

CSP Enabled LinkedIn to whitelist all the resources from which a script/ frame or any content from a 3rd party domain can be rendered/ parsed on their site ensuring that such evil cases described above do not get executed. They successfully implemented CSP in the month of January 2018 (LinkedIn Team to confirm the exact timelines)

Current Status:

Implemented CSP:

Testing:

 

Hits: 1363

Related articles