×News:
OpenXava with AI - Refine the UI (Part 2) -
December 1 ·
Read more
Since OpenXava 7.3 your
applications can comply with
OWASP
Top Ten, which means having the highest security standards for web
applications. In fact, OpenXava passes the OWASP
ZAP
web security test 100%, without any critical, medium or low level
alerts.
This does not mean that
applications made with OpenXava are automatically secure or
automatically comply with the OWASP Top Ten, because your own code could
be vulnerable, you could use your own vulnerable libraries, you could
not correctly configure your application, not correctly configure your
application server or disable some security feature of OpenXava.
Therefore, it is important that you run the ZAP test on your application
yourself, or even hire a security auditor to verify the security of your
application and compliance with the required standards.
When you run your application in development, OpenXava uses an embedded
Tomcat configured to meet all the necessary security requirements to
pass the ZAP. However, when you generate a WAR and deploy it on your
production Tomcat, your application may not be completely secure, nor
pass the ZAP. You have to configure some details.
Error pages
To pass the ZAP, error pages
cannot offer information about the server that is being used, let alone
display an error trace. When you start the application from the embedded
Tomcat for development, it is already configured to offer secure error
pages. Also, if your application was created with OpenXava 7.3 or
higher, the error pages are already well configured. But if you created
your application with an OpenXava prior to v7.3 and you are deploying a
WAR on a Tomcat, you will have to add the following in the web.xml
of your application, which is located in src/main/webapp/WEB-INF
of your project:
<error-page>
<error-code>404</error-code>
<location>/WEB-INF/error404.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/WEB-INF/error500.html</location>
</error-page>
There is no need to create error404.html
or error500.html, because they are included in openxava.jar.
Same site cookies
The same applies to cookie
settings. If you use the embedded Tomcat or your application was created
with v7.3+ there is no problem, but otherwise you have to define Same
Site Cookies as Lax in the context.xml, located in
src/main/webapp/META-INF. Add the entry <CookieProcessor
sameSiteCookies="lax" />, as you see here:
<Context>
<JarScanner scanClassPath="false" />
<CookieProcessor sameSiteCookies="lax" /> <!-- ADD THIS LINE -->
...
The ZAP test, in addition to analyzing the URL of the application you
indicate, also makes some checks in the root context where your
application is deployed. The root context in Tomcat is defined by the
ROOT application, if you do not have control over the ROOT application
or you do not mind ignoring the indications that ZAP makes about the
root context, you do not need to do anything. However, if you want to
pass the ZAP 100% with your WAR deployed in Tomcat, you will have to
make sure that the root application generates CSP headers and the X-Content-Type-Options
header.
Unfortunately, there is no quick
way to configure Tomcat for this. You will have to write the code for a
filter that generates these headers. The following code may be useful to
you:
import java.io.*;
import javax.servlet.*;
import javax.servlet.annotation.*;
import javax.servlet.http.*;
@WebFilter("/*")
public class ContentSecurityPolicyFilter implements Filter {
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setHeader("Content-Security-Policy", "default-src 'self'; frame-ancestors 'self'; form-action 'self';");
httpResponse.setHeader("X-Content-Type-Options", "nosniff");
chain.doFilter(request, response);
}
public void init(FilterConfig cfg) throws ServletException { // For Tomcat 8.x
}
public void destroy() { // For Tomcat 8.x
}
}
Compile the class and leave it
inside webapps/ROOT/WEB-INF/classes of your Tomcat, in the same
folder structure of the package where you have written the class. That
is, if the class is in the package com.yourcompany.root.filters
the ContentSecurityPolicyFilter.class should be left in the
folder webapps/ROOT/WEB-INF/classes/com/yourcompany/root/filters
of your Tomcat.
To recognize the filter, you
have to ensure that metadata-complete is set to false in
ROOT’s web.xml:
<web-app
...
metadata-complete="false">
...
Finally, you should download
ZAP and run it on your application
deployed on your Tomcat.
Disable web security
It’s not a good idea to disable security, but if your application does
not require strict security compliance and will be run in a secure
environment, there may be times when it is convenient to disable web
security either totally or partially. This may be necessary if we have a
lot of our own old web code that does not follow good security practices
or if we use third-party libraries that also do not comply with them.
Specifically, OpenXava, since
version 7.3, has a strict Content Security Policy (CSP). This
means that the browser is instructed not to do things that can
potentially be dangerous. Which in turn restricts the things that can be
used.
For example, you can only
download images, scripts, CSSs or open frames from the same address from
where the application has been downloaded. If we need to download
resources from another site, it can be done by adding the properties trustedHostsForImages,
trustedHostsForScripts, trustedHostsForStyles and trustedHostsForFrames
in the xava.properties file of our project, as in this example:
trustedHostsForImages=https://openxava.org/
trustedHostsForScripts=https://openxava.org/
trustedHostsForStyles=https://openxava.org/
trustedHostsForFrames=https://openxava.org/
In this example, it is allowed
to download images, JavaScript, CSSs and open iframes from openxava.org.
Using these properties is not dangerous if the addresses we put are
trustworthy. We can put several separated by commas.
On the other hand, by default,
the CSP is configured to not allow the use of eval() in
JavaScript. If we have our own code that uses eval() or a
third-party library that needs it, we can enable the use of eval()
with the following line in xava.properties:
Enabling the use of eval()
is always dangerous, so this should be a temporary measure and you
should start thinking about rewriting your code to not use eval()
or update the corresponding JavaScript library.
In addition, the Content
Security Policy (CSP) header can be completely disabled. Add to xava.properties:
Doing this is a quick way to see
your application working if you have updated to version 7.3+ from an old
version of OpenXava, but it constitutes a significant security risk,
because strict CSP is what allows inhibiting most security risks.