Upcoming SlideShare
Loading in...5




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

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



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Browsers_SameOriginPolicy_CORS_ContentSecurityPolicy Browsers_SameOriginPolicy_CORS_ContentSecurityPolicy Presentation Transcript

  • Same Origin Policy Cross-Origin Resource Sharing Content Security Policy
  • 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 • 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)
  • 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
  • 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 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
  • CORS Server/Browser Request /Response Flow
  • 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
  • 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 • • • 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  • vention_Cheat_Sheet • And of course CSP (Content Security Policy)
  • 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
  • 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 – – – –
  • Thank You