The csrfpId above is faked, but this is the javascript that is injected into my pages when the module is enabled. From my understanding of what the module is supposed to do, I believe that this is the expected behavior.
The problem is that my page uses Jquery to make a post request to a php script in order to retrieve JSON. When the module is disabled, the JSON is returned from the php script as expected. An example looks like this:
Above is just one example, but this seem to be happening on all Jquery Post requests to a PHP script that returns JSON.
Initially when I enabled the module ,I received errors because I did not set and options for the module. I later added the following module options:
CSRF_Enable on
CSRF_ScriptPath /csrf.js
When I first set these options, it failed becasue I didn't have the csrf.js file in the correct location. This could be see because of a 404 error. I corrected this and the 404 went away. However, regardless of the options being set or not, the JSON problem still exists.
Any ideas?
Last edit: luskbo 2016-08-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for sharing your findings.
mod_csrf should "process" HTML responses only, but not JSON. I wonder why the parser gets triggered (obviously it does, because the missing characters are exactly as long as the parsers window). You haven't captured the full HTTP response (incl. header), have you? I believe the application responses with a content-type header indicating that this is text/html (and not application/json or similar).
If it does so, we either have to change the application sending a proper header or to enhance mod_csrf trying to verifying that the body is HTML indeed (mime type guessing).
Regards, Pascal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've uploaded version 0.9 of mod_csrf which includes a fix to flush the remaining buffer in the case the module is unable to find the necessary HTML nodes when parsing the response body.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using the Apache module called mod_csrf for preventing cross site request forgery.
When I enable the module, it seems to work at first glance. My pages are being injected with the data:
The csrfpId above is faked, but this is the javascript that is injected into my pages when the module is enabled. From my understanding of what the module is supposed to do, I believe that this is the expected behavior.
The problem is that my page uses Jquery to make a post request to a php script in order to retrieve JSON. When the module is disabled, the JSON is returned from the php script as expected. An example looks like this:
[{"name":"itema","count":6},{"name":"itemb","count":11},{"name":"itemc","count":4}]
However, when I enable the csrf module, the JSON returned is broken. An example of the broken JSON looks like this:
[{"name":"imtea","count":6},{"name":"itemb","count":11},{"name":"itemc","count
Above is just one example, but this seem to be happening on all Jquery Post requests to a PHP script that returns JSON.
Initially when I enabled the module ,I received errors because I did not set and options for the module. I later added the following module options:
CSRF_Enable on
CSRF_ScriptPath /csrf.js
When I first set these options, it failed becasue I didn't have the csrf.js file in the correct location. This could be see because of a 404 error. I corrected this and the 404 went away. However, regardless of the options being set or not, the JSON problem still exists.
Any ideas?
Last edit: luskbo 2016-08-28
Thank you for sharing your findings.
mod_csrf should "process" HTML responses only, but not JSON. I wonder why the parser gets triggered (obviously it does, because the missing characters are exactly as long as the parsers window). You haven't captured the full HTTP response (incl. header), have you? I believe the application responses with a content-type header indicating that this is text/html (and not application/json or similar).
If it does so, we either have to change the application sending a proper header or to enhance mod_csrf trying to verifying that the body is HTML indeed (mime type guessing).
Regards, Pascal
I've uploaded version 0.9 of mod_csrf which includes a fix to flush the remaining buffer in the case the module is unable to find the necessary HTML nodes when parsing the response body.