Em 21-07-2016 13:54, a...@pepo.com escreveu:
Hi Rodrigo,
CSRF tokens would prevent any malicious POST or PUT requests which are
not made by the user knowingly.CSRF doesnot work for get requests at
all.You can turn off CSRF if there aren't any POST request or those
request wont do any damage to your application or database.
Yes, I understand, but that doesn't answer my 2 questions. To make it
short, given the scenario I described, I'd like to know:
1 - Why wouldn't checking Origin and Referer headers be enough to
prevent CSRF?
2 - If the page containing the CSRF token does not reflect user input,
would sending the CSRF token unmodified from the session be enough
protection?
Thanks,
Rodrigo.
P.S.: Rails doesn't protect GET requests because such requests shouldn't
perform any state change in the server side, not because they are not
vulnerable to CSRF. But if for some reason someone decides to take such
actions on GET requests, there's nothing preventing them to use CSRF
tokens on such requests as well. But for some GET request at least CSRF
must be disabled so that one would be able to get the token before
issues the next requests... Also, even if Rails would check for CSRF in
GET requests it wouldn't be able to know which ones should be protected
automatically...
On Thursday, July 21, 2016 at 9:22:06 PM UTC+5:30, Rodrigo Rosenfeld
Rosas wrote:
A few extra comments to better explain it.
Em 21-07-2016 11:54, Rodrigo Rosenfeld Rosas escreveu:
> Hi, hope to find someone here with a good understanding of CSRF
> handling in Rails and willing to answer my questions :)
>
> I've read the security guide and couldn't find this kind of
> information so maybe this is something we could improve in the
guides
> and I could send a PR once I confirm I understood the reasoning
behind
> each implementation details.
>
> So, what are my problems with CSRF tokens? They add complexity,
> prevent caching and seem unnecessary for my application. I know
Rails
> is not designed for serving only my application but if we could
> improve the security guides I would be able to opt out from
having a
> token if I could be sure my application would remain safe. Or, if I
> should keep using CSRF to be safe, then it would help if Rails
> wouldn't mask the token generating a new one on each request
because
> that would allow the application to provide better caching.
>
> So, while researching about CSRF it seems like enough protection to
> simply verify the ORIGIN or REFERER headers unless there's a
security
> breach in the browser itself or in some browser plugin, like
Flash or
> Java. Sometimes those headers may not be present for legit
requests,
> but this does not seem to be the case with the main browsers if
your
> application runs over HTTPS in a single domain. I mean, Rails won't
> try to protect against GET requests to HTML pages as it doesn't
make
> sense anyway, so in that case it would be fine if those headers
would
> be missing or coming from a separate domain.
>
> So, as far as I can tell, checking the headers would be enough
if the
> following conditions can be met:
>
> - the application doesn't change any data on GET requests,
following
> the web semantics;
>
> - it's served over HTTPS for all requests (so that a request
wouldn't
> be made to HTTP in the same domain which could hide the referer in
> some browser implementations);
Using HTTPS also means it wouldn't be possible for a proxy server to
change such headers.
>
> - it forbids non GET requests where those headers are both
missing or
> when they don't match a whitelist;
>
> - the application restricts access to supported browsers;
>
> - the supported browsers and their plugins do not allow changing
those
> headers for cross-domain requests;
>
>
> I understand the last two conditions are out of our control but the
> company would be able to decide whether or not they are responsible
> for buggy browsers or plugins. For example, if such an exploit is
> possible, then maybe it would also be possible that it could be
used
> to issue a regular GET request from the other domain and extract
the
> token from it anyway, right?
>
> Now, even if the company decides that they want to add extra
> protection anyway to make it harder for such bugged
browsers/plugins
> exploits to be successfully used, maybe it would be enough to
provide
> the unmasked CSRF token in the original GET request. It used to
be the
> case in Rails but it was changed to mitigate BREACH attacks.
> Accordingly to http://breachattack.com/ the following conditions
must
> be met for the application to be vulnerable:
>
> "If you have an HTTP response body that meets all the following
> conditions, you might be vulnerable:
>
> 1 - Your page is served with HTTP compression enabled (GZIP /
DEFLATE)
>
> 2 - Your page reflects user data via query string parameters,
POST...
>
> 3 - Your application page serves PII, a CSRF token, sensitive
data..."
>
> While 1 and 3 would hold true for our SPA, we serve a single page
> which I'd want to be cacheable with ETag. We don't reflect query
> string parameters in that page, so I guess we would be safe from
the
> BREACH attack. In that case we would be able to use the unmasked
CSRF
> token stored in session, while remaining safe, right?
>
> I know Rails will try to add default protection that is suited
to most
> applications but it would be helpful if it could explain better the
> measures it takes against the attacks in the security guide as
well as
> explaining how to allow safe caching by telling in which conditions
> the CSRF token wouldn't have to be masked. I wouldn't be
bothering you
> if the token masking didn't come with some caveat, but we actually
> have a trade-off here, as masking the token could affect the
> client-side performance by preventing proper caching (or by forcing
> the client to perform another XHR request to get the masked token).
Actually it would be possible to cache using other techniques like
if-modified-since, getting a hash of the content with the token
extracted and so on, but I'd prefer to keep it simple and just use
the
regular ETag middleware.
> I'd love to understand if there are any other reasons why the CSRF
> token is being masked as well as confirming it would be okay to not
> mask it provided the page doesn't reflect any user input. If you
know
> those answers I'll be pretty thankful for your feedback.
>
>
> Thanks,
>
> Rodrigo.
>
--
You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to rubyonrails-core+unsubscr...@googlegroups.com
<mailto:rubyonrails-core+unsubscr...@googlegroups.com>.
To post to this group, send email to rubyonrails-core@googlegroups.com
<mailto:rubyonrails-core@googlegroups.com>.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
