Presenter links protected against CSRF
- David Grudl
- Nette Core | 8117
Activation:
Protection will cover both actions, signals and components and will enabled by annotation for the appropriate method or for whole presenter. For individual components, it will be activated by annotations in similar way, how are defined persistent components now.
(Implementation should be general, so the same API can be used in future for authorization etc.)
The principle of protection:
Protected links will be rendered with HTML attribute
data-nette-secure and send like POST forms using JavaScript, but
with field __csrf in addition. The default implementation will not
use jQuery and will be compatible with IE8+.
Token will be checked in RequestFactory, as mentioned in this RFC.
Presenter will only check if HTTP method, for the protected links, is other than GET / HEAD. Otherwise will throw 403.
AJAX:
Protected links can be sent via AJAX usign methods POST/PUT/DELETE with token
in HTTP header X-CSRF-Token. This means that RequestFactory in
addition to POST field checking will check header X-CSRF-Token too
(if it matches token in cookie).
- David Grudl
- Nette Core | 8117
This solution is JS only. Good enough in 2014. Nobody knows how turn JavaScript off.
- Filip Procházka
- Moderator | 4668
Protected links are for actions that require loggedin user. If you wanna just read something the web will still works because you don't need javascript for that (GET http method). But for operations over some data (POST/PUT/DELETE http methods through AJAX) you would need javascripts.
Makes perfect sense to me.
- David Grudl
- Nette Core | 8117
My fault, I have split this RFC in two RFCs. So this is now only about protected presenters.
- JakubJarabica
- Gold Partner | 184
Not only middle click, but what about clicking on some link before document.ready has been triggered? Unfortunately there are still slow(EDGE/3G) connections that cause JS to run in terms of seconds.