This is an automated email from the ASF dual-hosted git repository.
jleroux pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ofbiz-site.git
The following commit(s) were added to refs/heads/master by this push:
new d4fb793 Improved: about securing
themes/common-theme/webapp/images/products subdirectories
d4fb793 is described below
commit d4fb793c3574dd59661d54b3aa5610ae1ab419ef
Author: Jacques Le Roux <[email protected]>
AuthorDate: Sun Sep 28 17:53:25 2025 +0200
Improved: about securing themes/common-theme/webapp/images/products
subdirectories
---
security.html | 14 +++++++++++---
template/page/security.tpl.php | 14 +++++++++++---
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/security.html b/security.html
index e42bd4b..46eff2c 100644
--- a/security.html
+++ b/security.html
@@ -126,13 +126,21 @@
<a
href="//cwiki.apache.org/confluence/display/OFBIZ/How+to+secure+your+deployment"
target="external">How to secure your deployment.</a><br>
<p> </p>
- <p><strong>All system privileges, including access to potentially
vulnerable operations, are granted to administrators</strong>. Even if we
assume that administrators don't attack their own websites, it's essential to
exercise extra care when granting administrator privileges.
- Therefore, if a security breach occurs on the
administration page (webtools), it's generally not perceived as a problem. The
administrator holds the power. Unless an ordinary user manages to overstep
their bounds and act beyond their authority.
+ <p><strong>All system privileges, including access to potentially
vulnerable operations, are granted to administrators</strong>.
+ Even if we assume that administrators don't attack
their own websites, it's essential to exercise extra care when granting
administrator privileges.
+ Therefore, if a security breach occurs on the
administration page (webtools), it's generally not perceived as a problem. The
administrator holds the power.
+ Unless an ordinary user manages to overstep their
bounds and act beyond their authority.
So in the webtools page we only accept vulnerabilities
when using a not administrator credential.
</p>
- <p><strong>At the UI level the OFBiz logs are protected and should
not be vulnerable to exploits</strong>. We though warn OFBiz users it's
important that out of OFBiz UI level logs files remain restricted to their
trusted users.
+ <p><strong>At the UI level the OFBiz logs are protected and should
not be vulnerable to exploits</strong>.
+ We though warn OFBiz users it's important that out of OFBiz
UI level logs files remain restricted to their trusted users.
Also we recommend to use the <strong>verbose level on
production</strong> only when it's absolutely necessary.</p>
+ Another case where access needs to be restricted to trusted
users is inside subdirectories of themes/common-theme/webapp/images/products.
+ Specifically because images upload for products is possible
in those places. Hence possible embedded webshells, even if OFBiz has a robust
protection.
+ As recommended by OWASP, a solid solution is to move the
products images upload to another domain.
+ You may also simply prevent security issues by making these
subdirectories non-executable.
+
<h2><a id="security"></a>Security Vulnerabilities</h2>
<div class="divider"><span></span></div>
diff --git a/template/page/security.tpl.php b/template/page/security.tpl.php
index 3bd1ac2..104ab0b 100644
--- a/template/page/security.tpl.php
+++ b/template/page/security.tpl.php
@@ -27,13 +27,21 @@
<a
href="//cwiki.apache.org/confluence/display/OFBIZ/How+to+secure+your+deployment"
target="external">How to secure your deployment.</a><br>
<p> </p>
- <p><strong>All system privileges, including access to potentially
vulnerable operations, are granted to administrators</strong>. Even if we
assume that administrators don't attack their own websites, it's essential to
exercise extra care when granting administrator privileges.
- Therefore, if a security breach occurs on the
administration page (webtools), it's generally not perceived as a problem. The
administrator holds the power. Unless an ordinary user manages to overstep
their bounds and act beyond their authority.
+ <p><strong>All system privileges, including access to potentially
vulnerable operations, are granted to administrators</strong>.
+ Even if we assume that administrators don't attack
their own websites, it's essential to exercise extra care when granting
administrator privileges.
+ Therefore, if a security breach occurs on the
administration page (webtools), it's generally not perceived as a problem. The
administrator holds the power.
+ Unless an ordinary user manages to overstep their
bounds and act beyond their authority.
So in the webtools page we only accept vulnerabilities
when using a not administrator credential.
</p>
- <p><strong>At the UI level the OFBiz logs are protected and should
not be vulnerable to exploits</strong>. We though warn OFBiz users it's
important that out of OFBiz UI level logs files remain restricted to their
trusted users.
+ <p><strong>At the UI level the OFBiz logs are protected and should
not be vulnerable to exploits</strong>.
+ We though warn OFBiz users it's important that out of OFBiz
UI level logs files remain restricted to their trusted users.
Also we recommend to use the <strong>verbose level on
production</strong> only when it's absolutely necessary.</p>
+ Another case where access needs to be restricted to trusted
users is inside subdirectories of themes/common-theme/webapp/images/products.
+ Specifically because images upload for products is possible
in those places. Hence possible embedded webshells, even if OFBiz has a robust
protection.
+ As recommended by OWASP, a solid solution is to move the
products images upload to another domain.
+ You may also simply prevent security issues by making these
subdirectories non-executable.
+
<h2><a id="security"></a>Security Vulnerabilities</h2>
<div class="divider"><span></span></div>
