1. Implement Web Application Security

The Knox Gateway is a Web API (REST) Gateway for Hadoop clusters. REST interactions are HTTP based, and therefore the interactions are vulnerable to a number of web application security vulnerabilities. The web application security provider allows you to configure protection filter plugins.

	Note
	The initial vulnerability protection filter is for Cross Site Request Forgery (CSRF). Others will be added in future releases.

1.1. Configure Protection Filter against Cross Site Request Forgery Attacks

A Cross Site Request Forgery (CSRF) attack attempts to force a user to execute functionality without their knowledge. Typically the attack is initiated by presenting the user with a link or image that when clicked invokes a request to another site with which the user already has an established an active session. CSRF is typically a browser based attack.

The only way to create a HTTP request from a browser is with a custom HTTP header is to use Javascript XMLHttpRequest or Flash, etc. Browsers have builtin security that prevent web sites from sending requests to each other unless specifically allowed by policy. This means that a website www.bad.com cannot send a request to http://bank.example.com with the custom header X-XSRF-Header unless they use a technology such as a XMLHttpRequest. That technology would prevent such a request from being made unless the bank.example.com domain specifically allowed it. This then results in a REST endpoint that can only be called via XMLHttpRequest (or similar technology).

	Note
	After enabling CSRF protection within the gateway, a custom header is required for all clients that interact with it, not just browsers.

To add CSRF protection filter:

Open the cluster topology descriptor file, $cluster-name.xml, in a text editor.
Add a WebAppSec webappsec provider to topology/gateway with a parameter for each service as follows:
```
<provider> 
  <role>webappsec</role> 
  <name>WebAppSec</name> 
  <enabled>true</enabled> 
  <param>
    <name>csrf.enabled</name>
    <value>$csrf_enabled</value>
  </param> 
  <param> 
    <name>csrf.customHeader</name>
    <value>$header_name</value>
  </param> 
  <param> 
    <name>csrf.methodsToIgnore</name>
    <value>$HTTP_methods</value>
  </param> 
</provider>
```
where:
$csrf_enabled is either true or false.
$header_name when the optional parameter csrf.customHeader is present the value contains the name of the header that determines if the request is from a trusted source. The default, X-XSRF-Header, is described by the NSA in its guidelines for dealing with CSRF in REST.
$HTTP_methods when the optional parameter csrf.methodsToIgnore is present the value enumerates the HTTP methods to allow without the custom HTTP header. The possible values are GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, or PATCH. For example, specifying GET allows GET requests from the address bar of a browser. Only specify methods that adhere to REST principals in terms of being idempotent.
Save the file.
The gateway creates a new WAR file with modified timestamp in /var/lib/knox/data/deployments .

1.2. Validate CSRF Filtering

The following curl command can be used to request a directory listing from HDFS while passing in the expected header X-XSRF-Header.

curl -k -i --header "X-XSRF-Header: valid" -v -u guest:guest-password https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS

Omitting the –header “X-XSRF-Header: valid” above results in an HTTP 400 bad_request. Disabling the provider, by setting csrf.enabled to false allows a request that is missing the header.

Legal notices