PEAK XOOPS - under the topic of against CSRF ... (2) 
XOOPS
XOOPS : under the topic of against CSRF ... (2)
XOOPS has a simple system preventing from CSRF in DB layer.
POST && Good Referer --> allow all SQL
!POST || Bad Referer --> allow only SQL starting with "SELECT"
This is troublesome.
If someone post a news with referer off, he will get message "Your post has been received, successfully" but there is no such a post in fact.
It's both obscure and insecure.
I insist such protection in DB layer should be removed, and each controller has been implemented with token(ticket).
Comments list
GIJOE
Posted on 2006/6/2 6:48 | Last modified
hi Skalpa.
Quote:It's quite natural.
XSS + CSRF combination attack is the most powerful one.
If the form has XSS, neither referer check nor ticket make any sense.
But there are many users "referer off" in the world.
Thus, I insist
- referer check off
- ticket check (with feature of repost) on
Of course, XSS/ScriptInsertion can't be allowed.
Anyway, this english topic is much shorter than my original topic in Japanese.
Though I know I have to translate whole of my opinion into English...
Quote:
don't forget CSRF starts with the assumption that Javascript code can be inserted
XSS + CSRF combination attack is the most powerful one.
If the form has XSS, neither referer check nor ticket make any sense.
But there are many users "referer off" in the world.
Thus, I insist
- referer check off
- ticket check (with feature of repost) on
Of course, XSS/ScriptInsertion can't be allowed.
Anyway, this english topic is much shorter than my original topic in Japanese.
Though I know I have to translate whole of my opinion into English...
skalpa
Posted on 2006/6/1 8:38
The fact operations that modify the state of the Web should only be allowed during a POST request is part of the Web axioms, as describe in Tim Berners-Lee's notes.
So, although I'm almost sure this has not been implemented for this reason on purpose, it forces non-knowledged developers to respect this rule, and I think it is positive in fact.
Also, on a sidenote: I think something additional has to be found... Tokens are not more secure and can be tricked and bypassed (don't forget CSRF starts with the assumption that Javascript code can be inserted
).
So, although I'm almost sure this has not been implemented for this reason on purpose, it forces non-knowledged developers to respect this rule, and I think it is positive in fact.
Also, on a sidenote: I think something additional has to be found... Tokens are not more secure and can be tricked and bypassed (don't forget CSRF starts with the assumption that Javascript code can be inserted
).
Login