As tech lead, I need critical finding from WebInspect Oct 2022 scan addressed

[ADPennington]

Description:

ACF OCIO performs monthly security scans on prod using WebInspect, and has one critical finding for Oct 2022:

"WebInspect has detected support for weak TLS/SSL ciphers on the server https://tanfdata.acf.hhs.gov:443/runtime-main.[hash].js". More information is on p. 23 here :lock:

Per OCIO, we have 2 weeks to address critical findings. When we need more time to resolve, we should inform them.

Acceptance Criteria:

• [ ] source of issue identified
• [ ] source of issue resolved or documented
• [ ] Testing Checklist has been run and all tests pass
• [ ] README is updated, if necessary

Tasks:

• [ ] investigate root cause
• [ ] look into why this isnt showing up in owasp scans
• [ ] resolve/document
• [ ] Run Testing Checklist and confirm all tests pass

Notes:

• Note 1
• Note 2
• Note 3

Supporting Documentation:

• about runtime-main.[hash].js

[ADPennington]

@jtimpe the critical finding description is on page 8 of the above attachment. and the dependency appears as a low finding from zap here

[jtimpe]

@ADPennington @stevenino @andrew-jameson bit of an update here based on some research

• (Draft PR) attempt to resolve

I attempted to update our ssl_protocol for nginx to TLS 1.3, but it didn't work. I think that's because Cloud.gov sits between the client and the nginx instance we have set up to serve the frontend. Since Cloud.gov is the first party to handle the request, whatever SSL/TLS protocols they support are what the browser will negotiate with. Our nginx configuration only applies to the connection between the Cloud.gov load balancer that initially serves the request and our frontend application.

In Firefox (and I assume Chrome), you can see the protocol settings in DevTools by going to the Network tab, selecting the request to /, and selecting the Security tab

From the Cloud.gov SSL/TLS docs

Our TLS implementation and cipher suites are consistent with White House Office of Management and Budget’s M-15-13, the Department of Homeland Security’s Binding Operational Directive 18-01, and the NIST Guidelines for TLS Implementations. Some SSL/TLS scanners will nonetheless return results flagging the following ciphers as “weak”:

TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003C)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC027)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC028)

I'm afraid this looks like another platform limitation. Unfortunately, we can't update the TLS protocol version for the browser-to-load-balancer part of the request, Cloud.gov handles that. According to their documentation, though, the implementation is secure and we should be able to ignore the finding.

[ADPennington]

Thanks @jtimpe this is helpful. I think we can document this on our false positive form and submit to TDP ISSOs. Once the security team approves we can close this ticket. cc: @stevenino @andrew-jameson @AiseosaO @tdrammeh1

I'm wondering if we need to keep track of findings that show up in the security scans that will not get remediated. we have one for zap here and maybe we should have a similar one for webinspect. 🤔

[stevenino]

False positives will be documented in ATO documents.