Introduction:
Trust is the fundamental key to the Internet. You trust your internet service provider to keep your connection up-to-date. It is important to your developers that you trust the architecture provider when they say that your servers will remain available and that customers trust that you’re safely securing their data. Additionally, they trust that what they see on your website is what you intend for them to see.
The most common attacks people face in a web application are Cross-site scripting, Clickjacking, and some injection attacks. So, an Internet Service Provider is responsible for providing them security. There is a Policy that helps secure your application from these types of attacks. That policy is called Content-Security-Policy.
In this article, we will discuss Content-Security-Policy (CSP). Before we start, Let's talk about ‘Cross-Site-Scripting' attacks.
What is Cross-Site-Scripting?
Cross-Site-Scripting (XSS) is an Injection attack in which an advisor (attacker) can inject a malicious payload or code and gain user credentials, important data, cookies, tokens, etc.
Cross-Site-Scripting attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user.
Scenario 1:
“Now the main thing is how to protect your application from XSS attacks.”
.png)
So, if you want to
protect your application from XSS attacks, you must know about
Content-Security-Policy (CSP).
What is Content-Security-Policy?
Content Security Policy is the most
powerful browser security feature to prevent Cross-Site-Scripting, Clickjacking and some Injection attacks. It can use the X-Frame-Options of the security header or Meta tag
to prevent Cross-Site-Scripting (XSS).
A Content Security Policy mostly restricts the sources and types of content and where on the page that content can be presented, or rendered. In terms of preventing Cross-Site-Scripting, "inline JavaScript" tends to be the first vector for malicious content. Basically, Inline JavaScript is when code is placed in a "<script>", "eval()", "<img>", "<svg>" tag in the body of the HTML document. In addition, preventing inline JavaScript will also stop code from executing on event listeners such as "onClick" or "onHover" attributes, which are common vectors for XSS. Typically speaking, it is bad practice to use inline JavaScript - Using a CSP to prevent inline JavaScript from executing is not only a great security feature, but it also enforces good code hygiene.
How to use Content-Security-Policy?
Content-Security-Policy acts
as a Rakshak (Protector) against Cross-Site-Scripting and
injection attacks.
Every developer
and researcher should be aware of CSP. Let’s look at ‘how CSP can be used as a
Rakshak?’
In addition to helping and caring for his soldier, Rakshak also knows how to manage him. Similarly, we must be able to configure a Content-Security-Policy clearly. CSP cannot protect Web Applications if there is any misconfiguration. And now directives are like soldiers. So, how should you manage your soldiers or directives? It's totally up to you.
👉Mostly
usable CSP directives and their usage:
Content-Security-Policy provides a wide range of directives, each one specific to a content type. As part of the content security policy, the following directives are provided:
|
default-src |
img-src |
|
connect-src |
media-src |
|
frame-src |
object-src |
|
script-src |
frame-ancestors |
|
sandbox |
child-src |
|
style-src |
|
Before moving into the directives, here are a few
basic keywords that are used in CSP directive values:
* (asterisk): Allow anything
none: Won't allow loading
of any resources
self: Only allow
resources from the current origin
unsafe-inline: Allow use
of inline resources
unsafe-eval: Allow use of
dynamic code evaluation
https: Allow resources only over HTTPS
Syntax of Content-Security-Policy:
👉 Content-Security-Policy Header
Content-Security-Policy: <policy-directive>; <policy-directive>
👉 Content-Security-Policy
Meta Tag
<meta http-equiv=“Content-Security-Policy” content=“<policy-directive>” />
Where <policy-directive> consists of: <directive> <value> with no internal punctuation.
Now let's examine each of the content security
policy directives with examples:
default-src :
The default-src directive defines the default policy for fetching resources such as
JavaScript, images, frames, CSS, AJAX requests, Fonts and HTML5 Media. Always
remember that the default-src directive is not applicable to all directives.
Example of default-src Policy:
default-src
'self' cdn.intelliroot.com;
img-src :
The img-src directive
defines a valid source of images.
Example of img-src Policy:
img-src 'self' img.intelliroot.com;
connect-src :
The connect-src applies to XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> or Event
Source. The browser emulates a 400 HTTP status code if
it is not allowed.
Example of connect-src Policy:
connect-src 'self';
media-src :
The media-src defines a valid source of audio and video, (e.g., HTML5 <audio>, <video> elements).
Example of media-src Policy:
media-src media.intelliroot.com;
frame-src :
The frame-src defines valid sources for loading frames. In CSP Level 2 frame-src was
deprecated in favor of the child-src directive. CSP Level 3, has undeprecated
frame-src and it will continue to defer to child-src if not present.
Example of frame-src Policy:
frame-src 'self';
object-src :
The object-src defines valid sources of plugins, e.g., <object>, <embed> or <applet>.
Example of object-src Policy:
object-src 'self';
script-src :
The script-src defines a valid source of JavaScript.
Example of script-src Policy:
script-src 'self' js.itelliroot.com;
frame-ancestors:
The frame-ancestors defines valid sources for embedding the resource using <frame> <iframe> <object> <embed> <applet>. Setting this directive to 'none' should be
roughly equivalent to X-Frame-Options: DENY
Example of frame-ancestors Policy:
frame-ancestors 'none';
Sandbox:
Enables a sandbox
for the requested resource similar to the iframe sandbox attribute.
The sandbox applies a same origin policy, prevents popups, plugins and script
execution is blocked. You can keep the sandbox value empty to keep all
restrictions in place, or add values: allow-forms, allow-same-origin, allow-scripts, allow-popups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, and allow-top-navigation.
Example of sandbox Policy:
sandbox allow-forms allow-scripts;
child-src:
The child-src defines
valid sources for web workers and nested browsing contexts loaded using
elements such as <frame> and <iframe>
Example of child-src Policy:
child-src 'self'
style-src:
The style-src defines
valid sources of stylesheets or CSS.
Example of style-src Policy”:
style-src 'self' css.intelliroot.com;
Scenario 2:
Using Multiple
Content-Security-Policies:
It is
possible to specify multiple policies for a resource using the Content-Security-Policy header, the Content-Security-Policy-Report-Only header, and the <meta> element.
So, you can use the Content-Security-Policy header more than once. Using multiple Content-Security-Policies
results in better security for the web application.
Conclusion:
Content security policy is one of the best features to prevent Cross-Site-Scripting attacks, when used correctly. It is important to develop a strategy that will be effective when implementing your CSP. By doing so, you will be able to control which scripts are allowed in your applications more strictly. The styles used in applications are the same.
Using a CSP that is supported by a wide range of browsers would be a great advantage. Chrome supports all CSPs. With a CSP, you will be able to keep converting scripts so that your website will be secure. You can generate an automatic content Content-Security-Policy from https://report-uri.com/home/generate.
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://content-security-policy.com
https://www.appsecmonkey.com/blog/content-security-policy
){kind=link}
0 Comments