Many software companies now use automated security test tools and many of them do a regular set of scans to ensure their application is well protected and secure.
One of the good tips to help minimized the reported issues and to avoid false positives, is to configure the application reverse proxy in the right way.
In this post, I will focus on Apache and how to add a simple configuration to mitigate multiple reported issues found by automated tools.
In this example, I am scanning a simple Java web form running behind Apache which acts as a reverse proxy in this case.
Below is the initial scan report:
Below is an example configuration for the domain http://172.17.0.1/:
# Set those headers to enable right CORS headers.
Header always set Access-Control-Allow-Origin "http://172.17.0.1"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"
Header always set Access-Control-Expose-Headers "*"
# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
# Set x-frame-options to sameorigin to combat click-jacking.
Header always set X-Frame-Options SAMEORIGIN
# Set Samesite to strict to counter potential session cookie hijacking, also helps protect
# from CSRF though session cookie.
Header edit Set-Cookie ^(.*)$ $1;SameSite=strict
# Set X-Content-Type-Options to nosniff to avoid MIME sniffing.
Header always set X-Content-Type-Options nosniff
As you can see, the above rules address multiple issues reported in the scan, mainly to protect agains CORS problems,click-jacking, XSS though cookies and Anti-MIME sniffing.
Once that configuration is in effect, the number of reported issues is much less:
The last problem related to CSRF is an architectural problem in the application.
Modern web applications are encouraged to use tokens injected into the HTML pages and forms, dynamic generated content and on server side to validate that same user with same session is one who is submitting the request without being hijacked by some malicious attack.
Check https://en.wikipedia.org/wiki/Cross-site_request_forgery for more information.
Modsecurity does have rules that work by injecting content to help with CSRF, though, if applied without change, it could break the application functionality.
One of the good tips to help minimized the reported issues and to avoid false positives, is to configure the application reverse proxy in the right way.
In this post, I will focus on Apache and how to add a simple configuration to mitigate multiple reported issues found by automated tools.
In this example, I am scanning a simple Java web form running behind Apache which acts as a reverse proxy in this case.
Below is the initial scan report:
As you can see, there are multiple findings in the scan report, mainly we have problems with the below:
- X-Frame-Options Header Not Set
- X-Content-Type-Options Header Missing
- Absence of Anti-CSRF Tokens
- Cookie Without SameSite Attribute
- Charset Mismatch (Header Versus Meta Charset) (informational finding)
Below is an example configuration for the domain http://172.17.0.1/:
# Set those headers to enable right CORS headers.
Header always set Access-Control-Allow-Origin "http://172.17.0.1"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"
Header always set Access-Control-Expose-Headers "*"
# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
# Set x-frame-options to sameorigin to combat click-jacking.
Header always set X-Frame-Options SAMEORIGIN
# Set Samesite to strict to counter potential session cookie hijacking, also helps protect
# from CSRF though session cookie.
Header edit Set-Cookie ^(.*)$ $1;SameSite=strict
# Set X-Content-Type-Options to nosniff to avoid MIME sniffing.
Header always set X-Content-Type-Options nosniff
As you can see, the above rules address multiple issues reported in the scan, mainly to protect agains CORS problems,click-jacking, XSS though cookies and Anti-MIME sniffing.
Once that configuration is in effect, the number of reported issues is much less:
The last problem related to CSRF is an architectural problem in the application.
Modern web applications are encouraged to use tokens injected into the HTML pages and forms, dynamic generated content and on server side to validate that same user with same session is one who is submitting the request without being hijacked by some malicious attack.
Check https://en.wikipedia.org/wiki/Cross-site_request_forgery for more information.
Modsecurity does have rules that work by injecting content to help with CSRF, though, if applied without change, it could break the application functionality.
