Re: "Exploit"...
Reply #2 –
Elk may probably be affected, yes.. But the Language-Editor is protected via validateToken().. I reckon a stolen admin cookie wouldn't help, the token validation would fail and you'd have to re-enter the password to get a properly initialized admin session.
Re: "Exploit"...
Reply #3 –
Oh yes, there's the token system, I'd forgotten about that.
Re: "Exploit"...
Reply #4 –
It would be a bit more complex, but if you have an admin session you can just load the page (with the token) and POST the page...no?
Re: "Exploit"...
Reply #6 –
See, that to me seems to undermine the token system's effectiveness. You're proving that the person who hit the button to start the page is the same person who is hitting the button the second time, but if the session's already compromised, the hijacker only needs to have the session in order to be able to do their own thing anyway :/
Re: "Exploit"...
Reply #7 –
I'd say that the token system ensures that the person POSTing something is the same (of course with all due limitations of an insecure http communication) that hit the "save" button.
The token can be summarized on:
a random (unique) string is created
the string is placed in an input type=hidden
the <form> is POSTed
the string is checked
The tokens were able to avoid the 2.0.3 bug (i.e. POSTing to an admin form from an "anonymous" page), though if the session is compromised the tokens are of no use.
I don't think the tokens were meant to be more than that.