Hi Christopher - Vipin's response was absolutely correct. And you're correct in your assessment regarding the idempotent aspect of those methods make it unnecessary to add such protection.
CSRF attacks target behavior rather than getting to returned responses. Moreover, the attacker can't even access the response to such a call. The difference between this implementation and what is typically described by OWASP and the like is that this is for REST APIs not for webapps. Therefore, this protection is really for browser based calls to REST APIs from javascript. Javascript/ajax programming model has a pretty robust set of protections already built into it for such protections. In fact, you have to explicitly enabled CORS support for making ajax calls across origin. This is why we don't have to check the source and target origins for REST API protection. You can see my write up on this for the Hadoop protection here: https://issues.apache.org/jira/secure/attachment/12781473/CSRFProtectionforRESTAPIs.pdf Hope that is helpful. thanks, --larry On Fri, Oct 7, 2016 at 4:44 PM, Christopher Jackson < [email protected]> wrote: > 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]> > Reply-To: "[email protected]" <[email protected]> > Date: Saturday, October 8, 2016 at 1:19 AM > To: "[email protected]" <[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-password > https://localhost:8443/gateway/default/webhdfs/v1/tmp\?op\=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 > > >
