[Security][High] csrftoken set via HTTP, not HTTPS (due 3/8/25)

[exalate-issue-sync]

Description:

Cookie with a "secure" attribute was initially set by an insecure connection; i.e. HTTP vs HTTPS. (INFO, Severity level 1)

During the initial setting of the secure cookie through an insecure connection, a Man In The Middle attack could be performed and cookie data can be stolen; the cookie will then be transmitted to the server only using a secure connection. In this case, the "secure" attribute will not protect the cookie as it could be compromised in the setting phase.

| Request Method | Request URL | Request Headers | Response | | GET | http://test-api.fecfile.fec.gov/ | Host: test-api.fecfile.fec.gov User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.171 Safari/537.36 Accept: / | csrftoken=ahVYVcKiocwRkM2ev8WZZeDtlmO2lYsj; expires=Wed Feb 4 18:14:48 2026; path=/; domain=.fecfile.fec.gov; max-age=31449481; secure Cookies set via JavaScript do not have an associated HTTP response header. |

Solution:

The general recommendation is to send "secure" cookies to client only using secure connection.

May involve editing or working with django middleware

QA Notes

Developers will present artifact of change for verification

DEV Notes

null

Design

null

See full ticket and images here: FECFILE-2007

[exalate-issue-sync]

Dan Fowlkes commented: BLUF: I believe that this is almost entirely mitigated by our web-app config which exclusively uses HTTPS, therefore web-app will never call web-api via HTTP. The only way someone could MITM an HTTP request to web-api would be if they were calling the APIs directly over HTTP (as the vuln test did) and then it may only work for the first request.

In my testing I believe that was able to reproduce this initially. After some additional testing I went back to take screenshots of the evidence to include in this write-up but was unable to reproduce that initial success. One possibility is that this issue only manifests the first time after which the HTTP301 Permanent Redirect from HTTP to HTTPS prevents the possibility of it happening again (even after clearing the host cache and disabling caching, restarting the browser, etc.) Subsequent attempts to hit via HTTP resulted in HTTP307 Internal Redirects at best, with no cookie set until already on HTTPS. The other possibility is that I never reproduced the issue at all and that I didn’t notice, when examining request headers and response headers when I’d switched from HTTP to HTTPS.

Regardless. According to the scan findings report excerpted above, this issue occurs if/when one intentionally goes to http://test-api.fecfile.fec.gov/, which rightly responds with an HTTP301 permanent redirect to https://test-api.fecfile.fec.gov/ BUT allegedly (the very first time?) also responds with a csrftoken while still on HTTP. Should this happen it would be a Severity level 1 finding (-- the lowest) per the report.

In all subsequent testing, I have found that (based on the headers) the redirect from HTTP to HTTPS is happening in CloudFront before ever reaching the server, which does not forward cookies through by default. Have we created a whitelist in CF with csrftoken?

Regardless, the only way that this could be reproduced would be intentionally hitting our APIs via HTTP. This could happen at most once due to CF responding with an HTTP301 Permanent Redirect from HTTP and HTTPS. So long as web-app calls web-api via HTTPS there is no danger.

[exalate-issue-sync]

Dan Fowlkes commented: In further testing, AWS Cloudfront redirects HTTP requests to HTTPS with a 301 Permanent Redirect before they reach nginx, much less django:

{noformat}$ curl -v http://test-api.fecfile.fec.gov

• Host test-api.fecfile.fec.gov:80 was resolved.
• IPv6: 2600:9000:201e:2000:a:35dc:4680:93a1, 2600:9000:201e:de00:a:35dc:4680:93a1, 2600:9000:201e:1200:a:35dc:4680:93a1, 2600:9000:201e:5200:a:35dc:4680:93a1, 2600:9000:201e:8e00:a:35dc:4680:93a1, 2600:9000:201e:7000:a:35dc:4680:93a1, 2600:9000:201e:c000:a:35dc:4680:93a1, 2600:9000:201e:b600:a:35dc:4680:93a1
• IPv4: 52.85.151.87, 52.85.151.97, 52.85.151.94, 52.85.151.124
• Trying 52.85.151.87:80...
• Connected to test-api.fecfile.fec.gov (52.85.151.87) port 80

GET / HTTP/1.1
Host: test-api.fecfile.fec.gov
User-Agent: curl/8.5.0
Accept: /

< HTTP/1.1 301 Moved Permanently
< Server: CloudFront
< Date: Thu, 13 Feb 2025 23:45:20 GMT
< Content-Type: text/html
< Content-Length: 167
< Connection: keep-alive
< Location: https://test-api.fecfile.fec.gov/
< X-Cache: Redirect from cloudfront
< Via: 1.1 8d6071bd169bbf5fd46638140132b1d0.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: IAD89-C3
< X-Amz-Cf-Id: neTKIxZlZR1KgBkjrnlwXmZt4bp9T85dmpyssWOkGIi7CQQ-xR2hWg==
{noformat}

No csrf token cookie is set hitting (just) [test-api.fecfile.fec.gov|http://test-api.fecfile.fec.gov] via HTTPS:

{noformat}$ curl -v -c - https://test-api.fecfile.fec.gov

• Host test-api.fecfile.fec.gov:443 was resolved.
• IPv6: 2600:9000:201e:e200:a:35dc:4680:93a1, 2600:9000:201e:3400:a:35dc:4680:93a1, 2600:9000:201e:8c00:a:35dc:4680:93a1, 2600:9000:201e:d200:a:35dc:4680:93a1, 2600:9000:201e:6000:a:35dc:4680:93a1, 2600:9000:201e:a600:a:35dc:4680:93a1, 2600:9000:201e:d600:a:35dc:4680:93a1, 2600:9000:201e:1a00:a:35dc:4680:93a1
• IPv4: 52.85.151.87, 52.85.151.94, 52.85.151.97, 52.85.151.124
• Trying 52.85.151.87:443...
• Connected to test-api.fecfile.fec.gov (52.85.151.87) port 443
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519 / RSASSA-PSS
• ALPN: server accepted h2
• Server certificate:
• subject: CN=test-api.fecfile.fec.gov
• start date: Jan 3 22:20:58 2025 GMT
• expire date: Apr 3 22:20:57 2025 GMT
• subjectAltName: host "test-api.fecfile.fec.gov" matched cert's "test-api.fecfile.fec.gov"
• issuer: C=US; O=Let's Encrypt; CN=R10
• SSL certificate verify ok.
• Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
• using HTTP/2
• [HTTP/2] [1] OPENED stream for https://test-api.fecfile.fec.gov/
• [HTTP/2] [1] [:method: GET]
• [HTTP/2] [1] [:scheme: https]
• [HTTP/2] [1] [:authority: test-api.fecfile.fec.gov]
• [HTTP/2] [1] [:path: /]
• [HTTP/2] [1] [user-agent: curl/8.5.0]
• [HTTP/2] [1] [accept: /]

GET / HTTP/2
Host: test-api.fecfile.fec.gov
User-Agent: curl/8.5.0
Accept: /

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  < HTTP/2 302
  < content-type: text/html; charset=utf-8
  < content-length: 0
  < date: Fri, 14 Feb 2025 00:19:06 GMT
  < x-frame-options: DENY
  < cache-control: no-cache, no-store
  < cross-origin-opener-policy: same-origin
  < location: /api/docs/
  < referrer-policy: same-origin
  < strict-transport-security: max-age=31536000
  < x-content-type-options: nosniff
  < x-vcap-request-id: f885333a-4971-4508-6a42-72ea64881d22
  < x-xss-protection: 1; mode=block
  < vary: Cookie
  < x-cache: Miss from cloudfront
  < via: 1.1 c34bd35d24f6df50307d1ac92d0f6110.cloudfront.net (CloudFront)
  < x-amz-cf-pop: IAD89-C3
  < x-amz-cf-id: pUlYWLUHQ4h1iKt-okAZTv-I_nJI3ie8LZ8esk4-zVW6DCBPxHnZtA==
  <
• Connection #0 to host test-api.fecfile.fec.gov left intact

Netscape HTTP Cookie File

https://curl.se/docs/http-cookies.html

This file was generated by libcurl! Edit at your own risk.{noformat}

Whereas it is set hitting [test-api.fecfile.fec.gov/api/docs/|http://test-api.fecfile.fec.gov/api/docs/]:

{noformat}$ curl -v -c - https://test-api.fecfile.fec.gov/api/docs/

• Host test-api.fecfile.fec.gov:443 was resolved.
• IPv6: 2600:9000:201e:f400:a:35dc:4680:93a1, 2600:9000:201e:a200:a:35dc:4680:93a1, 2600:9000:201e:cc00:a:35dc:4680:93a1, 2600:9000:201e:a600:a:35dc:4680:93a1, 2600:9000:201e:4c00:a:35dc:4680:93a1, 2600:9000:201e:ac00:a:35dc:4680:93a1, 2600:9000:201e:ae00:a:35dc:4680:93a1, 2600:9000:201e:3600:a:35dc:4680:93a1
• IPv4: 52.85.151.97, 52.85.151.124, 52.85.151.94, 52.85.151.87
• Trying 52.85.151.97:443...
• Connected to test-api.fecfile.fec.gov (52.85.151.97) port 443
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519 / RSASSA-PSS
• ALPN: server accepted h2
• Server certificate:
• subject: CN=test-api.fecfile.fec.gov
• start date: Jan 3 22:20:58 2025 GMT
• expire date: Apr 3 22:20:57 2025 GMT
• subjectAltName: host "test-api.fecfile.fec.gov" matched cert's "test-api.fecfile.fec.gov"
• issuer: C=US; O=Let's Encrypt; CN=R10
• SSL certificate verify ok.
• Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
• using HTTP/2
• [HTTP/2] [1] OPENED stream for https://test-api.fecfile.fec.gov/api/docs/
• [HTTP/2] [1] [:method: GET]
• [HTTP/2] [1] [:scheme: https]
• [HTTP/2] [1] [:authority: test-api.fecfile.fec.gov]
• [HTTP/2] [1] [:path: /api/docs/]
• [HTTP/2] [1] [user-agent: curl/8.5.0]
• [HTTP/2] [1] [accept: /]

GET /api/docs/ HTTP/2
Host: test-api.fecfile.fec.gov
User-Agent: curl/8.5.0
Accept: /

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  < HTTP/2 200
  < content-type: text/html; charset=utf-8
  < content-length: 1195
  < date: Fri, 14 Feb 2025 00:16:47 GMT
  < allow: GET, HEAD, OPTIONS
  < cache-control: no-cache, no-store
  < cross-origin-opener-policy: unsafe-none
  < referrer-policy: same-origin
• Added cookie csrftoken="0yKj9gTs4eW2am6I4c5ToSESMZsuwbpn" for domain fecfile.fec.gov, path /, expire 1770941807
  < set-cookie: csrftoken=0yKj9gTs4eW2am6I4c5ToSESMZsuwbpn; Domain=fecfile.fec.gov; expires=Fri, 13 Feb 2026 00:16:47 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
  < strict-transport-security: max-age=31536000
  < x-content-type-options: nosniff
  < x-vcap-request-id: 77b6f2d8-7439-49c4-55ad-05b1e7be172b
  < x-xss-protection: 1; mode=block
  < x-frame-options: DENY
  < vary: Accept-Encoding,Cookie
  < x-cache: Miss from cloudfront
  < via: 1.1 157ebd6865840045fc8b5ed1cce7e466.cloudfront.net (CloudFront)
  < x-amz-cf-pop: IAD89-C3
  < x-amz-cf-id: VnYsenuhF9wfAlGOIuD-LBuHcLy086zvgvM2MjvAWi_Nstgp0SE7sw==
• Connection #0 to host test-api.fecfile.fec.gov left intact

Netscape HTTP Cookie File

https://curl.se/docs/http-cookies.html

This file was generated by libcurl! Edit at your own risk.

.fecfile.fec.gov TRUE / TRUE 1770941807 csrftoken 0yKj9gTs4eW2am6I4c5ToSESMZsuwbpn{noformat}

[exalate-issue-sync]

Dan Fowlkes commented: Conclusion? I am leaning toward the belief that this is a false positive and that the tool is mistaken that it is still operating over HTTP when the csrf token cookie is set.