Cross Site Request Forgery (CSRF)

1. Cross Site Request Forgery(CSRF)

2. Definition: Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. example: You are logged in to a web application XYZ and then You opened your favorite web-forum or any other website and a task is automatically initiated in the web application XYZ under your credential without your intention

3. A little Overview.

4. What can be done through CSRF? Most of the tasks allowed by the website (through GET or even through POST request) can be performed by an attacker utilizing CSRF e.g. on an ADDM appliance 10.128.33.172 we can schedule an discovery scan though a get request through following URL: http://10.128.33.172/ui/DiscoveryEcaEngineState?scanType=SCAN_ONCE&range=1.2.3.4

5. What are common ways to perform a CSRF attack? The most popular ways to execute CSRF attacks is by using a HTML image tag, or JavaScript image object. Typically an attacker will embed these into an email or website so when the user loads the page or email, they perform a web request to any URL of the attackers liking. Below is a list of the common ways that an attacker may try sending a request. HTML Methods IMG SRC <imgsrc="http://host/?command"> SCRIPT SRC <script src="http://host/?command"> JavaScript Methods 'Image' Object <script> varfoo = new Image(); foo.src = "http://host/?command"; </script>

6. Can applications using only POST be vulnerable? Yes. An attacker could craft a web form on site A and using JavaScript auto submit the form to a target location of Site b. There's another way to attack a website using purely POST based parameters, however this depends entirely on how the web application was developed. Popular web based libraries such as Python webware allow a developer to fetch a parameter without caring if it came in through a GET or POST request. As is the case with certain usages of webware, POST requests can be converted to GET by the attacker and the application action will still be performed. example: #does not care about request type fileld1 = self.request().field('myField')

7. CSRF Attack Example (using post )

8. How do I detect if a website is vulnerable? If your website allows performing a site function using a static URL or POST request (i.e. one that doesn't change) then it is possible. If this command is performed through GET then it is a much higher risk. Overall if you are able to perform the same function using the GET or POST request repeatedly then the site application may be vulnerable.

9. <input type=hidden value=23a3af01b> Referer: http://www.facebook.com/home.php CSRF Defence • Referer Validation • Secret Validation Token

10. Referer: http://www.facebook.com/ Referer: http://www.evil.com/attack.html Referer: Referer Validation   ?

11. Secret Validation token The solution that is generally used is to place a token, that has a limited life-time, in the URL or in the page itself, and, when the URL is fetched, check that this token is still valid. The basic idea would be : - When generating the page : - generate a unique token - store it in the user's session and place it in the links of the page . When the HTTP request is made : - Check if the token is present in the URL - Check if it's present in the user's session - If not => do not perform the action

12. Secret Validation token (Contd…) The idea there is : Tokens don't have a long life-time, and are hard to guess which means your attacker : • has only a window of a few minutes during which his injection will be valid • will have to be good at guessing ^^ - will have to generate a different page for each user and each session.

13. References http://en.wikipedia.org/wiki/Cross-site_request_forgery https://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Confluence Page Link : http://confluence.bmc.com:8080/display/Discovery/Building+a+Secure+Web+UI