A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
The application allows a user to submit a state changing request that does not include anything secret. Like so:http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243So, the attacker constructs a request that will transfer money from the victim’s account to their account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control.<imgsrc="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#“width="0" height="0" />If the victim visits any of these sites while already authenticated to example.com, any forged requests will include the user’s session info, inadvertently authorizing the request.
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data. For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request. In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.
Because many intranets support a single sign-on environment where authentication to a site can be performed transparently, the victim need not even use the application prior to being tricked into sending the forged request. Even if the victim is not authenticated and the application does not integrate with a single sign-on system, many authentication systems will intercept a request, require authentication, and then transparently transfer a client back to the original requested location. Because of this, even unauthenticated victims are subject to such attacks.
Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.
Preventing CSRF requires the inclusion of a unpredictable token in the body or URL of each HTTP request. Such tokens should at a minimum be unique per user session, but can also be unique per request.1.The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is subject to exposure.2.The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs the risk that the URL will be exposed to an attacker, thus compromising the secret token.OWASP’s CSRF Guardcan be used to automatically include such tokens in your Java EE, .NET, or PHP application. OWASP’s ESAPIincludes token generators and validatorsthat developers can use to protect their transactions.
A nonce is a one-time cryptographically random token that is returned to the client. For each request, a different nonce is created, so secrets are not reused. The nonce is sent to the client, and also saved on the server, and then compared when the operation request comes in. The downside of a nonce is that it needs to be stored on the server. If it’s stored in memory, it limits system scalability across multiple web or application servers.An HMAC is an encrypted hash or "keyed hash" of the page combined with the session ID. If you create an HMAC of the Page URL, plus the User ID or Session ID a comparison value can be created that will make distributed attacks very difficult. The downside is that every time the user returns to the page it is possible that the same page URL and user ID might be generated, making it possible to steal the secret and reuse it. So you should add a timestamp to the HMAC to ensure the secret value is unique for each request. The timestamp would be concatenated with the page URL and user ID. Like a salt, the timestamp plain text need not be kept secret or protected, and is most easily sent to the client in a hidden form field or placed in a state cookie. During the request, the timestamp is retrieved and added to the URL and ID to generate the comparison HMAC.
The OWASP CSRF Guard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRF Guard will generate a cryptographically random token using the SecureRandom class to be stored in the session.
2. ToC• Definition.• OWASP Rating.• Attack Scenarios.• CSRF in the wiled.• Demo time.• Detection• Protection.• Summery & Discussion. 2
3. DefinitionA CSRF attack is forcing a logged-on victim‟s browser to send a forged HTTP request, including the victim‟s session cookie and any other automatically included authentication information, to a vulnerable web application.Synonyms: XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking, One-Click (Microsoft). 3
9. In the wield..- Firewall web management.- Stored CSRF flaws.(Self-vulnerable applications)- Sammy Worm.Methodologies: XSS, Social Engineering…. 10
10. DetectionCode Review:• see if each link and form contains an unpredictable token for each user.• focus on state-changing functions.• check multistep transactions.PenTesting:• Manual Testing.• OWASP‟s CSRF Tester tool. 11
11. Protection[Developers]• Check referrer, Really help?!(open redirect/HTTPS/subdomains)• Double Submit Cookies.• Challenge-Response. (CAPTCHA/Re-Authentication)• Put unique token in the URL/URL parameter.• Include the unique token (per request/session) in a hidden field. No XSS & Share a ‘Secret’ With The User. 12
12. Protection[Tokens]Good Tokens:Nonce:One-time cryptographically random token that is returned to the client per request.HMAC:#(PageUrl+Session/userID+Timestamp)(eg In .net encrypted „ViewState‟) 13
13. Protection [Defense in depth]Do not use GET parameters.Do not put the secret in the URL/Cookies.(log/history/referer exposure,!)Send successful logins to a well-known location instead of automatic redirection.(Top10 A10)Do not resubmit POST parameters if you need to perform redirection. 14
14. Protection [Users]Logoff immediately after using a web applicationDo not allow your browser to save username/passwords, and do not allow sites to “remember” your loginDo not use the same browser to access sensitive applications and to surf freely the Internet.Be careful when clicking untrusted Links. 15
15. OWASP‟s ToolsOWASP‟s CSRF Guard can be used to automatically include such tokens in your Java EE, .NET, or PHP application.OWASP‟s ESAPI token generators and validators.+ OWASP‟s CSRF Tester. 16
16. OWASP Top 10 2010:A1 –InjectionA2 –Cross-Site Scripting (XSS)A3 –Broken Authentication and Session ManagementA4 –Insecure Direct Object ReferenceA5 –Cross Site Request Forgery (CSRF)A6 –Security Misconfiguration(NEW)A7 –Insecure Cryptographic StorageA8 –Failure to Restrict URL AccessA9 –Insufficient Transport Layer ProtectionA10 –Unvalidated Redirects and Forwards (NEW)