• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
A5 cross site request forgery.pptx

A5 cross site request forgery.pptx






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

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

    A5 cross site request forgery.pptx A5 cross site request forgery.pptx Presentation Transcript

    • A5 Cross-Site Request ForgeryProblem and Protection
    • What if ...o  We have a forum that allows HTML encoding.o  A logged-in user posts a note that renders as:<div class="normal">Heres a picture of my lolcat:<img alt="Image cannot be found" src=http:// www.facebook.com/like.php?User=AgileGadgets />.<br / ><br />Enjoy!</div>o  What happens?o  Everyone who is _______ in to ___________ will automatically ________ you.
    • Cross-site request forgeryo  CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action.o  Understand: websites dont verify a user.o  Websites can verify only that the request came from the browser of an authorized user.o  Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.
    • Cross-site request forgeryo  aka •  CSRF •  sea surf •  XSRF •  one-click attack •  session-riding •  hostile linking •  confused deputy •  automation attack
    • How attackers do ito  Post the attack and get victims to navigate to it.o  Create and host a web page with the attack on it.o  Find a public site that allows posting (blog responses, forums) and put up a malicious link.o  How do they get people to hit their tainted pages? •  Phishing emails •  Blog posts and replies •  Chat
    • What does the attack look like?
    • How we do not protect ourselveso  Check the HTTP referrer •  Myth: If we check the referrer and only honor requests that originated from our site, we can eliminate CSRFs that came from some other site. •  Reality: The HTTP referrer is easily spoofed resulting in false positives and is stripped by some hosts and elements resulting in false negatives.o  Using some secret cookie •  Myth: If our secret cookie is missing from the request, well know its illegitimate. •  Reality: All cookies are submitted with each request.o  Only accepting POST requests •  Myth: If we only put business logic behind POSTs vs. GETs, a simple link click cant fire event logic. •  Reality: Attacker can cause POSTs via JavaScript or by having a form that posts on any event including Load or Ready.o  Multi-step transactions •  Myth: If the victim has to confirm everything, it cant be automated. •  Reality: Once the attacker learns the steps, he simply has to automate each step.
    • How we protect ourselveso  Synchronizer token patterno  Require user interactiono  Clear sessions early and often
    • Synchronizer Token Pattern1.  Server writes a token to session.2.  Server puts a token in the browser response. •  Pre-crafted querystring •  Cookie •  Hidden field3.  Browser sends a new request to the server. This request has the client-side token.4.  Server compares the token in the request to the token it saved to session.5.  If theyre the same, were genuine. If different, it is a CSRF attack.
    • One token per sessiono  Generate a value when a user gets a session.o  Put that in every page in a hidden field.o  If we stop seeing that value in some page, we know its not a valid user.
    • Unique token per requesto  On page 1s unload: •  Generate a new token (random number or GUID). •  Put that token in a hidden form field. •  Save it to session.o  On page 2s load: •  Read the token from session. •  Read it from the hidden form field. •  If they dont match, reject the action.
    • Use ViewStateo  ASP.NET webforms pages have a hidden field with ViewState. It stores the values in all ofo  Used so that the server knows which of the original form field values were changed.o  Tells the ASP.NET engine which events must be run. •  ex: If a textbox value is different from what is stored in ViewState, the engine knows it must run the textChanged event.o  If it is required by your sensitive page and is missing, it will thwart the attacker.o  (But to bypass, he can run your app and grab his own ViewState for replay in the attack.)
    • Page.ViewStateUserKeyo  This is a property calculated and encoded to match the user who started the Session.o  So if an attacker tries to fake a ViewState, it will be detected and flagged as an error.o  To enable it, do this.protected override OnInit(EventArgs e){ base.OnInit(e); if (User.Identity.IsAuthenticated) ViewStateUserKey = Session.SessionID;}
    • Require user interactiono  Before performing the sensitive action, require the user to respond: •  reenter a username and password. •  Use a CAPTCHAo  The attacker may have a session cookie, but he does not know the username and password used to get that cookie.
    • Clear sessionso  If a session doesnt exist, it cant be used.o  Users often think that if they clear their session cookies, theyre safe. False! •  Must be done ___________-side.
    • Summaryo  When an attacker tricks logged-in users into hitting some URL that is pointing at another site, it is a cross-site request forgery.o  Use the synchronizer token pattern to protect your surfers. •  Use the cookie, but also manually check a hidden form field or QueryString.o  Expiring sessions promptly can also help.
    • Further studyo  Synchronizer token pattern: •  http://bit.ly/SychronizerTokeno  Summary of ASP.NET security hints: o  http://bit.ly/ASPSecurityHintso  ViewState decoder: •  http://bit.ly/ViewStateDecoder