knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pzamp...@apache.org
Subject svn commit: r1827045 - in /knox: site/books/knox-1-1-0/user-guide.html trunk/books/1.1.0/book.md trunk/books/1.1.0/config_webappsec_provider.md
Date Fri, 16 Mar 2018 20:18:50 GMT
Author: pzampino
Date: Fri Mar 16 20:18:50 2018
New Revision: 1827045

URL: http://svn.apache.org/viewvc?rev=1827045&view=rev
Log:
Corrected Strict-Transport-Security typos

Modified:
    knox/site/books/knox-1-1-0/user-guide.html
    knox/trunk/books/1.1.0/book.md
    knox/trunk/books/1.1.0/config_webappsec_provider.md

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=1827045&r1=1827044&r2=1827045&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 16 20:18:50 2018
@@ -81,7 +81,7 @@
     <li><a href="#CSRF">CSRF</a></li>
     <li><a href="#CORS">CORS</a></li>
     <li><a href="#X-Frame-Options">X-Frame-Options</a></li>
-    <li><a href="#HTTP+Strict-Tranport-Security+-+HSTS">HTTP Strict-Tranport-Security
- HSTS</a></li>
+    <li><a href="#HTTP+Strict-Transport-Security+-+HSTS">HTTP Strict-Transport-Security
- HSTS</a></li>
   </ul></li>
   <li><a href="#Websocket+Support">Websocket Support</a></li>
   <li><a href="#Audit">Audit</a></li>
@@ -3228,7 +3228,7 @@ chmod 400 knox.service.keytab
 </ul><h6><a id="Start/stop+Apache+HTTP+Server">Start/stop Apache HTTP Server</a>
<a href="#Start/stop+Apache+HTTP+Server"><img src="markbook-section-link.png"/></a></h6>
 <pre><code>APACHE_HOME/bin/apachectl -k start
 APACHE_HOME/bin/apachectl -k stop
-</code></pre><h6><a id="Verify">Verify</a> <a href="#Verify"><img
src="markbook-section-link.png"/></a></h6><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 wit
 hout 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 XMLHttpReques
 t. 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 pa
 rams. 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><p>Because
of this one-to-many provider/filter relationship, there is an extra configuration element
for this provider per filter. As you can see in the sample below, the actual filter configuration
is defined entirely within the params of the WebAppSec provider.</p>
+</code></pre><h6><a id="Verify">Verify</a> <a href="#Verify"><img
src="markbook-section-link.png"/></a></h6><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 wit
 hout 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 XMLHttpReques
 t. 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
  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><p>Because
of this one-to-many provider/filter relationship, there is an extra configuration element
for this provider per filter. As you can see in the sample below, the actual filter configuration
is defined entirely within the params of the WebAppSec provider.</p>
 <pre><code>&lt;provider&gt;
     &lt;role&gt;webappsec&lt;/role&gt;
     &lt;name&gt;WebAppSec&lt;/name&gt;

Modified: knox/trunk/books/1.1.0/book.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/1.1.0/book.md?rev=1827045&r1=1827044&r2=1827045&view=diff
==============================================================================
--- knox/trunk/books/1.1.0/book.md (original)
+++ knox/trunk/books/1.1.0/book.md Fri Mar 16 20:18:50 2018
@@ -78,7 +78,7 @@
     * #[CSRF]
     * #[CORS]
     * #[X-Frame-Options]
-    * #[HTTP Strict-Tranport-Security - HSTS]
+    * #[HTTP Strict-Transport-Security - HSTS]
 * #[Websocket Support]
 * #[Audit]
 * #[Client Details]

Modified: knox/trunk/books/1.1.0/config_webappsec_provider.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/1.1.0/config_webappsec_provider.md?rev=1827045&r1=1827044&r2=1827045&view=diff
==============================================================================
--- knox/trunk/books/1.1.0/config_webappsec_provider.md (original)
+++ knox/trunk/books/1.1.0/config_webappsec_provider.md Fri Mar 16 20:18:50 2018
@@ -36,7 +36,7 @@ For security reasons, browsers restrict
 
 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
 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.
 
 



Mime
View raw message