I need to add CSRF token (p_auth) to my Liferay (ver.6.1.1) portal project.
Liferay provides this ability out of the box with auth.token.check.enabled=true
But it does this only for requests marked with #ActionMapping annotation [source]. At that time, as I need CSRF protection for #ResourceMapping because I have a lot of ajax requests for form submitting.
Thank you for the advice.
You can find the way for implementation of protection in http://www.liferay.com/community/forums/-/message_boards/message/26782849
Related
All the examples of CSRF exploits tend to be against pages which process the incoming request.
If the page doesn't have a form processing aspect do I need to worry about CSRF ?
The situation I'm looking # :
the page in question contains sensitive data
as such users need to establish a session to view the page
... my understanding is that a malicious page will be able to redirect a client to this page by embedding a link to it, however since there's no action on the target to perform there's no harm that can result, right ?
There's no way for said malicious site can view the sensitive page, correct ?
Why I ask: I want the url to the page with sensitive data to have a 'simple' URL which allows people to email the link to other people (who will in turn need a session to view the page). The token-based solution I've seen for most CSRF solutions remove this possibility, and so I'd like to avoid them if possible.
There's no way for said malicious site can view the sensitive page, correct ?
Correct in terms of CSRF.
The blog you linked is talking about Cross-Origin Script Inclusion, which is a different animal. To be vulnerable to XOSI your sensitive page would have to be interpretable as JavaScript, and you'd have to be either serving it without a proper HTML MIME type, or the browser would have to be an old one that didn't enforce type checking on scripts.
You might also potentially worry about clickjacking, where another site includes yours in a frame and overlays misleading UI elements. There are some sneaky ways that has been used to extract sensitive data (see the next generation clickjacking paper and this amusing info leak in Firefox) so you may wish to disallow framing with the X-Frame-Options header.
Why I ask: I want the url to the page with sensitive data to have a 'simple' URL which allows people to email the link to other people (who will in turn need a session to view the page). The token-based solution I've seen for most CSRF solutions remove this possibility
You definitely shouldn't be putting a CSRF token in a GET URL. Apart from the ugliness, and breakage of navigation, URLs are easy to leak from the browser or other infrastructure, potentially compromising the confidentiality of the token.
Normal practice is not to put CSRF protection on side-effect-free actions.
In general, CSRF is independent from whether the request causes any side effects or not. The CWE describes CSRF (CWE-352) as follows:
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
So CSRF is a general request intention authenticity problem.
However, although CSRF is not really feasible without any effects other than data retrieval as the same-origin policy restricts the attacker from accessing the response, the attacker could exploit another vulnerability to profit from retrieval-only requests as well and gain access to sensitive data.
I've been trying to search for an alternative for browsers that have disabled cookies in their browser and forms that require the antiforgerytoken for validation. How should a case like this be handled?
Any suggestions or alternatives to preventing CSRF in ASP.Net MVC forms would be greatly appreciated.
Thanks you!
You can create your own CUSTOM ANTIFORGERYTOKEN FILTER for more details
check the links...
http://forums.asp.net/t/1938599.aspx
http://www.prideparrot.com/blog/archive/2012/7/securing_all_forms_using_antiforgerytoken
There are a number of alternatives to using AntiForgeryTokens stored in session as part of the Synchroniser Token Pattern. One method gaining traction is the Encrypted Token Pattern, implemented by a Framework called ARMOR. The premise here is that you need neither Session nor cookies in order to maintain CSRF protection in a stateless manner, which won't be interrupted by browser settings, particularly the disabling of cookies.
I want to use basic auth to authenticate users. The problem is when a user needs authentication, the browser loads an ugly form where the user should enter their credentials (such is the default on all browsers when they get a basic auth request).
I would like to know how I can bypass this ugly browser default form and instead serve an alternative good looking custom made form.
Thanks in advance
What you're seeing is the HTTP authentication page put out by your web server. Browsers just pass it as is, and it's not customizable. This is why no one really uses them for much other than locking a site down during development or hiding a particular part of a site.
If you want to do something that fits the look and feel of your site, you're going to need to design a page or include your login somewhere on your existing pages.
I asked this question about reasons to use Drupal 7's Forms API as opposed to just processing form submission requests myself and eventually calling a function like node_save() or comment_save(). while a variety of reasons were given for using the Forms API, only one possible security vulnerability was raised: by not using Drupal 7's Forms API, I'd be missing out on the CSRF prevention techniques it uses. From what I've read, this basically involves the use of a token for validating requests.
My question is twofold:
Is it possible to leverage Drupal's token method of CSRF prevention in the script I write to process the Ajax request, thereby entirely eliminating the added risk I'm assuming by not using the Forms API? If so, how?
Does the Forms API employ techniques beyond the use of tokens that I should also implement?
Please note that I do not want this question to become a discussion of whether I should use the Forms API or not.
The token is generated by drupal_get_token() and validated using drupal_valid_token().
I am researching stuff I hear regularly that when doing a webapp in JSF 2.0 you are already protected from crossite - scripting and - request forgery. The following excerpt from a SO post confirms this:
In JSF 2.0 this has been improved by using a long and strong autogenerated value instead of a rather predictable sequence value and thus making it a robust CSRF prevention.
Can someone provide some more detail on this? How does this autogenerated value prevent CSRF? Thanks!
How does this autogenerated value prevent CSRF ?
Because it cannot be guessed. So the attacker cannot hardcode it in a hidden field in a form of the attack website (unless the target site has a XSS hole and thus the value can simply be obtained directly by XSS means). If the value is not valid for JSF, then the form submit from the attack website will simply not be processed but instead generate a ViewExpiredException. Please note that the attacker would still need to get the session ID so that it can be passed back through jsessionid URL attribute, so the originally "weak" CSRF protection would still require some XSS hole to obtain the session ID.
After all, I have the impression that you do not understand at all what CSRF is; the answer is rather self-explaining if you understand what CSRF is. In that case, please check the following question: Am I under risk of CSRF attacks in a POST form that doesn't require the user to be logged in?
One thing to remember is that the CSRF-protection in JSF 2.0 is implicit and is only valid for POST requests.
In JSF 2.2 there will be more explicit support for this. I briefly explained this here: http://arjan-tijms.omnifaces.org/p/jsf-22.html