mod_csrfprotector
mod_csrfprotector copied to clipboard
mebjas
Actions from input filter
To validate CSRF Token against token stored in database (for that session), the request body is read in input filter. Currently I'm able to read & retrieve csrf_token from the request body & validate it. however I'm unable to take further actions if validations fails:
this is the point where actions need to be taken
One idea is to leave all these complications in reading POST data, and switch csrf_token logic completely to urls. The idea is, even for POST requests the token is sent along with url as an argument. Is it insecure, we are using per request tokens?
What was the previous approach that let you stop the request but stopped feeding PHP?
it was to generate a key-value pair of whole POST body from request buffer. code is available at: http://cistoner.org/blog/minhaz/2014/06/17/parse-post-request-in-apache-2-2/
why dont you do this when you find an invalid token using the filter approach? On Jul 26, 2014, at 6:47 PM, minhaz [email protected] wrote:
it was to generate a key-value pair of whole POST body from request buffer. code is available at: http://cistoner.org/blog/minhaz/2014/06/17/parse-post-request-in-apache-2-2/
— Reply to this email directly or view it on GitHub.
I used this method from a general header parser hook, and its like further actions on that request is based on return value of the hook. So all I had to do, was to return HTTP_FORBIDDEN (or others) in case of failed validation.
However in case of input filter this approach didn't work.
If there could be some way I could call a similar hook from input filter or terminate the connection from input filter, things would get easier
input filter based approach to -> https://github.com/mebjas/mod_csrfprotector/tree/input-filter-based branch
csrf token as GET token approach -> master