0% found this document useful (0 votes)
21 views46 pages

Content Security Policy

Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting and other code injection attacks. It works by whitelisting sources of approved content that browsers are allowed to load on a site, such as JavaScript, CSS, fonts, and images. The CSP is defined in HTTP headers using directives that specify allowed sources for different content types.

Uploaded by

vaidehi mehra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views46 pages

Content Security Policy

Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting and other code injection attacks. It works by whitelisting sources of approved content that browsers are allowed to load on a site, such as JavaScript, CSS, fonts, and images. The CSP is defined in HTTP headers using directives that specify allowed sources for different content types.

Uploaded by

vaidehi mehra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 46

Content Security Policy

What is it?

• “Content Security Policy (CSP) is a computer security standard


introduced to prevent cross-site scripting (XSS), clickjacking and
other code injection attacks resulting from execution of malicious
content in the trusted web page context. […] CSP provides a standard
method for website owners to declare approved origins of content that
browsers should be allowed to load on that website—covered types
are JavaScript, CSS, HTML frames, web workers, fonts, images,
embeddable objects such as Java applets, ActiveX, audio and video
files, and other HTML5 features.”
• – https://en.wikipedia.org/wiki/Content_Security_Policy
How does it work?

• Applied in the Content-Security-Policy HTTP header (more on HTTP


headers).
• With it, you can create a whitelist of trusted content sources.
• Because CSP occurs on the HTTP headers, it can implement security
early on.
What does it look like?

• The Content-Security-Policy is defined in the HTTP headers and is


provided with directives and their respective sources.
• HTTP Headers:
• Response Headers

Content-Security-Policy: <directive> <source list>; <directive>
<source list>;

• Directives can list multiple sources.
What are directives?

• Directives define the rules the browser must follow for various types
of resources.
• The main ones we will most often work with are:
• default-src, script-src, style-src, img-src, font-src
• But there’s plenty more…
• base-uri, frame-src, object-src, media-src, connect-src, form-action,
frame-ancestors, child-src, plugin-types, upgrade-insecure-requests,
worker-src, sandbox
What are source lists?

• Source lists are sets of strings which identify content that can be fetched and
potentially embedded or executed. For example, you may load styles from
your site, and fonts from Google.
• Sources can follow various formats:
• example.com – Allows resources from the specified domain name.
• *.example.com – Allows resources from any subdomain under
example.com.
• https://cdn.com – Only resources over HTTPS matching the given domain.
• https: – Allows loading resources only over HTTPS on any domain.
• data: – Allows resources via the data scheme (eg Base64 encoded images).
What is ‘self’ all about?

• Special keywords can be used instead of URLs.


• *
• ‘self’
• ‘unsafe-inline’
• ‘unsafe-eval’
• ‘strict-dynamic’
• ‘none’
• ‘nonce-‘
• ‘sha256-‘
• More on these here: https://content-security-policy.com/
How do I implement it?

• With the .htaccess file:


<IfModule mod_headers.c>
Header set Content-Security-Policy “default-src ‘self’; …”
</IfModule>
• With PHP (must happen before any other content):
header(“Content-Security-Policy: default-src ‘none’;”);
• With a <meta> tag (not recommended):
<meta http-equiv=”Content-Security-Policy” content=”default-src
‘self’”>
• With a plugin (yay!):
HTTP Headers or WP Content Security Policy Plugin
Will it break anything?

• Quite possibly, yes.


• Luckily there is the Content-Security-Policy-Report-Only header.
• Allows you to test your CSP without enforcing it.
• Format is the same as the Content-Security-Policy header.
Hypertext Transport Protocol
HTTP
• Hypertext Transport Protocol
• Language of the Web
• protocol used for communication between web browsers and web servers
• TCP port 80 (443 secure)
• RFC 2616 (ver 1.1)
URI,URN,URL
• Uniform Resource Identifier
• Information about a resource
• Uniform Resource Name
• The name of the resource with in a namespace
• Uniform Resource Locator
• How to find the resource, a URI that says how to find the resource
HTTP - URLs
• URL
• Uniform Resource Locator
• protocol (http, ftp, news)
• host name (name.domain name)
• port (usually 80 but many on 8080)
• directory path to the resource
• resource name
• http://xxx.myplace.com/www/index.html
• http://xxx.myplace.com:80/cgi-bin/t.exe
HTTP - methods
• Methods
• GET
• retrieve a URL from the server
• simple page request
• run a CGI program
• run a CGI with arguments attached to the URL
• POST
• preferred method for forms processing
• run a CGI program
• parameterized data in sysin
• more secure and private
HTTP - methods
• Methods (cont.)
• PUT
• Used to transfer a file from the client to the server
• HEAD
• requests URLs status header only
• used for conditional URL handling for performance
enhancement schemes
• retrieve URL only if not in local cache or date is more recent
than cached copy
HTTP Request Packets
• Sent from client to server
• Consists of HTTP header
• header is hidden in browser environment
• contains:
• content type / mime type
• content length
• user agent - browser issuing request
• content types user agent can handle
• and a URL
HTTP Request Headers
• Precede HTTP Method requests
• headers are terminated by a blank line
• Header Fields:
• From
• Accept
• Accept-Encoding
• Accept Language
HTTP Request Headers (cont.)
• Referer
• Authorization
• Charge-To
• If-Modified-Since
• Pragma
From:
• In internet mail format, the requesting user
• Does not have to correspond to requesting host name (might be a
proxy)
• should be a valid e-mail address
Accept:
• List of schemes which will be accepted by client
• <field> = Accept: <entry> * [,<entry>]
• <entry> = <content type> *[;<param>]
• <param> = <attr> = <float>
• <attr> = q / mxs / mxb
• <float> = <ANSI-C floating point >
• Accept: text/html
• Accept: audio/basic q-1
• if no Accept is found; plain/text is assumed
• may contain wildcards (*)
Accept-Encoding
• Like Accept but list is a list of acceptable encoding schemes
• Ex
• Accept-Encoding: x-compress;x-zip
User-Agent
• Software product used by original client
• <field> = User-Agent: <product>
• <product> = <word> [/<version>]
• <version> = <word>
• Ex.
• User-Agent: IBM WebExplorer DLL /v960311
Referer
• For Server’s benefit, client lists URL od document (or document type)
from which the URL in request was obtained.
• Allows server to generate back-links, logging, tracing of bad links…
• Ex.
• Referer: http:/www.w3.com/xxx.html
Authorization:
• For Password and authentication schemes
• Ex.
• Authorization: user fred:mypassword
• Authorization: kerberos kerberosparameters
ChargeTo:
• Accounting information
• Accounting system dependent
Pragma:
• Same format as accept
• for servers
• should be passed through proxies, but used by proxy
• only pragma currently defined is no-cache; proxy should get
document from owning server rather than cache
Modified-Since:
• Used with GET to make a conditional GET
• if requested document has not been modified since specified date a
Modified 304 header is sent back to client instead of document
• client can then display cached version
Response Packets
• Sent by server to client browser in response to a Request Packet
Status Header
• “HTTP/1.0 sp code”
• Codes:
• 1xx - reserved for future use
• 2xx - successful, understood and accepted
• 3xx - further action needed to complete
• 4xx - bad syntax in client request
• 5xx - server can’t fulfill good request
HTTP Response Headers
• Sent by server to client browser
• Status Header
• Entities
• Content-Encoding:
• Content-Length:
• Content-Type:
• Expires:
• Last-Modified:
• extension-header
• Body – content (usually html)
Status Codes
• 200 OK • 401 unauthorized
• 201 created • 403 forbidden
• 202 accepted • 404 not found
• 204 no content • 500 int. server error
• 301 moved perm. • 501 not impl.
• 302 moved temp • 502 bad gateway
• 304 not modified • 503 svc not avail
• 400 bad request
Statelessness

• Because of the Connect, Request, Response,


Disconnect nature of HTTP it is said to be a
stateless protocol
• i.e. from one web page to the next there is nothing in
the protocol that allows a web program to maintain
program “state” (like a desktop program).
• “state” can be maintained by “witchery” or “trickery”
if it is needed
Maintaining program “state”
• Hidden variables (<input type=hidden>
• Sessions
• Special header tags interpreted by the server
• Used by ASP, PHP, JSP
• Implemented at the language api level
Session Management

• Web Authentication, Session Management, and Access


Control:
Authentication General Guidelines

• User IDsEmail address as a User ID


Authentication Solution and Sensitive
Accounts
• Implement Proper Password Strength Controls
• Implement Secure Password Recovery Mechanism
• Store Passwords in a Secure Fashion
• Compare Password Hashes Using Safe Functions
• Transmit Passwords Only Over TLS or Other Strong Transport
• Require Re-authentication for Sensitive Features
• Consider Strong Transaction Authentication
• TLS Client Authentication
• Authentication and Error Messages
• Authentication Responses
• Incorrect and correct response examples
• Login
• Password recovery
• Account creation
• Error Codes and URLs
• SSL vs TLS
• Server Configuration
• Only Support Strong Protocols
• Only Support Strong Ciphers
• Use Strong Diffie-Hellman Parameters
• Disable Compression
• Patch Cryptographic Libraries
• Test the Server Configuration
• CertificatesUse Strong Keys and Protect Them
• Use Strong Cryptographic Hashing Algorithms
• Use Correct Domain Names
• Carefully Consider the use of Wildcard Certificates
• Use an Appropriate Certification Authority for the Application's
User Base
• Use CAA Records to Restrict Which CAs can Issue Certificates
• Always Provide All Needed Certificates
• Consider the use of Extended Validation Certificates
• ApplicationUse TLS For All Pages
• Do Not Mix TLS and Non-TLS Content
• Use the "Secure" Cookie Flag
• Prevent Caching of Sensitive Data
• Use HTTP Strict Transport Security
• Consider the use of Client-Side Certificates
• Consider Using Public Key Pinning
• Reference:
• https://cheatsheetseries.owasp.org/cheatsheets/
Transport_Layer_Protection_Cheat_Sheet.html#ssl-vs-tls
• Protect Against Automated Attacks
• Multi-Factor Authentication
• Account Lockout
• CAPTCHA
• Security Questions and Memorable Words
• Logging and Monitoring
• Use of authentication protocols that require no password
• OAuth
• OpenId
• SAML
• FIDO
• Password Managers
reference
• https://cheatsheetseries.owasp.org/cheatsheets/
Authentication_Cheat_Sheet.html#require-re-authentication-for-
sensitive-features

You might also like