1. What is Cross Site Request Forgery Cross Site Request Forgery Vulnerability Which Websites are Vulnerable How the CSRF works Riding the Session Example Attack Scenario CSRF Mitigation Best Practices: For the End User For Applications Misconceptions about CSRF Defenses That Dont Work CSRF Myths and Reality How to Prevent CSRF

2. A Cross Site Request Forgery (CSRF) the sleeping giant, is anattack that forces a logged-on victims browser to send a forged HTTPrequest, including the victims session cookie and any otherautomatically included authentication information, to a vulnerableweb application. This allows the attacker to force the victims browserto generate requests the vulnerable application thinks are legitimaterequests from the victim. 3. Cross-site request forgery, is also known asa one-click attack or session riding andabbreviated as CSRF ("sea-surf") or XSRF, isa type of malicious exploit of a websitewhereby unauthorized commands aretransmitted from a user that the websitetrusts. ... 4. The seed for CSRF vulnerability goes back 25years agoto the birth of Internet and worldwide web.The Bad people have all the time in the world,and they need to be successful only once,but the enforcement teams have to besuccessful 100% of the time. 5. Cross-site request forgery vulnerabilities exploit the trust that aWeb Application has on the Client Browser: Exploits a users privileges and trust to a particular Website. Exploits the trust that applications have on authenticatedsessions. It is a Client Side(Browser) attack.Identifying the attacker is even more difficult as the attackoccurs in the context of the authenticated user! 6. The key characteristic of a CSRF vulnerability are that the applicationaccepts a request that makes something occur on the server and theattacker can determine all the parameters of that request for anotheruser. Not to be confused with Cross Site Scripting! In Cross Site Scripting (XSS),the attacker exploits the trust a user has for a website, with CSRF on theother hand, the attacker exploits the trust a website has against a usersbrowser. CSRF Involves two key components to be successful: A willing victim (this cannot be controlled) A vulnerable website (this can be controlled) 7. Checking whether an application is vulnerable is by seeing if any links andforms lack an unpredictable CSRF token. Without such a token, attackerscan forge malicious requests. An alternate defense is to require the user to prove they intended to submitthe request, either through re-authentication, or some other proof they are areal user (e.g., a CAPTCHA). Also, important is focusing on the links and forms that invoke state-changingfunctions, since those are the most important CSRF targets. The multistep transactions should be also checked, as they are not inherentlyimmune. Attackers can easily forge a series of requests by using multiple tagsor possibly JavaScript. Session cookies, source IP addresses, and other information automaticallysent by the browser dont provide any defense against CSRF since thisinformation is also included in forged requests. 8. Websites that has not taken specific steps to mitigate therisks of CSRF attacks are most like vulnerable. Every piece of sensitive website functionality is vulnerable According to Open Web Application Security Project(OWASP): Cross Site request forgery is not a new attack, butis simple and devastating.." This vulnerability is extremelywidespread.." " all web application frameworks arevulnerable to CSRF 9. HTTP is a Stateless Protocol, Web Applications maintains state throughSessionID (in Cookies or URL Parameters, Hidden variables) The Server Trusts the SessionID coming from the browser. For authenticated sessions , the browser does not resend a NEW SessionID tothe application as a proof that each HTTP request is authenticated This allow for riding the session with an interleaved malicious HTTP request. If an attacker phish a victim forcing him to select a web page (via web mailfor example) that has a malicious HTML tag such as iframe with anembedded GET request and if such request is issued (by the victim webpage selection) when an authenticated session with the same application isstill valid, then such malicious request will processed by the application. 10. The Web application (server) implicitly assumes that any request that comes inexpresses the will of the user, as it comes from the users browser. The Application does not take into account that the request may as well have beenfoisted on the user by a third party. Is this the web applications fault? ... Though most users have good intention theserver side application has the responsibility to check for the one in a million baduser/request The attacker abuses an existing session in the victims browser, he/she "rides" on it. This isknown as Session Riding .. a.k.a CSRF. 11. The application allows a user to submit a state changing request that does notinclude anything secret. For example:http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243So, the attacker constructs a request that will transfer money from the victimsaccount to the attackers account, and then embeds this attack in an imagerequest or iframe stored on various sites under the attackers control:If the victim visits any of the attackers sites while already authenticated toexample.com, these forged requests will automatically include the users sessioninfo, authorizing the attackers request. 12. Logoff immediately after using a critical web application Do not save username/passwords (browser capability), auto complete Dont Use remember me your login (uses persistent cookies) Do not use the same browser to access sensitive applications and to surffreely the Internet. However, if both things have to be done at the samemachine, do them with separate browsers (IE and FF, or IE and Chrome,or FF- Chrome). Using HTML enabled mail pose additional risks since simply viewing amail message might lead to the execution of an attack. Check computer for malwares frequently 13. Insert custom random tokens into every form and URL - (SynchronizerToken Design Pattern) Make sure there a no XSS/HTML Tag Injection, Link Injection, Phishingvulnerabilities in user application Re-authenticate when performing high risk transactions Do not use GET requests for sensitive data or to perform high risktransactions. Do not allow POST variables as GET when submitting forms When using Flash always have restricted crossdomain.xml file (on theserver) When redirecting out of domain requests implement a white listapproach. Disable all Unsafe HTTP methods (all except GET and POST) 14. Only accept POST Stops simple link-based attacks (IMG, frames, etc.) But hidden POST requests can be created withiframes, scripts, etc Referrer checking Some users prohibit referrers, so user cant just requirereferrer headers Techniques to selectively create HTTP request withoutreferrers exist Requiring multi-step transactions CSRF attack can perform each step in order URL Rewriting 15. CSRF is a special case of Cross SiteScripting (XSS) POSTs are not vulnerable to CSRF CSRF is low risk vulnerability Different vulnerability, root causes andcountermeasures. XSS can facilitate CSRF It is more difficult to exploit but they canlead to automatic submission Can perform any un-authorized businesstransaction such as change passwords,force logouts, transfer money, discloseinformation. 16. Preventing CSRF usually requires the inclusion of an unpredictable token ineach HTTP request. Such tokens should, at a minimum, be unique per usersession. The preferred option is to include the unique token in a hiddenfield. This causes the value to be sent in the body of the HTTP request,avoiding its inclusion in the URL, which is more prone to exposure. The unique token can also be included in the URL itself, or a URLparameter. However, such placement runs a greater risk that the URL willbe exposed to an attacker, thus compromising the secret token.OWASPs CSRF Guard can automatically include such tokens in Java EE,.NET, or PHP apps. OWASPs ESAPI includes methods developers can use toprevent CSRF vulnerabilities. Requiring the user to re-authenticate, or prove they are a user (e.g., via aCAPTCHA) can also protect against CSRF. 17. Auger, R. (2010). Cross Site Request Forgery. Retrieved on Oct. 14, 2014 fromhttp://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery Acunetix. CSRF Attacks What They Are and How to Defend Against Them. Retrieved on Oct.14, 2014 from http://www.acunetix.com/websitesecurity/csrf-attacks/ CWE-352. Cross-Site Request Forgery (CSRF). Retrieved on Sept. 14, 2014 fromhttp://cwe.mitre.org/data/definitions/352.html OWASP. Top 10 2013-A8-Cross-Site Request Forgery (CSRF). Retrieved on Sept. 12, 2014 fromhttps://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) Padinjaruveetil, G. Cross-Site Request Forgery Vulnerability. Retrieved on Oct. 21, 2014 fromhttp://www.slideshare.net/capgemini/crosssite-request-forgery-vulnerability-a-sleeping-giant?qid=c81be391-715a-4f23-beb6-673e5567e0b0&v=qf1&b=&from_search=1 18. CSRF Vulnerability: A 'Sleeping Giant - http://www.darkreading.com/risk/csrf-vulnerability-a-sleeping-giant/d/d-id/1128371 Cookies are bad for you: Improving web application security - http://sitr.us/2011/08/26/cookies-are-bad-for-you.html Interface HTTPUtilities - http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.html http://www.darkreading.com/default.asp Login Cross-Site Request Forgery (CSRF) - http://www.ethicalhack3r.co.uk/login-cross-site-request-forgery-csrf/ OWASP. Category: OWASP CSRF Guard Project - https://www.owasp.org/index.php/CSRFGuard OWASP. CSRF Guard 3 Token Injection https://www.owasp.org/index.php/CSRFGuard_3_Token_Injection OWASP. Category: OWASP CSRF Tester Project https://www.owasp.org/index.php/CSRFTester OWASP. Category: OWASP Enterprise Security API https://www.owasp.org/index.php/ESAPI Stack Overflow. CSRF (Cross-site request forgery) attack example and prevention in PHP Using CSRF Protection in the Login Form - http://symfony.com/doc/current/cookbook/security/csrf_in_login_form.html Veracode. Cross-Site Request Forgery Guide: Learn All About CSRF Attacks and CSRF Protectionhttp://www.veracode.com/security/csrf Wasson, M. (2012). Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET Web API http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks 19. According to Ray Kurzweil, by the year 2045, humanintelligence will enhance a billion-fold thanks to high-tech brainextensions. He refers to this phenomenon as the singularity, apoint at which humans and computers will merge. This sort ofone in two will create serious challenges for security and in theallocation of moral accountability between the two Singularity- http://www.youtube.com/watch?v=-wqaEsEApSE How does the Future look like.. -http://www.youtube.com/watch?v=H4axEZwLdno