OWASP Khartoum - Top 10 A5 - 7th meeting - Cross Site Request Forgery
•Télécharger en tant que PPTX, PDF•
2 j'aime•895 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à OWASP Khartoum - Top 10 A5 - 7th meeting - Cross Site Request Forgery
Similaire à OWASP Khartoum - Top 10 A5 - 7th meeting - Cross Site Request Forgery (20)
Plus de OWASP Khartoum
Plus de OWASP Khartoum (9)
OWASP Khartoum - Top 10 A5 - 7th meeting - Cross Site Request Forgery
- 1. Cross Site Request Forgery Obay Osman OWASP Khartoum 15 Sept 2012 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
- 2. ToC • Definition. • OWASP Rating. • Attack Scenarios. • CSRF in the wiled. • Demo time. • Detection • Protection. • Summery & Discussion. 2
- 3. Definition A 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
- 4. OWASP Risk Rating # 4
- 5. Attack Scenarios User: http://bank.com/app/transferFunds?amount=1 500&destinationAccount=4673243243 Attacker: <img src= "http://bank.com/app/transferFunds?amo unt=1500&destinationAccount=attackersA cct#“ width="0" height="0" /> 5
- 6. #1 6
- 7. #2 7
- 8. Let us break something… 9
- 9. In the wield.. - Firewall web management. - Stored CSRF flaws.(Self-vulnerable applications) - Sammy Worm. Methodologies: XSS, Social Engineering…. 10
- 10. Detection Code 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 application Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login Do 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 Tools OWASP‟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
- 17. OWASP Top 10 2010: A1 –Injection A2 –Cross-Site Scripting (XSS) A3 –Broken Authentication and Session Management A4 –Insecure Direct Object Reference A5 –Cross Site Request Forgery (CSRF) A6 –Security Misconfiguration(NEW) A7 –Insecure Cryptographic Storage A8 –Failure to Restrict URL Access A9 –Insufficient Transport Layer Protection A10 –Unvalidated Redirects and Forwards (NEW)
- 18. Ref. • https://www.owasp.org/index.php/CSRF • https://www.owasp.org/index.php/Testing_for_CSRF_ %28OWASP-SM-005%29 • https://www.owasp.org/index.php/Cross- Site_Request_Forgery_%28CSRF%29_Prevention_Ch eat_Sheet • http://cwe.mitre.org/data/definitions/352.html • https://www.trustwave.com/sae_sample/owasp-top- 10/CourseFiles/Player.htm
- 19. 20
Notes de l'éditeur
- Access Control Attacks
- 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.
- The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.You should check multistep transactions, as they are not inherently immune. Attackers can easily forge a series of requests by using multiple tags or possibly JavaScript.Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesn’t count since this information is also included in forged requests.OWASP’s CSRF Testertool can help generate test cases to demonstrate the dangers of CSRF flaws.
- 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.
- Do not use GET parameters. Although it’s possible to perform CSRF attacks via POST parameters, it limits the types of manipulation a malicious user can perform on the victim to forge the request.Do not put the secret in the URL; the URL should not to contain any kind of secret. Broken authentication and session can be seen in weblogs and accessed via JavaScript.Send successful logins to a well-known location instead of automatic redirection. Do not resubmit POST parameters if you need to perform redirection.
- 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.