Same Origin PolicyCross-Origin Resource Sharing

Content Security Policy

subbul@gmail.com

Agenda

• Need for SOP• How CORS help SOP• What is XSS?• How CSP helps preventing XSS

Why Same Origin Policy ?• What if your personal data you are entering in a “Bank” page

in Browser is accessible to another Page in the browser Instance

What is Same Origin Policy

• This is a Browser Mechanism to allow trusted pages/scripts• To Prevent HTML/JS Application from different window, domain accessing the

DOM, data of Application current domain or “Origin”• Thanks to Same Origin Policy (SOP), Browser prevents loading or blocks request for

DOM access, execution of script from “Origin/Domain” other than “Self”

• More Details

What are allowed in SOP?

• SOP cannot prevent cross site content inclusions (like images, scripts, css from different domain

• http://www.google.com/page1 can access http://www.google.com/page2• http://www.google.com/page1 cannot access http://www.yahoo.com as the two pages

belong to different domain• <script> is allowed by SOP [file:// ??]• In a http://www.mypage.com page, you can include<script src=

http://api.google.com/googleplus >. • Google API page scripts are executed in “Mypage” domain, HTML Application, it will

still have access to “Mypage” DOM elements. So, if the “Google API scripts” are compromised, it will have bad effect on the “MyPage” (Will take it to XSS- Cross Site Scripting)

What is not allowed in SOP?

• AJAX (XHR) from One domain to another• XHR request from “MyPage.com” to “Google.com”• Why it is not allowed?– Using AJAX you can download a malicious JS code and could spoil the

current page information or could derive information from current page and send it over maliciously to remote pages

How to circumvent SOP• Simple suggestion DO NOT USE ( unless it’s the End of the World)• Document.domain• PostMessage• JSONP

• Right Way – CORS (Cross-Origin Resource Sharing)

Cross-Origin Resource Sharing

• CORS is to overcome SOP for XHR• Allowing Cross Origin Request from Domain A to Domain B using XHR• Introduction of new HTTP Headers (Origin) from Server to make Browser decide to

Allow Cross-Origin request or not• Use Pre-flight (handshake) OPTIONS request for methods other than POST/GET to

know if the server supports, allow-origin for your request

More Detail

How CORS works?

CORS HTTP Request/Response HeadersHTTP Request/ ResponseHeader

Parameter Description Example

Access-Control-Allow-Origin:

<origin> | * Specifying a particular “domain” is allowed or “*” all

Access-Control-Allow-Origin: http://mozilla.com

Access-Control-Allow-Credentials

True| false Request for cookie along with request

Access-Control-Request-Method

GET,POST Request for supported HTTP methods

Access-Control-Allow-Headers

Content-Type| Custom-Header

Preflight-request headers

CORS Server/Browser Request /Response Flow

http://www.html5rocks.com/static/images/cors_server_flowchart.png

XSS (Cross Site Scripting)• Finding Vulnerability of Web Pages and

injecting and injecting malicious client side- script .

• Types– Non-Persistent (server Echo’s back your

request)– Adding malicious scripts in HTML Forms,

HTTP Query from web browser during a search request. If the “String” is not formatted/escaped, the injected script will be executed back in client browser.

– E.g.,• Phishing Attacks, • URL Shortens (bit.ly ) taking to legitimate

page and injecting their “script” along with it

XSS (Cross Site Scripting)– Persistent (Server stores the data and

script)– Storing user provided “string” as is

without escaping the HTML, JS code in Webserver and serving later to all users will cause the malicious script to execute on client browser

– Message Boards, which include Plain Text and Scripts, later when another user reloads the Message Board, the malicious code executes and steals user data

– Defacing web servers, cookie/session stealing

Examples

• http://www.insecurelabs.org/Task/Rule1 • http://www.insecurelabs.org• https://www.owasp.org/index.php/Testing_for_Reflected_Cros

s_site_scripting_(OWASP-DV-001)

How to Prevent XSS

• Validation/Sanitization of ALL user inputs in a page• No inline please, keep it safe in a dedicated JS• Secure all input path, query string, file path etc• Don’t keep untrusted data in your HTML, JS• This is one of the reason, you find forms in organization preventing <, > etc

• https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

• And of course CSP (Content Security Policy)

Resource

Content Security Policy (CSP)• It’s a policy how Browser/UserAgent adhere to as a directive from

HTTP Server in order to display, execute scripts• New HTTP Headers introduced to enable CSP• Content-Security-Policy: script-src 'self'

https://abc.MyWebpage.com Trusted Source

Trusted Source

Content Security Policy• If a malicious code is injected through XSS (added <script src=“hackedsite.com”>), browser

will detect and prevent• More XSS prevention by• 'unsafe-inline' prevents inline JavaScript and CSS • 'unsafe-eval' prevents text-to-JavaScript mechanisms like eval • Default-src “none” (Shut down any other script, img, media load beyond my own)• Other resources which can be controlled by CSP are font-src,img-src etc

– http://www.html5rocks.com/en/tutorials/security/content-security-policy/– http://erlend.oftedal.no/blog/csp/readiness/– http://people.mozilla.org/~bsterne/content-security-policy/details.html– https://wiki.mozilla.org/index.php?title=Security/CSP/Spec&oldid=133465

Thank You