Modified: knox/site/project-info.html URL: http://svn.apache.org/viewvc/knox/site/project-info.html?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/site/project-info.html (original) +++ knox/site/project-info.html Fri Mar 13 15:01:22 2020 @@ -1,13 +1,13 @@ <!DOCTYPE html> <!-- - | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-site-plugin:3.7.1:CategorySummaryDocumentRenderer at 2020-03-12 + | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-site-plugin:3.7.1:CategorySummaryDocumentRenderer at 2020-03-13 | Rendered using Apache Maven Fluido Skin 1.7 --> <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> - <meta name="Date-Revision-yyyymmdd" content="20200312" /> + <meta name="Date-Revision-yyyymmdd" content="20200313" /> <meta http-equiv="Content-Language" content="en" /> <title>Knox Gateway – Project Information</title> <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" /> @@ -40,7 +40,7 @@ <div id="breadcrumbs"> <ul class="breadcrumb"> - <li id="publishDate">Last Published: 2020-03-12</li> + <li id="publishDate">Last Published: 2020-03-13</li> </ul> </div> <div class="row-fluid">
Modified: knox/site/team.html URL: http://svn.apache.org/viewvc/knox/site/team.html?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/site/team.html (original) +++ knox/site/team.html Fri Mar 13 15:01:22 2020 @@ -1,13 +1,13 @@ <!DOCTYPE html> <!-- - | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:team at 2020-03-12 + | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:team at 2020-03-13 | Rendered using Apache Maven Fluido Skin 1.7 --> <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> - <meta name="Date-Revision-yyyymmdd" content="20200312" /> + <meta name="Date-Revision-yyyymmdd" content="20200313" /> <meta http-equiv="Content-Language" content="en" /> <title>Knox Gateway – Project Team</title> <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" /> @@ -40,7 +40,7 @@ <div id="breadcrumbs"> <ul class="breadcrumb"> - <li id="publishDate">Last Published: 2020-03-12</li> + <li id="publishDate">Last Published: 2020-03-13</li> </ul> </div> <div class="row-fluid"> Modified: knox/trunk/books/0.10.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.10.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.10.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.10.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.10.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.10.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.10.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.10.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe.options.enabled</name><value>true</value></param> </provider> @@ -59,6 +40,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -78,11 +69,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.11.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.11.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.11.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.11.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.11.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.11.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.11.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.11.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe.options.enabled</name><value>true</value></param> </provider> @@ -59,6 +40,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -78,11 +69,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.12.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.12.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.12.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.12.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.12.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.12.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.12.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.12.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe.options.enabled</name><value>true</value></param> </provider> @@ -59,6 +40,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -78,11 +69,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.13.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.13.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.13.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.13.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.13.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.13.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.13.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.13.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe.options.enabled</name><value>true</value></param> </provider> @@ -59,6 +40,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -78,11 +69,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.14.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.14.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.14.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.14.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.14.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.14.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.14.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.14.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,28 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are three aspects of web application security that are handled now: Cross Site Request Forgery (CSRF), Cross Origin Resource Sharing and HTTP Strict-Transport-Security. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - -#### HTTP Strict-Tranport-Security - HSTS -HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections and never via the insecure HTTP protocol. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF, CORS and HTTP STS but others will follow and you may be interested in creating your own. @@ -53,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe-options.enabled</name><value>true</value></param> <param><name>strict.transport.enabled</name><value>true</value></param> </provider> @@ -63,6 +41,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -82,11 +70,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false @@ -110,7 +102,7 @@ xframe-options.value | T ##### HTTP Strict Transport Security -Web applications can be protected by protocol downgrade attacks and cookie hijacking by adding HTTP Strict Transport Security response header. +HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections and never via the insecure HTTP protocol. ###### Config Modified: knox/trunk/books/0.7.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.7.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.7.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.7.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> </provider> #### Descriptions #### @@ -58,6 +39,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -77,11 +68,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.8.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.8.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.8.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.8.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.8.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.8.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.8.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.8.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> </provider> #### Descriptions #### @@ -58,6 +39,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -77,11 +68,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.9.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.9.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.9.0/config_pac4j_provider.md (original) +++ knox/trunk/books/0.9.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.9.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.9.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.9.0/config_webappsec_provider.md (original) +++ knox/trunk/books/0.9.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe.options.enabled</name><value>true</value></param> </provider> @@ -59,6 +40,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -78,11 +69,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/0.9.1/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.9.1/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.9.1/config_pac4j_provider.md (original) +++ knox/trunk/books/0.9.1/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/0.9.1/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/0.9.1/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/0.9.1/config_webappsec_provider.md (original) +++ knox/trunk/books/0.9.1/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,25 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are two aspects of web application security that are handled now: Cross Site Request Forgery (CSRF) and Cross Origin Resource Sharing. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF and CORS but others will follow and you may be interested in creating your own. @@ -50,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe.options.enabled</name><value>true</value></param> </provider> @@ -59,6 +40,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -78,11 +69,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false Modified: knox/trunk/books/1.0.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/1.0.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/1.0.0/config_pac4j_provider.md (original) +++ knox/trunk/books/1.0.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled> Modified: knox/trunk/books/1.0.0/config_webappsec_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/1.0.0/config_webappsec_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/1.0.0/config_webappsec_provider.md (original) +++ knox/trunk/books/1.0.0/config_webappsec_provider.md Fri Mar 13 15:01:22 2020 @@ -18,28 +18,6 @@ ### Web App Security Provider ### Knox is a Web API (REST) Gateway for Hadoop. The fact that REST interactions are HTTP based means that they are vulnerable to a number of web application security vulnerabilities. This project introduces a web application security provider for plugging in various protection filters. -There are three aspects of web application security that are handled now: Cross Site Request Forgery (CSRF), Cross Origin Resource Sharing and HTTP Strict-Transport-Security. Others will be added in future releases. - -#### CSRF -Cross site request forgery (CSRF) attacks attempt to force an authenticated user to -execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. - -CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. - -#### CORS -For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. - -Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. - -#### HTTP Strict-Tranport-Security - HSTS -HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections and never via the insecure HTTP protocol. - - #### Configuration #### ##### Overview ##### As with all providers in the Knox gateway, the web app security provider is configured through provider params. Unlike many other providers, the web app security provider may actually host multiple vulnerability/security filters. Currently, we only have implementations for CSRF, CORS and HTTP STS but others will follow and you may be interested in creating your own. @@ -53,7 +31,7 @@ Because of this one-to-many provider/fil <param><name>csrf.enabled</name><value>true</value></param> <param><name>csrf.customHeader</name><value>X-XSRF-Header</value></param> <param><name>csrf.methodsToIgnore</name><value>GET,OPTIONS,HEAD</value></param> - <param><name>cors.enabled</name><value>true</value></param> + <param><name>cors.enabled</name><value>false</value></param> <param><name>xframe-options.enabled</name><value>true</value></param> <param><name>strict.transport.enabled</name><value>true</value></param> </provider> @@ -63,6 +41,16 @@ The following tables describes the confi ##### CSRF +Cross site request forgery (CSRF) attacks attempt to force an authenticated user to +execute functionality without their knowledge. By presenting them with a link or image that when clicked invokes a request to another site with which the user may have already established an active session. + +CSRF is entirely a browser based attack. Some background knowledge of how browsers work enables us to provide a filter that will prevent CSRF attacks. HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to 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: by enabling this protection within the topology, this custom header will be required for *all* clients that interact with it - not just browsers. + ###### Config Name | Description | Default @@ -82,11 +70,15 @@ Disabling the provider will then allow a ##### CORS +For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests. + +Cross Origin Resource Sharing is a way to explicitly alter the same-origin policy for a given application or API. In order to allow for applications to make cross domain requests through Apache Knox, we need to configure the CORS filter of the WebAppSec provider. + ###### Config Name | Description | Default -----------------------------|-------------|--------- -cors.enabled | This param enables the CORS capabilities|false +cors.enabled | Setting this parameter to true allows cross origin requests. The default of false prevents cross origin requests.|false cors.allowGenericHttpRequests| {true\|false} defaults to true. If true generic HTTP requests will be allowed to pass through the filter, else only valid and accepted CORS requests will be allowed (strict CORS filtering).|true cors.allowOrigin | {"\*"\|origin-list} defaults to "\*". Whitespace-separated list of origins that the CORS filter must allow. Requests from origins not included here will be refused with an HTTP 403 "Forbidden" response. If set to \* (asterisk) any origin will be allowed.|"\*" cors.allowSubdomains | {true\|false} defaults to false. If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).|false @@ -110,7 +102,7 @@ xframe-options.value | T ##### HTTP Strict Transport Security -Web applications can be protected by protocol downgrade attacks and cookie hijacking by adding HTTP Strict Transport Security response header. +HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections and never via the insecure HTTP protocol. ###### Config Modified: knox/trunk/books/1.1.0/config_pac4j_provider.md URL: http://svn.apache.org/viewvc/knox/trunk/books/1.1.0/config_pac4j_provider.md?rev=1875157&r1=1875156&r2=1875157&view=diff ============================================================================== --- knox/trunk/books/1.1.0/config_pac4j_provider.md (original) +++ knox/trunk/books/1.1.0/config_pac4j_provider.md Fri Mar 13 15:01:22 2020 @@ -35,15 +35,6 @@ To enable SSO for REST API access throug <gateway> <provider> - <role>webappsec</role> - <name>WebAppSec</name> - <enabled>true</enabled> - <param> - <name>cors.enabled</name> - <value>true</value> - </param> - </provider> - <provider> <role>federation</role> <name>SSOCookieProvider</name> <enabled>true</enabled>
