A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz
When a user interacts with a web application, they do it indirectly through a browser. When the user clicks a button or submits a form, the browser sends a request back to the web server. Because the browser runs on a machine that can be controlled by an attacker, the application must not trust any data sent by the browser.
It might seem that not trusting any user data would make it impossible to write a web application but that's not the case. If the user submits a form that says they wish to purchase an item, it's OK to trust that data. But if the submitted form also includes the price of the item, that's something that cannot be trusted.
Get Gruyere to issue you a cookie for someone else's account.
The previous section said "If the user submits a form that says they wish to purchase an item, it's OK to trust that data." That's true as long as it really was the user that submitted the form. If your site is vulnerable to XSS, then the attacker can fake any request as if it came from the user. But even if you've protected against XSS, there's another attack that you need to protect against: cross-site request forgery.
When a browser makes requests to a site, it always sends along any cookies it has for that site, regardless of where the request comes from. Additionally, web servers generally cannot distinguish between a request initiated by a deliberate user action (e.g., user clicking on "Submit" button) versus a request made by the browser without user action (e.g., request for an embedded image in a page). Therefore, if a site receives a request to perform some action (like deleting a mail, changing contact address), it cannot know whether this action was knowingly initiated by the user — even if the request contains authentication cookies. An attacker can use this fact to fool the server into performing actions the user did not intend to perform.
The goal here is to find a way to perform an account changing action on behalf of a logged in Gruyere user without their knowledge. Assume you can get them to visit a web page under your control.
Find a way to get someone to delete one of their Gruyere snippets.
Browsers prevent pages of one domain from reading pages in other
domains. But they do not prevent pages of a domain from referencing
resources in other domains. In particular, they allow images to be
rendered from other domains and scripts to be executed from other
domains. An included script doesn't have its own security context. It
runs in the security context of the page that included it. For
www.evil.example.com includes a script hosted
www.google.com then that script runs in
evil context not in the
Find a way to read someone else's private snippet using XSSI.
That is, create a page on another web site and put something in
that page that can read your private snippet. (You don't need to post
it to a web site: you can just create a
.html in your
home directory and double click on it to open in a browser.)
© Google 2010 Terms of Service
The code portions of this codelab are licensed under the Creative Commons Attribution-No Derivative Works 3.0 United States license <http://creativecommons.org/licenses/by-nd/3.0/us>. Brief excerpts of the code may be used for educational or instructional purposes provided this notice is kept intact. Except as otherwise noted the remainder of this codelab is licensed under the Creative Commons Attribution 3.0 United States license <http://creativecommons.org/licenses/by/3.0/us>.