Published on

Presentation about Same Origin Policy, CORS, Content SecurityPolicy, XSS

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Same Origin Policy Cross-Origin Resource Sharing Content Security Policy
  2. 2. Agenda • • • • Need for SOP How CORS help SOP What is XSS? How CSP helps preventing XSS
  3. 3. 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
  4. 4. 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
  5. 5. What are allowed in SOP? • SOP cannot prevent cross site content inclusions (like images, scripts, css from different domain • can access • cannot access as the two pages belong to different domain • <script> is allowed by SOP [file:// ??] • In a page, you can include<script src= >. • 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)
  6. 6. What is not allowed in SOP? • AJAX (XHR) from One domain to another • XHR request from “” to “” • 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
  7. 7. 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)
  8. 8. 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
  9. 9. How CORS works?
  10. 10. CORS HTTP Request/Response Headers HTTP Request/ ResponseHeader Parameter Description Example Access-Control-AllowOrigin: <origin> | * Specifying a particular “domain” is allowed or “*” all Access-Control-AllowOrigin: Access-Control-AllowCredentials True| false Request for cookie along with request Access-ControlRequest-Method GET,POST Request for supported HTTP methods Access-Control-AllowHeaders Content-Type| Custom-Header Preflight-request headers
  11. 11. CORS Server/Browser Request /Response Flow
  12. 12. 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 ( ) taking to legitimate page and injecting their “script” along with it
  13. 13. 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
  14. 14. Examples • • • s_site_scripting_(OWASP-DV-001)
  15. 15. 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  • vention_Cheat_Sheet • And of course CSP (Content Security Policy)
  16. 16. 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' Trusted Source Resource Trusted Source
  17. 17. Content Security Policy • If a malicious code is injected through XSS (added <script src=“”>), 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 – – – –
  18. 18. Thank You