Hi Vipin, That was very helpful as I overlooked the default value for that property. I have a few follow up questions:
Those three methods (options, get, head) are all idempotent (when following spec) so you ignore them because there is no real CSRF threat for idempotent methods. Is that correct? Why do the CSRF filters that are added as part of webappsec not check that the same origins (source, target) are used? This is a suggested action for defense by OWASP for CSRF attacks. Regards, Christopher Jackson > On Oct 7, 2016, at 4:02 PM, Vipin Rathor <[email protected]> wrote: > > Hi Christopher, > > By default the GET method is added as 'methods-to-ignore’ for CSRF header. > Please define this param in webappsec like below & restart Knox gateway > service. > > <param><name>csrf.methodsToIgnore</name><value>OPTIONS,HEAD</value></param> > > Hope this helps. > > Thanks, > VR > From: Christopher Jackson <[email protected] > <mailto:[email protected]>> > Reply-To: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Date: Saturday, October 8, 2016 at 1:19 AM > To: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Subject: webappsec not getting enabled > > I seem to be having trouble getting the webappsec provider in Knox 0.7.0 > enabled. Adding the following to the default topology nested in the gateway > element and restarting the Knox service didn’t seem to enable it: > > <provider> > <role>webappsec</role> > <name>WebAppSec</name> > <enabled>true</enabled> > <param><name>csrf.enabled</name><value>true</value></param> > <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> > <param><name>cors.enabled</name><value>true</value></param> > <param><name>xframe-options.enabled</name><value>true</value></param> > </provider> > > Just wondering if there is something additional that I need to do? I took a > look at the stack > /usr/iop/current/knox-server/data/deployments/default.war.157a089fbe0/WEB-INF/topology.xml > (default.war.157a089fbe0 is the most recent default folder) and I do see the > configuration I just added included. Additionally I see in the gateway.xml in > the same folder that the CSRF and CORS filters are enabled for the role I’m > trying to access. However I can still access the resource through the default > gateway without including the specified csrf.customHeader. > > For example, both the following requests succeed: > > curl -k -i -v -u guest:guest-password > https://localhost:8443/gateway/default/webhdfs/v1/tmp\?op\=LISTSTATUS > <https://iop42bm5.rtp.raleigh.ibm.com:8443/gateway/default/webhdfs/v1/tmp%5C?op%5C=LISTSTATUS> > curl -k -i --header "X-XSRF-Header: valid" -v -u > guest:guest-passwordhttps://localhost:8443/gateway/default/webhdfs/v1/tmp\?op\=LISTSTATUS > <https://localhost:8443/gateway/default/webhdfs/v1/tmp%5C?op%5C=LISTSTATUS> > > I didn’t see anything strange in the logs. Any suggestions on something I > missed or something else I should try to debug? > > Regards, > Christopher Jackson
