AppScan issues with the default OOD configuration

Get Help
1

We are using AppScan to evaluate OOD for DoD policy compliance, and have noted a few things that should be changed by default – and some things that we don’t know how to fix (if they can be fixed).

One basic thing is that by default the Apache configuration includes "Indexes FollowSymLinks" – these are frowned upon by the scan and triggered multiple warnings. We resolved this by changing "Indexes FollowSymLinks" to "-Indexes -FollowSymLinks" in

/opt/ood/ood-portal-generator/templates/ood-portal.conf.erb

… and that fixed those warnings. I notice there is the "Indexes FollowSymLinks" pattern elsewhere in /opt/ood/portal-generator … they didn’t seem to trigger warnings, so we left them alone – but they should be evaluated for change as well.

There is also the mandated use of TLS v1.2+ and removal of insecure ciphers, which required these statements to be added to ood-portal.yml:

  • ‘SSLProtocol TLSv1.2’
  • ‘SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256’

What remains are some things that we don’t know how to fix or deal with:

  1. [High] “Phishing through URL Redirection” (https://x.x.x/nginx/stop) – I think this is part of the logout process (which we’re not really using since we’re using OIDC authentication). The issue is that even though the user may not ever see this URL go by, a malicious party could craft a URL that would redirect someone to a malicious site. I couldn’t find how to disable this …
  2. [Low] “Apache Multiviews Attack” (https://x.x.x/icons/ ) – their recommended fix is to just disable the Apache Multiviews feature. Will that break OOD? Normally this is off unless explicitly turned on, but we can’t find where it is enabled. How would this be done (either disabling it or not enabling it)?
  3. [Low] “Missing or Insecure headers”, including (with ‘normal’ mitigations):
    – “Object-Src” policy in “Content-Security-Policy” (Header set Content-Secure-Policy "default-src 'self';")
    – “Script-Src” policy in “Content-Security-Policy” (Header set Content-Secure-Policy "default-src 'self';")
    – “X-Content-Type-Options” (Header set X-Content-Type-Options nosniff)
    – “X-XSS-Protection” (Header set X-XSS-Protection "1; mode=block")
    Normally these would be easy to mitigate with header commands (examples in parenthesis after each header), but we’re not sure how/where to set things where they will be effective since the Apache configuration is dynamic.

Thanks for your help!

2

Hi thanks for the topic and sorry for the delay!

Here are some answers to those questions:

  1. this is an active part of OnDemand. It’s how you ‘restart your webserver’ from the Help menu. I’ll have to lookup if you can disable this (I don’t believe you can). We have put work into validating those redirects, though it won’t be until 2.1.
  2. I don’t believe this will break OOD.
  3. You may be able to hack the auth settings in the ood_portal for extra lines like so. Though putting a content security policy here (in the /node and /rnode Locations) may break some apps.
auth:
  - # your actual auth settings
  - Header set Content-Secure-Policy "default-src 'self';
3

We also scanned the system with AppSpider, and resolved some of those as such:

  1. nginx stop redirects broken · Issue #1800 · OSC/ondemand · GitHub was resolved.
  2. We set a bunch of things using the ssl: config in ood_protal.yml as such:
ssl:
  - 'SSLCertificateFile "..."'
  - 'SSLCertificateKeyFile "..."'
  - SSLProxyEngine on
  - SSLProtocol +TLSv1.2
  - SSLCipherSuite ECDH+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256
  - SSLHonorCipherOrder on
  - FileETag None
  - TraceEnable off
  - Header unset "X-Powered-By"
  - Header unset "Via"
  - Header unset "ETag"
  - Header always set X-Content-Type-Options "nosniff"
  - Header always set X-Frame-Options "SAMEORIGIN"
  - Header always set X-Xss-Protection "1; mode=block"
  - Header always set X-Permitted-Cross-Domain-Policies "none"
  - Header always set Strict-Transport-Security "max-age=31536000"
  - "Header always set Content-Security-Policy \"default-src https: wss: data: 'unsafe-inline' 'unsafe-eval'\""

You can customize it to your liking.

1 Like
4

Yep actually @karcaw is right, you can use ssl to set it globally instead of auth within every Location.

5

You may be able to disable the nginx uri by setting it to null. But as we’ve indicated in the open office hours, users being able to bounce their own is kind of a nice feature.

nginx_uri: null

https://osc.github.io/ood-documentation/latest/reference/files/ood-portal-yml.html#configure-per-user-nginx

Lastly - we did patch the redirects. We didn’t backport it to 2.0, but we could.

6

Wrote that too soon. Looks like if you unset that variable. OOD won’t work at all! The /pun URLs don’t get generated!

7

Which is to say - there’s no resolution we have for you at this time. I don’t believe you can disable this.

We can backport the fixes for redirects, but we still have redirects to /pun URLs. The fix we added was just to ensure that URLs you’re being redirected to are relative (the current host you’re on) and start with /pun.

8

@jeff.ohrstrom - thanks for the information!

Where would I look to see the patch that addresses this in 2.1? What is the current forecast for when 2.1 will be released?

No need to backport on our account (yet) since this is just the pilot project. When the customer decides to deploy OOD program-wide, I hope 2.1 will be out anyway, and we’ll be good.

9

As for #2 in the original post … you say it shouldn’t kill OOD – but we can’t find where it is enabled, and can’t identify a good place to try to disable it. Can you point us to where it should be disabled?

10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.