Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

This article provides advice for ensuring a secure environment for Redesign applications.   The SSDT uses a number of standard tools and frameworks (Tomcat, Spring Security, etc) which implement best practices for web application security.   In March 2019, a "Penetration Test" was executed against USPS-R and USAS-R to help ensure the applications were performing as expected.   The results of the test revealed several minor potential vulnerabilities.  The SSDT has made adjustments to the software to resolve the issues which can be handled in code.

...

Internally, the USxS-R application run under Apache Tomcat 8.5 listening on unencrypted port 8080.  The intention is to never allow access to this port directly.  

In the The default docker configuration recommended by the SSDT does not expose port 8080 on the docker engine.   The port should only be accessible by the reverse proxy running on the same server as the application containers.  If However, ff the ITC is using an external reverse proxy, the then port 8080 must will be exposed on the docker engine, but must not be exposed to the public internet thru the firewall.  If possible, access to port 8080 should be limited to the reverse proxy.

...

If the reverse proxy accepts connections to port 80 (or any unsecured port), then the reverse proxy must do a forced redirect to port 433 (secured port).  The reverse proxy should must not allow any request to reach the application on using an unsecured connection.  This is important so that the "session cookie" is not created by the application and is never transmitted over  over a unsecured connection.    It is also important that the reverse proxy redirects for both "root" path access and "deep linking".   For example, if the browser attempts a request to "http://yourserver/vui/login", the reverse proxy should redirect to "https://yourserver/vui/login". 

...

The reverse proxy should automatically apply the HSTS (HTTP Strict Transport Security) headers header to all responses from on the HTTPS port.   This header instructs the browser to never contact the host name in the URL on an unsecured port.  It effectively causes the browser to automatically redirect if the user enters an unsecure URL.  Again, this ensures that the "session cookie" created by the application is never transmitted over an unsecure connection.


Info

The example reverse proxy configuration provided by the SSDT using the "nginx-proxy" image automatically implement both the forced redirect and HSTS headers.  If you are using 'nginx-proxy' configured with an SSL certificate or Let's Encrypt, then the reverse proxy will implement these recommendations.

Disable TCP Timestamps

A common security best practice is to disable IP4 TCP timestamps.  Timestamps in IP packets can enable a potential attacker to determine your system uptime and therefore be able to determine if your system might not be patched for a vulnerability which requires reboot.  If you wish to disable IP4 timestamps, you can  do the following:

Code Block
>  echo "net.ipv4.tcp_timestamps = 0" > /etc/sysctl.d/net.tcp_timestamps.conf
> sysctl -p

the above recommendations.

Verify Correct Proxy Behavior

You can use CURL (or other utilities, including Chrome's developer tools) to verify the correct behavior of the reverse proxy.  Below are a few examples of using CURL to test redirect and security headers.  These examples were executed against the SSDT Demo server that is using nginx-proxy using a wildcard SSL certificate. 

...

Code Block
$ curl --head https://pentest-usas.demo.ssdt.io/vui/app
HTTP/2 302
server: nginx/1.14.1
date: Thu, 11 Apr 2019 18:34:29 GMT
set-cookie: JSESSIONID=B187DCAE08077163C03D732DF3AFA9B8; Path=/; HttpOnly
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
strict-transport-security: max-age=31536000 ; includeSubDomains
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
location: https://pentest-usas.demo.ssdt.io/vui/login/#!login-page
strict-transport-security: max-age=31536000


Info

Notice that in In the final example, the following headers are included:

  • cache-control: no-cache, no-store, max-age=0, must-revalidate
  • pragma: no-cache
  • expires: 0
  • x-xss-protection: 1; mode=block
  • x-frame-options: SAMEORIGIN

These are the standard set of response headers for all request which produce "dynamic" responses.  That is, any response which may contain application data includes these headers.  The first three headers prevent browsers (and standards compliant proxy servers) from caching and storing the responses.   The final two headers enable browser protections against XSS (cross site scripting) and frameset "click jacking" attacks.  

Disable TCP Timestamps

A common security best practice is to disable IP4 TCP timestamps.  Timestamps in IP packets can enable a potential attacker to determine your system uptime and therefore be able to determine if your system might not be patched for a vulnerability which requires reboot.  If you wish to disable IP4 timestamps, you can  do the following:

Code Block
>  echo "net.ipv4.tcp_timestamps = 0" > /etc/sysctl.d/net.tcp_timestamps.conf
> sysctl -p


Content by Label
showLabelsfalse
max5
spacesrtd
showSpacefalse
sortmodified
reversetrue
typepage
cqllabel = "kb-how-to-article" and type = "page" and space = "rtd"
labelskb-how-to-article

...