This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git

commit a721ba7557a6b474a66efa6de2600d8894330a15
Author: Jacques Le Roux <jacques.le.r...@les7arts.com>
AuthorDate: Mon Apr 20 18:57:58 2020 +0200

    Documented: fixes wrong indentations
---
 .../security/src/docs/asciidoc/_include/sy-CSRF-defense.adoc |  8 ++++----
 .../src/docs/asciidoc/_include/sy-password-and-JWT.adoc      | 12 ++++++------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/framework/security/src/docs/asciidoc/_include/sy-CSRF-defense.adoc 
b/framework/security/src/docs/asciidoc/_include/sy-CSRF-defense.adoc
index 867150e..889c960 100644
--- a/framework/security/src/docs/asciidoc/_include/sy-CSRF-defense.adoc
+++ b/framework/security/src/docs/asciidoc/_include/sy-CSRF-defense.adoc
@@ -38,14 +38,14 @@ ____
 By default OOTB the SameSiteFilter property sets the same-site attribute value 
to 'strict. SameSiteFilter allows to change to 'lax' if needed. If you use 
'lax' we recommend that you set the csrf.defense.strategy property to 
org.apache.ofbiz.security.CsrfDefenseStrategy in order to provide an effective 
defense against CSRF attacks.
 
 
-===== Properties
+==== Properties
 
 The _security.properties_ file contains related properties:
 
     # -- By default the SameSite value in SameSiteFilter is 'strict'.
     # -- This property allows to change to 'lax' if needed.
-    # -- If you use 'lax' we recommend that you set 
-    # -- org.apache.ofbiz.security.CsrfDefenseStrategy 
+    # -- If you use 'lax' we recommend that you set
+    # -- org.apache.ofbiz.security.CsrfDefenseStrategy
     # -- for csrf.defense.strategy (see below)
     SameSiteCookieAttribute=
 
@@ -68,7 +68,7 @@ The _security.properties_ file contains related properties:
     # -- Because OFBiz OOTB also sets the SameSite attribute to 'strict' for 
all cookies,
     # -- which is an effective CSRF defense,
     # -- default is org.apache.ofbiz.security.NoCsrfDefenseStrategy if not 
specified.
-    # -- Use org.apache.ofbiz.security.CsrfDefenseStrategy 
+    # -- Use org.apache.ofbiz.security.CsrfDefenseStrategy
     # -- if you need to use a 'lax' for SameSiteCookieAttribute
     csrf.defense.strategy=
 
diff --git 
a/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc 
b/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc
index c1bdee4..684a3f9 100644
--- a/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc
+++ b/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc
@@ -55,12 +55,12 @@ Cross-origin resource sharing) on the target server
 
 
 ==== How to secure JWT
-When you use JWT, in order to sign your tokens, you have the choice of using a 
sole so called secret key or a pair of public/private keys: 
https://jwt.io/introduction/. 
+When you use JWT, in order to sign your tokens, you have the choice of using a 
sole so called secret key or a pair of public/private keys: 
https://jwt.io/introduction/.
 
 You might prefer to use pair of public/private keys, for now by default OFBiz 
uses a simple secret key. Remains the way how to store this secret key. 
https://security.stackexchange.com/questions/87130/json-web-tokens-how-to-securely-store-the-key[This
 is an interesting introduction about this question].
 
-. The first idea which comes to mind is to use a property in the 
security.properties file. It's safe as long as your file system is not 
compromised. 
-. You may also pick a SystemProperty entity (overrides the file property). 
It's safe as long as your DB is not compromised. 
+. The first idea which comes to mind is to use a property in the 
security.properties file. It's safe as long as your file system is not 
compromised.
+. You may also pick a SystemProperty entity (overrides the file property). 
It's safe as long as your DB is not compromised.
 . We recommend to not use an environment variable as those can be considered 
weak:
 * http://movingfast.io/articles/environment-variables-considered-harmful
 * 
https://security.stackexchange.com/questions/49725/is-it-really-secure-to-store-api-keys-in-environment-variables
@@ -68,7 +68,7 @@ You might prefer to use pair of public/private keys, for now 
by default OFBiz us
 . You may want to tie the encryption key to the logged in user. This is used 
by the password recreation feature. The JWT secret key is salted with a 
combination of the current logged in user and her/his password. This is a 
simple and effective safe way.
 . Use a https://tools.ietf.org/html/rfc7519#section-4.1.7[JTI] (JWT ID). A JTI 
prevents a JWT from being replayed. This 
https://auth0.com/blog/blacklist-json-web-token-api-keys/http://url[auth0 blog 
article get deeper in that].  The same is kinda achieved with the password 
recreation feature. When the user log in after the new password creation, the 
password has already been  changed. So the link (in the sent email) containing 
the JWT for the creation of the new password can't be reused.
 . Tie the encryption key to the hardware. You can refer to this 
https://en.wikipedia.org/wiki/Hardware_security_module[Wikipedia page] for more 
information.
-. If you want to get deeper in this get to this 
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Key_Management_Cheat_Sheet.md#user-content-storage[OWASP
 documentation] 
+. If you want to get deeper in this get to this 
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Key_Management_Cheat_Sheet.md#user-content-storage[OWASP
 documentation]
 
 Note: if you want to use a pair of public/private keys you might want to 
consider  leveraging the Java Key Store that is also used by the "catalina" 
component to store certificates. Then don't miss to read:
 
@@ -112,7 +112,7 @@ The introduction of the same-site attribute set to 'strict' 
for all cookies prev
 
 So same-site attribute set to 'none' is necessary for the internal SSO to 
work, https://github.com/whatwg/fetch/issues/769['lax' is not enough]. So if 
someone wants to use the internal SSO feature s/he also needs to use  the CSRF 
token defense. If s/he wants to be safe from CSRF attacks. Unfortunately, due 
backporting difficulties, this option is currently (2020-04-15) only available 
in trunk.
 
-====== Fecth API
+===== Fecth API
 An alternative would be to use the Fetch Javascript API with the
 
 [source]
@@ -126,4 +126,4 @@ For those interested, there are more information in 
https://issues.apache.org/ji
 
 
 === Last but not least
-Be sure to read 
https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure[Keeping 
OFBiz secure]
\ No newline at end of file
+Be sure to read 
https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure[Keeping 
OFBiz secure]

Reply via email to