Security Csrf Prevention
// Security - Cross Site Request Forgery - Prevention:
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.
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 more prone to exposure.
2. 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.
https://www.owasp.org/index.php/CSRFGuard
https://www.owasp.org/index.php/ESAPI
3. Requiring the user to reauthenticate, or prove they are a user (e.g., via a
CAPTCHA) can also protect against CSRF.
The CSRF token is probably stored inside the server-side session, and is only
sent to the browser as a hidden form field, the attacker does not have this
token so he cannot put it into the script.
// CSRF Prevention:
1. State changing web operations should be accompanied by a secret that isn’t
sent automatically like Cookies. These secrets are called CSRF tokens.
2. CSRF tokens are typically included in the DOM.
3. The tokens should be unique per user per session.
4. The server should validate the token upon each state changing request
5. This would prevent malicious websites from performing state changing
operations on benign domains.
6. Custom headers with secrets are also an effective way to prevent CSRF
because they are not automatically sent by your browser.
Sometimes, it is possible to store the CSRF attack on the vulnerable site
itself. Such vulnerabilities are called Stored CSRF flaws. This can be
accomplished by simply storing an IMG or IFRAME tag in a field that accepts
HTML, or by a more complex cross-site scripting attack. If the attack can store
a CSRF attack in the site, the severity of the attack is amplified. In
particular, the likelihood is increased because the victim is more likely to
view the page containing the attack than some random page on the Internet. The
likelihood is also increased because the victim is sure to be authenticated to
the site already.
CSRF attacks are also known by a number of other names, including XSRF,
"Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking.
Microsoft refers to this type of attack as a One-Click attack in their threat
modeling process and many places in their online documentation.
Cross-Site Scripting is not necessary for CSRF to work. However, any cross-site
scripting vulnerability can be used to defeat token, Double-Submit cookie,
referer and origin based CSRF defenses. This is because an XSS payload can
simply read any page on the site using a XMLHttpRequest and obtain the generated
token from the response, and include that token with a forged request. This
technique is exactly how the MySpace (Samy) worm defeated MySpace's anti CSRF
defenses in 2005, which enabled the worm to propagate. XSS cannot defeat
challenge-response defenses such as Captcha, re-authentication or one-time
passwords. It is imperative that no XSS vulnerabilities are present to ensure
that CSRF defenses can't be circumvented.
Approaches to prevent CSRF:
1. Embed a CSRF Token as a hidden form field. The CSRF token should be unique
per session. It should be included as a hidden field in a POST request.
Avoid including the CSRF token as part of a GET request because it is leaked
through the referrer header, in the server log, and browser history.
2. Viewstate (ASP.NET): ASP.NET has an option to maintain your ViewState. The
ViewState indicates the status of a page when submitted to the server. The
status is defined through a hidden field placed on each page with a
<form runat="server"> control. Viewstate can be used as a CSRF defense, as
it is difficult for an attacker to forge a valid Viewstate. It is not
impossible to forge a valid Viewstate since it is feasible that parameter
values could be obtained or guessed by the attacker. However, if the current
session ID is added to the ViewState, it then makes each Viewstate unique,
and thus immune to CSRF. http://sforce.co/2hraiYr
3. Double Submit Cookies: Double submitting cookies is defined as sending a
random value in both a cookie and as a request parameter, with the server
verifying if the cookie value and request value are equal. When a user
authenticates to a site, the site should generate a (cryptographically
strong) pseudorandom value and set it as a cookie on the user's machine
separate from the session id. The site does not have to save this value in
any way. The site should then require every sensitive submission to include
this random value as a hidden form value (or other request parameter) and
also as a cookie value. An attacker cannot read any data sent from the server
or modify cookie values, per the same-origin policy. This means that while
an attacker can send any value he wants with a malicious CSRF request, the
attacker will be unable to modify or read the value stored in the cookie.
Since the cookie value and the request parameter or form value must be the
same, the attacker will be unable to successfully submit a form unless he is
able to guess the random CSRF value. Direct Web Remoting (DWR) Java library
version 2.0 has CSRF protection built in as it implements the double cookie
submission transparently. I think that this depends on us using the
HttpOnly flag.
4. Encrypted Token Pattern: The Encrypted Token Pattern leverages an encryption,
rather than comparison, method of Token-validation. After successful
authentication, the server generates a unique Token comprised of the user's
ID, a timestamp value and a nonce, using a unique key available only on the
server. This Token is returned to the client and embedded in a hidden field.
Subsequent AJAX requests include this Token in the request-header, in a
similar manner to the Double-Submit pattern. Non-AJAX form-based requests
will implicitly persist the Token in its hidden field, although I recommend
persisting this data in a custom HTTP header in such cases. On receipt of
this request, the server reads and decrypts the Token value with the same
key used to create the Token.
On successful Token-decryption, the server has access to parsed values,
ideally in the form of claims. These claims are processed by comparing the
UserId claim to any potentially stored UserId (in a Cookie or Session
variable, if the site already contains a means of authentication). The
Timestamp is validated against the current time, preventing replay attacks.
Alternatively, in the case of a CSRF attack, the server will be unable to
decrypt the poisoned Token, and can block and log the attack.
This pattern exists primarily to allow developers and architects protect
against CSRF without session-dependency. It also addresses some of the
shortfalls in other stateless approaches, such as the need to store data in
a Cookie, circumnavigating the Cookie-subdomain and HTTPONLY issues.
CSRF can be prevented in a number of ways. Using a Synchronizer Token is one
way that an application can rely upon the Same-Origin Policy to prevent CSRF by
maintaining a secret token to authenticate requests. This section details other
ways that an application can prevent CSRF by relying upon similar rules that
CSRF exploits can never break.
1. Checking The Referer Header
2. Checking The Origin Header: The Origin HTTP Header standard was introduced
as a method of defending against CSRF and other Cross-Domain attacks. Unlike
the referer, the origin will be present in HTTP request that originates from
an HTTPS url. If the origin header is present, then it should be checked for
consistency.
3. Challenge-Response: Challenge-Response is another defense option for CSRF.
The following are some examples of challenge-response options:
a. CAPTCHA
b. Re-Authentication (password)
c. One-time Token
While challenge-response is a very strong defense to CSRF (assuming proper
implementation), it does impact user experience. For applications in need of
high security, tokens (transparent) and challenge-response should be used on
high risk functions.
All requests that create, update or delete data or have side-effects require
protection against CSRF. The most reliable method is to include an anti-CSRF
token as a hidden input with every application action. This token should be
included in all forms built by the genuine application and validated to be
present and correct before form data is accepted and acted upon. Use the POST
method for requests requiring protection to avoid disclosing the token value in
Referer headers.
The OWASP CSRFGuard Project also provides an anti-CSRF token mechanism
implemented as a filter and set of JSP tags applicable to a wide range of J2EE
applications. Download it at:
http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
http://shiflett.org/articles/cross-site-request-forgeries
The “csrf-magic” library can provide anti-CSRF tokens for many PHP applications.
Download it at:
http://csrf.htmlpurifier.org/
page revision: 1, last edited: 01 Jan 2017 22:08