The document discusses Cross Site Request Forgery (CSRF) attacks. It defines CSRF as an attack where unauthorized commands are transmitted from a user that a website trusts. The attack forces a logged-in user's browser to send requests, including session cookies, to a vulnerable website. This allows the attacker to generate requests the site thinks are from the user. The document outlines how CSRF works, example attacks, defenses for users and applications, and myths about CSRF. It recommends using unpredictable CSRF tokens or re-authentication to prevent CSRF vulnerabilities.

2.  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 Don’t Work
 CSRF Myths and Reality
 How to Prevent CSRF

3. A Cross Site Request Forgery (CSRF) – the “sleeping giant”, is an
attack that 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.

4. Cross-site request forgery, is also known as
a one-click attack or session riding and
abbreviated as CSRF ("sea-surf") or XSRF, is
a type of malicious exploit of a website
whereby unauthorized commands are
transmitted from a user that the website
trusts. ...”

5. The seed for CSRF vulnerability goes back 25
years ago…to the birth of Internet and world
wide 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 be
successful 100% of the time.

6. Cross-site request forgery vulnerabilities exploit the trust that a
Web Application has on the Client Browser:
 Exploits a users privileges and trust to a particular Website.
 Exploits the trust that applications have on authenticated
sessions.
 It is a Client Side(Browser) attack.
Identifying the attacker is even more difficult as the attack
occurs in the context of the authenticated user!

7.  The key characteristic of a CSRF vulnerability are that the application
accepts a request that makes something occur on the server and the
attacker can determine all the parameters of that request for another
user.
 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 the
other hand, the attacker exploits the trust a website has against a user’s
browser.
 CSRF Involves two key components to be successful:
› A willing victim (this cannot be controlled)
› A vulnerable website (this can be controlled)

8.  Checking whether an application is vulnerable is by seeing if any links and
forms lack an unpredictable CSRF token. Without such a token, attackers
can forge malicious requests.
 An alternate defense is to require the user to prove they intended to submit
the request, either through re-authentication, or some other proof they are a
real user (e.g., a CAPTCHA).
 Also, important is focusing on the links and forms that invoke state-changing
functions, since those are the most important CSRF targets.
 The multistep transactions should be also checked, as they are not inherently
immune. Attackers can easily forge a series of requests by using multiple tags
or possibly JavaScript.
 Session cookies, source IP addresses, and other information automatically
sent by the browser don’t provide any defense against CSRF since this
information is also included in forged requests.

9.  Websites that has not taken specific steps to mitigate the
risks 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, but
is simple and devastating.." This vulnerability is extremely
widespread.." " all web application frameworks are
vulnerable to CSRF”

10.  HTTP is a Stateless Protocol, Web Applications maintains state through
SessionID (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 to
the 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 mail
for example) that has a malicious HTML tag such as iframe with an
embedded GET request and if such request is issued (by the victim web
page selection) when an authenticated session with the same application is
still valid, then such malicious request will processed by the application.

11.  The Web application (server) implicitly assumes that any request that comes in
expresses 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 been
foisted on the user by a third party.
 Is this the web application’s fault? ... Though most users have good intention – the
server side application has the responsibility to check for the one in a million bad
user/request
 The attacker abuses an existing session in the victims browser, he/she "rides" on it. This is
known as Session Riding .. a.k.a CSRF.

12. The application allows a user to submit a state changing request that does not
include anything secret. For example:
http://example.com/app/transferFunds?amount=1500&destinationAccount=4673
243243
So, the attacker constructs a request that will transfer money from the victim’s
account to the attacker’s account, and then embeds this attack in an image
request or iframe stored on various sites under the attacker’s control:
<img
src="http://example.com/app/transferFunds?amount=1500&destinationAccount=
attackersAcct#" width="0" height="0" />
If the victim visits any of the attacker’s sites while already authenticated to
example.com, these forged requests will automatically include the user’s session
info, authorizing the attacker’s request.

13.  Logoff immediately after using a critical web application
 Do not save username/passwords (browser capability), auto complete
 Don’t Use “remember me” your login (uses persistent cookies)
 Do not use the same browser to access sensitive applications and to surf
freely the Internet. However, if both things have to be done at the same
machine, 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 a
mail message might lead to the execution of an attack.
 Check computer for malwares frequently

14.  Insert custom random tokens into every form and URL - (Synchronizer
Token Design Pattern)
 Make sure there a no XSS/HTML Tag Injection, Link Injection, Phishing
vulnerabilities in user application
 Re-authenticate when performing high risk transactions
 Do not use GET requests for sensitive data or to perform high risk
transactions.
 Do not allow POST variables as GET when submitting forms
 When using Flash always have restricted crossdomain.xml file (on the
server)
 When redirecting out of domain requests– implement a white list
approach.
 Disable all Unsafe HTTP methods (all except GET and POST)

15.  Only accept POST
› Stops simple link-based attacks (IMG, frames, etc.)
› But hidden POST requests can be created with
iframes, scripts, etc…
 Referrer checking
› Some users prohibit referrers, so user can’t just require
referrer headers
› Techniques to selectively create HTTP request without
referrers exist
 Requiring multi-step transactions
› CSRF attack can perform each step in order
 URL Rewriting

16.  CSRF is a special case of Cross Site
Scripting (XSS)
 POSTs are not vulnerable to CSRF
 CSRF is low risk vulnerability
 Different vulnerability, root causes and
countermeasures. XSS can facilitate CSRF
 It is more difficult to exploit but they can
lead to automatic submission
 Can perform any un-authorized business
transaction such as change passwords,
force logouts, transfer money, disclose
information.

17.  Preventing CSRF usually requires the inclusion of an unpredictable token in
each HTTP request. Such tokens should, at a minimum, be unique per user
session. 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 more prone to exposure.
 The unique token can also be included in the URL itself, or a URL
parameter. However, such placement runs a greater risk that the URL will
be exposed to an attacker, thus compromising the secret token.
OWASP’s CSRF Guard can automatically include such tokens in Java EE,
.NET, or PHP apps. OWASP’s ESAPI includes methods developers can use to
prevent CSRF vulnerabilities.
 Requiring the user to re-authenticate, or prove they are a user (e.g., via a
CAPTCHA) can also protect against CSRF.

18. • Auger, R. (2010). Cross Site Request Forgery. Retrieved on Oct. 14, 2014 from
http://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 from
http://cwe.mitre.org/data/definitions/352.html
• OWASP. Top 10 2013-A8-Cross-Site Request Forgery (CSRF). Retrieved on Sept. 12, 2014 from
https://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 from
http://www.slideshare.net/capgemini/crosssite-request-forgery-vulnerability-a-sleeping-giant?
qid=c81be391-715a-4f23-beb6-673e5567e0b0&v=qf1&b=&from_search=1

19. • 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 Protection
http://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

20.  According to Ray Kurzweil, by the year 2045, “human
intelligence will enhance a billion-fold thanks to high-tech brain
extensions. He refers to this phenomenon as the “singularity,” a
point at which humans and computers will merge. This sort of
“one in two” will create serious challenges for security and in the
allocation 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