The flag reload link needs a token, otherwise it is vulnerable to attacks.
For example, an attacker could craft a link to flag or unflag an entity, and use that URL as the SRC property for an image elsewhere on the web, or indeed in something such as an email. A user's browser would then attempt to load that image, and in doing so, cause a flagging action on the site on behalf of the unsuspecting user.
Comment | File | Size | Author |
---|---|---|---|
#29 | 2466703-29.flag_.reload-link-token.patch | 6.1 KB | tduong |
| |||
#23 | interdiff-2466703-18-23.txt | 937 bytes | tduong |
#23 | 2466703-23.flag_.reload-link-token.patch | 6.1 KB | tduong |
| |||
#18 | interdiff-2466703-15-18.txt | 2.98 KB | tduong |
#18 | 2466703-18.flag_.reload-link-token.patch | 7.17 KB | tduong |
|
Comments
Comment #1
joachim CreditAttribution: joachim commented1-line fix to add tokens to a link! Nice!
We need tests for this, and as it turns out the reload link type has no coverage, here's a whole new test class.
In addition to checking the lifecycle of the flagging, we try to load the reload link without the token and check we get access denied.
Comment #4
BerdirHm. This is going to be a problem with caching. The node is going to be cached including the csrf_token.
Try to test this with two different users, access it with the first user, then the second, the link won't work for that one. Maybe we already have some tests that proof this?
Fixing this is tricky, maybe post_render_cache? See #2467425: As a temporary measure until we have cacheable CSRF: let all forms add a csrf_token cache context?, but if we vary the cache for the flag/node for every user, then we're pretty much killing the node render cache. That's not cool.
Comment #5
BerdirGood, we do have tests for exactly that :) Might be easier to just add some additional asserts there for this?
Comment #6
Berdirwrong issue.
Comment #7
joachim CreditAttribution: joachim commentedAw that's a pain :(
But then this is a problem in Flag with the reload link in 7x-3x, and indeed ever since it was introduced (or as long as Drupal core has had a page cache).
So we could legitimately fix the security regression, then slap on a warning on the UI description of the link to say don't use it with caching, and then think about how to fix the caching. Another possibility is offering an option to disable the token -- we've had several requests over the years to have this feature on 7x-3x.
Comment #8
BerdirWell, page cache is one thing, but D8 has a lot more caching, as you can see, it's failing for authenticated users. And you can't disable that. Or don't want to. Because without render cache, D8 would be *very* slow.
I'll ask WimLeers, maybe he has some ideas.
Comment #9
joachim CreditAttribution: joachim commentedAnother issue asking to have the token turned off in D7: #2470373: How to bypass or alter CSRF token for a certain flag...
Comment #10
joachim CreditAttribution: joachim commentedThis affects the AJAX links too; the same attack could be crafted with that link type too.
Is there any way to have placeholders in the cached rendered content, which are replaced on output?
Comment #11
BerdirYes, there's the render cache that we can use but that won't work for anonymous users. Not completely sure if the csrf token access check is intelligent enough to skip them. Based on a quick look, apparently not...
Comment #12
joachim CreditAttribution: joachim commentedOn earlier versions of Flag, anonymous users aren't allowed to access flag at all unless Session API module is present.
Comment #13
joachim CreditAttribution: joachim commentedSo now we've set a cache context with #2473921: FlagSimpleTest is failing due to render/page caching, can the need for a token be handled by changing the cache context to:
so the entity is cached per-user?
Though making the whole entity cached per-user is not brilliant for performance...
Comment #14
BerdirSee #2565501-3: Tests are not working because Dynamic page cache was committed in core.. No, the user cache context doesn't help since a user can flag or unflag a node and then it has to change. And as you said, it would be very bad for performance.
Comment #15
BerdirCore now builds those tokens by default in a post render cache. Which means that this might just work now. Lets try. Simple rebase, the tests might need some updates now.
Comment #17
BerdirFlagSimpleTest doesn't fail on this anymore, so that seems to actually work now. Didn't look into the new test fails.
Comment #18
tduong CreditAttribution: tduong at MD Systems GmbH commentedUploaded patch
Comment #19
joachim CreditAttribution: joachim commentedWell spotted!
However, this fix belongs in a new issue. And the whole of that stuff should be removed, as Views module is now in core, so you can't download it, and I don't think we need to tell people they can use Views to make lists.
BTW: we don't put comments code about the changes that have been made. Comments should be about the code now. For everything else, there's the git log and the issue queue.
Comment #20
BerdirI knew you'd say that :)
Agreed with removing that text, the only problem is that this test causes an error because of it, so if we make a separate issue for that, we have to postpone this (critical) issue on a normal bugfix. But yes, lets create a quick issue for removing that then.
Comment #21
joachim CreditAttribution: joachim commentedIt's a 5-minute fix -- I can take care of it after lunch today unless @tduong beats me to filing an issue and making a patch :)
Comment #22
joachim CreditAttribution: joachim commentedStep one: created issue: #2619848: remove UI text about downloading Views.
(I'm not slacking off work, my caches are taking ages to clear ;)
Comment #23
tduong CreditAttribution: tduong at MD Systems GmbH commentedStep two: patch uploaded for that issue :P
For this issue:
This test will have to be retested after that the other issue will be committed
Comment #25
BerdirGreen now :)
@joachim, You added the Needs Tests that and provided a patch with test in the same patch, I don't really understand why, isn't this enough test coverage?
Comment #28
joachim CreditAttribution: joachim commentedEh, that was back in April. I have no idea! I'd completely forgotten I wrote the tests too! :D
Though I see the test class needs a rename, as since I wrote that we've changed the link type tests to be called LinkTypeFOOTest. But given this is critical, that can be a follow-up.
Comment #29
tduong CreditAttribution: tduong at MD Systems GmbH commentedUploaded patch:
LinkTypeReloadTest
Comment #30
Berdir-1 critical? :)
Comment #34
joachim CreditAttribution: joachim commentedCommitted!
Thanks for that final reroll tduong :)