Author: krisden
Date: Fri Mar 13 15:01:22 2020
New Revision: 1875157
URL: http://svn.apache.org/viewvc?rev=1875157&view=rev
Log:
KNOX-2291 - Improve WebAppSec docs around cors.enabled
Modified:
knox/site/books/knox-0-12-0/user-guide.html
knox/site/books/knox-0-13-0/user-guide.html
knox/site/books/knox-0-14-0/user-guide.html
knox/site/books/knox-1-0-0/user-guide.html
knox/site/books/knox-1-1-0/user-guide.html
knox/site/books/knox-1-2-0/user-guide.html
knox/site/books/knox-1-3-0/user-guide.html
knox/site/books/knox-1-4-0/user-guide.html
knox/site/index.html
knox/site/issue-management.html
knox/site/licenses.html
knox/site/mailing-lists.html
knox/site/project-info.html
knox/site/team.html
knox/trunk/books/0.10.0/config_pac4j_provider.md
knox/trunk/books/0.10.0/config_webappsec_provider.md
knox/trunk/books/0.11.0/config_pac4j_provider.md
knox/trunk/books/0.11.0/config_webappsec_provider.md
knox/trunk/books/0.12.0/config_pac4j_provider.md
knox/trunk/books/0.12.0/config_webappsec_provider.md
knox/trunk/books/0.13.0/config_pac4j_provider.md
knox/trunk/books/0.13.0/config_webappsec_provider.md
knox/trunk/books/0.14.0/config_pac4j_provider.md
knox/trunk/books/0.14.0/config_webappsec_provider.md
knox/trunk/books/0.7.0/config_webappsec_provider.md
knox/trunk/books/0.8.0/config_pac4j_provider.md
knox/trunk/books/0.8.0/config_webappsec_provider.md
knox/trunk/books/0.9.0/config_pac4j_provider.md
knox/trunk/books/0.9.0/config_webappsec_provider.md
knox/trunk/books/0.9.1/config_pac4j_provider.md
knox/trunk/books/0.9.1/config_webappsec_provider.md
knox/trunk/books/1.0.0/config_pac4j_provider.md
knox/trunk/books/1.0.0/config_webappsec_provider.md
knox/trunk/books/1.1.0/config_pac4j_provider.md
knox/trunk/books/1.1.0/config_webappsec_provider.md
knox/trunk/books/1.2.0/config_pac4j_provider.md
knox/trunk/books/1.2.0/config_webappsec_provider.md
knox/trunk/books/1.3.0/config_pac4j_provider.md
knox/trunk/books/1.3.0/config_webappsec_provider.md
knox/trunk/books/1.4.0/config_pac4j_provider.md
knox/trunk/books/1.4.0/config_webappsec_provider.md
Modified: knox/site/books/knox-0-12-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-0-12-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-0-12-0/user-guide.html (original)
+++ knox/site/books/knox-0-12-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -2864,15 +2864,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>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.</p>
@@ -2884,13 +2875,17 @@ APACHE_HOME/bin/apachectl -k stop
<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>
</code></pre>
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -2925,6 +2920,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the –header “X-XSRF-Header: valid” above should
result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -2937,7 +2934,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This param enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -3320,15 +3317,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the the SSOCookieProvider configured to use
the KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-0-13-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-0-13-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-0-13-0/user-guide.html (original)
+++ knox/site/books/knox-0-13-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -2918,15 +2918,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>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.</p>
@@ -2938,13 +2929,17 @@ APACHE_HOME/bin/apachectl -k stop
<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>
</code></pre>
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -2979,6 +2974,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the –header “X-XSRF-Header: valid” above should
result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -2991,7 +2988,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This param enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -3374,15 +3371,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-0-14-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-0-14-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-0-14-0/user-guide.html (original)
+++ knox/site/books/knox-0-14-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -3919,17 +3919,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
-<h4><a id="HTTP+Strict-Tranport-Security+-+HSTS">HTTP Strict-Tranport-Security
- HSTS</a> <a href="#HTTP+Strict-Tranport-Security+-+HSTS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>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.</p>
@@ -3941,7 +3930,7 @@ APACHE_HOME/bin/apachectl -k stop
<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>
@@ -3949,6 +3938,10 @@ APACHE_HOME/bin/apachectl -k stop
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -3983,6 +3976,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the –header “X-XSRF-Header: valid” above should
result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -3995,7 +3990,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This param enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -4070,7 +4065,7 @@ APACHE_HOME/bin/apachectl -k stop
</tbody>
</table>
<h5><a id="HTTP+Strict+Transport+Security">HTTP Strict Transport Security</a>
<a href="#HTTP+Strict+Transport+Security"><img
src="markbook-section-link.png"/></a></h5>
-<p>Web applications can be protected by protocol downgrade attacks and cookie
hijacking by adding HTTP Strict Transport Security response header.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4402,15 +4397,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-1-0-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-1-0-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-1-0-0/user-guide.html (original)
+++ knox/site/books/knox-1-0-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -3927,17 +3927,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
-<h4><a id="HTTP+Strict-Tranport-Security+-+HSTS">HTTP Strict-Tranport-Security
- HSTS</a> <a href="#HTTP+Strict-Tranport-Security+-+HSTS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>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.</p>
@@ -3949,7 +3938,7 @@ APACHE_HOME/bin/apachectl -k stop
<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>
@@ -3957,6 +3946,10 @@ APACHE_HOME/bin/apachectl -k stop
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -3991,6 +3984,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the –header “X-XSRF-Header: valid” above should
result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4003,7 +3998,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This param enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -4078,7 +4073,7 @@ APACHE_HOME/bin/apachectl -k stop
</tbody>
</table>
<h5><a id="HTTP+Strict+Transport+Security">HTTP Strict Transport Security</a>
<a href="#HTTP+Strict+Transport+Security"><img
src="markbook-section-link.png"/></a></h5>
-<p>Web applications can be protected by protocol downgrade attacks and cookie
hijacking by adding HTTP Strict Transport Security response header.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4410,15 +4405,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-1-1-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-1-1-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-1-1-0/user-guide.html (original)
+++ knox/site/books/knox-1-1-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -4046,17 +4046,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
-<h4><a id="HTTP+Strict-Transport-Security+-+HSTS">HTTP
Strict-Transport-Security - HSTS</a> <a
href="#HTTP+Strict-Transport-Security+-+HSTS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>As with all providers in the Knox gateway, the web app security provider is
configured through provider parameters. 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 might follow, and you may be interested in creating your own.</p>
@@ -4068,7 +4057,7 @@ APACHE_HOME/bin/apachectl -k stop
<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>xss.protection.enabled</name><value>true</value></param>
<param><name>strict.transport.enabled</name><value>true</value></param>
@@ -4077,6 +4066,10 @@ APACHE_HOME/bin/apachectl -k stop
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4111,6 +4104,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the <code>--header "X-XSRF-Header: valid"</code> above
should result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4123,7 +4118,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This parameter enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -4241,7 +4236,7 @@ APACHE_HOME/bin/apachectl -k stop
</tbody>
</table>
<h5><a id="HTTP+Strict+Transport+Security">HTTP Strict Transport Security</a>
<a href="#HTTP+Strict+Transport+Security"><img
src="markbook-section-link.png"/></a></h5>
-<p>Web applications can be protected by protocol downgrade attacks and cookie
hijacking by adding HTTP Strict Transport Security response header.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4573,15 +4568,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-1-2-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-1-2-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-1-2-0/user-guide.html (original)
+++ knox/site/books/knox-1-2-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -4046,17 +4046,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
-<h4><a id="HTTP+Strict-Transport-Security+-+HSTS">HTTP
Strict-Transport-Security - HSTS</a> <a
href="#HTTP+Strict-Transport-Security+-+HSTS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>As with all providers in the Knox gateway, the web app security provider is
configured through provider parameters. 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 might follow, and you may be interested in creating your own.</p>
@@ -4068,7 +4057,7 @@ APACHE_HOME/bin/apachectl -k stop
<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>xss.protection.enabled</name><value>true</value></param>
<param><name>strict.transport.enabled</name><value>true</value></param>
@@ -4077,6 +4066,10 @@ APACHE_HOME/bin/apachectl -k stop
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4111,6 +4104,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the <code>--header "X-XSRF-Header: valid"</code> above
should result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4123,7 +4118,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This parameter enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -4241,7 +4236,7 @@ APACHE_HOME/bin/apachectl -k stop
</tbody>
</table>
<h5><a id="HTTP+Strict+Transport+Security">HTTP Strict Transport Security</a>
<a href="#HTTP+Strict+Transport+Security"><img
src="markbook-section-link.png"/></a></h5>
-<p>Web applications can be protected by protocol downgrade attacks and cookie
hijacking by adding HTTP Strict Transport Security response header.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4573,15 +4568,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-1-3-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-1-3-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-1-3-0/user-guide.html (original)
+++ knox/site/books/knox-1-3-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -4300,17 +4300,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
-<h4><a id="HTTP+Strict-Transport-Security+-+HSTS">HTTP
Strict-Transport-Security - HSTS</a> <a
href="#HTTP+Strict-Transport-Security+-+HSTS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>As with all providers in the Knox gateway, the web app security provider is
configured through provider parameters. 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 might follow, and you may be interested in creating your own.</p>
@@ -4322,7 +4311,7 @@ APACHE_HOME/bin/apachectl -k stop
<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>xss.protection.enabled</name><value>true</value></param>
<param><name>strict.transport.enabled</name><value>true</value></param>
@@ -4331,6 +4320,10 @@ APACHE_HOME/bin/apachectl -k stop
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4365,6 +4358,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the <code>--header "X-XSRF-Header: valid"</code> above
should result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4377,7 +4372,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This parameter enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -4495,7 +4490,7 @@ APACHE_HOME/bin/apachectl -k stop
</tbody>
</table>
<h5><a id="HTTP+Strict+Transport+Security">HTTP Strict Transport Security</a>
<a href="#HTTP+Strict+Transport+Security"><img
src="markbook-section-link.png"/></a></h5>
-<p>Web applications can be protected by protocol downgrade attacks and cookie
hijacking by adding HTTP Strict Transport Security response header.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4826,16 +4821,6 @@ APACHE_HOME/bin/apachectl -k stop
<h5><a id="SSO+topology">SSO topology</a> <a href="#SSO+topology"><img
src="markbook-section-link.png"/></a></h5>
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/books/knox-1-4-0/user-guide.html
URL:
http://svn.apache.org/viewvc/knox/site/books/knox-1-4-0/user-guide.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/books/knox-1-4-0/user-guide.html (original)
+++ knox/site/books/knox-1-4-0/user-guide.html Fri Mar 13 15:01:22 2020
@@ -4325,17 +4325,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>Use Knox samples.</p>
<h3><a id="Web+App+Security+Provider">Web App Security Provider</a> <a
href="#Web+App+Security+Provider"><img
src="markbook-section-link.png"/></a></h3>
<p>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.</p>
-<p>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.</p>
-<h4><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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. </p>
-<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
-<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
-<h4><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
-<p>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.</p>
-<h4><a id="HTTP+Strict-Transport-Security+-+HSTS">HTTP
Strict-Transport-Security - HSTS</a> <a
href="#HTTP+Strict-Transport-Security+-+HSTS"><img
src="markbook-section-link.png"/></a></h4>
-<p>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.</p>
<h4><a id="Configuration">Configuration</a> <a href="#Configuration"><img
src="markbook-section-link.png"/></a></h4>
<h5><a id="Overview">Overview</a> <a href="#Overview"><img
src="markbook-section-link.png"/></a></h5>
<p>As with all providers in the Knox gateway, the web app security provider is
configured through provider parameters. 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 might follow, and you may be interested in creating your own.</p>
@@ -4347,7 +4336,7 @@ APACHE_HOME/bin/apachectl -k stop
<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>xss.protection.enabled</name><value>true</value></param>
<param><name>strict.transport.enabled</name><value>true</value></param>
@@ -4356,6 +4345,10 @@ APACHE_HOME/bin/apachectl -k stop
<h4><a id="Descriptions">Descriptions</a> <a href="#Descriptions"><img
src="markbook-section-link.png"/></a></h4>
<p>The following tables describes the configuration options for the web app
security provider:</p>
<h5><a id="CSRF">CSRF</a> <a href="#CSRF"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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. </p>
+<p>This means that a website www.bad.com cannot send a request to <a
href="http://bank.example.com";>http://bank.example.com</a> 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).</p>
+<p>NOTE: by enabling this protection within the topology, this custom header
will be required for <em>all</em> clients that interact with it - not just
browsers.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4390,6 +4383,8 @@ APACHE_HOME/bin/apachectl -k stop
<p>Omitting the <code>--header "X-XSRF-Header: valid"</code> above
should result in an HTTP 400 bad_request.</p>
<p>Disabling the provider will then allow a request that is missing the header
through. </p>
<h5><a id="CORS">CORS</a> <a href="#CORS"><img
src="markbook-section-link.png"/></a></h5>
+<p>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.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4402,7 +4397,7 @@ APACHE_HOME/bin/apachectl -k stop
<tbody>
<tr>
<td>cors.enabled </td>
- <td>This parameter enables the CORS capabilities</td>
+ <td>Setting this parameter to true allows cross origin requests. The
default of false prevents cross origin requests.</td>
<td>false</td>
</tr>
<tr>
@@ -4520,7 +4515,7 @@ APACHE_HOME/bin/apachectl -k stop
</tbody>
</table>
<h5><a id="HTTP+Strict+Transport+Security">HTTP Strict Transport Security</a>
<a href="#HTTP+Strict+Transport+Security"><img
src="markbook-section-link.png"/></a></h5>
-<p>Web applications can be protected by protocol downgrade attacks and cookie
hijacking by adding HTTP Strict Transport Security response header.</p>
+<p>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.</p>
<h6><a id="Config">Config</a> <a href="#Config"><img
src="markbook-section-link.png"/></a></h6>
<table>
<thead>
@@ -4852,15 +4847,6 @@ APACHE_HOME/bin/apachectl -k stop
<p>To enable SSO for REST API access through the Knox gateway, you need to
protect your Hadoop services with the SSOCookieProvider configured to use the
KnoxSSO service (sandbox.xml topology):</p>
<pre><code><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/site/index.html
URL:
http://svn.apache.org/viewvc/knox/site/index.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/index.html (original)
+++ knox/site/index.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
src/site/markdown/index.md at 2020-03-12
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from
src/site/markdown/index.md 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 – Announcing Apache Knox 1.3.0!</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/issue-management.html
URL:
http://svn.apache.org/viewvc/knox/site/issue-management.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/issue-management.html (original)
+++ knox/site/issue-management.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:issue-management
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:issue-management
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 – Issue Management</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/licenses.html
URL:
http://svn.apache.org/viewvc/knox/site/licenses.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/licenses.html (original)
+++ knox/site/licenses.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:licenses 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:licenses 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 Licenses</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/mailing-lists.html
URL:
http://svn.apache.org/viewvc/knox/site/mailing-lists.html?rev=1875157&r1=1875156&r2=1875157&view=diff
==============================================================================
--- knox/site/mailing-lists.html (original)
+++ knox/site/mailing-lists.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:mailing-lists
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:mailing-lists
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 Mailing Lists</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">
