Cookies without secure and HTTP flag set

Questions
1

Hi,

I used OKTA login for my Angular Application. When we sent the application for penetration testing following issue was raised.
Issue 1:
Cookies were identified without the HTTPOnly flag set, potentially allowing the cookies to be accessed by client-side scripts.

Technical Details
The following cookies were set without the HTTPOnly flag:

ADRUM_BT1
ADRUM_BTa
DT
JSESSIONID
proximity_14b727894adaba3d6f9e90c4fa86cf430
proximity_2ac00f0ba5abcfa18b09c643586c3d4bc
proximity_940ber3ce534851dba7d7aaeedb3e959
t

Recommendation
HTTPOnly header is set on all HTTP cookies. It should be noted that there may be legitimate client-site scripts within the application that read or write the cookie’s value. If this is the case, then it may not be possible to enable this flag.

Issue2:
Session cookies found without the Secure cookie flag set

Technical Details
The following cookies were set without the secure flag:

ADRUM_BTX
ADRUM_BTY
JSESSIONID
t

Recommendation
Reviewing all application cookies and setting the Secure attribute on all.

PS: All these cookies are generated by OKTA library can you please fix this.

2

Hey @Prudhvi!

I passed this on to our security team, and this was the response:

JSESSIONID is not a session cookie for Okta and can be ignored. There is no risk posed by this cookie.

The T cookie is used for UI themes, it has minimal security implications but will be remediated in the future.

Cookies prefixed with ADRUM are AppDynamics server-side agent cookies that do not have HttpOnly set by design. AppDynamics provides Okta with performance data that helps to troubleshoot customer issues and ensure Okta meets our availability SLA. AppDynamics does not store or process PII and these cookies are not related to the Okta session. More information is here: https://docs.appdynamics.com/display/PRO43/Correlate+Business+Transactions+for+Browser+RUM

Okta Sessions are managed by the SID cookie which has both HTTPOnly and Secure attributes enabled.

Also, in the future, I’d encourage you to attempt to disclose potential issues like this responsibly. You can see Okta policy here. The Apache Foundation also has a great write up too (geared for Apache projects, but still lots of great info)

3

It looks like

  1. The “t” cookie has not been remediated

  2. A cookie “oktaStateToken” really should have those two flags set

  3. A cookie “DT” which is there too, goes unexplaned.

1 Like
4

I understand by now that DT is the device token, which keeps track of MFA having been provided, so it seems that one also definitely deserves both flags.

5

Hi there. Anything new to this? It is is unsecure and JavaScrpt accessible. DT cookie should be definitly reviewed. One of the largest Authentication services as Okta and has such a basic security vulnerability without any real reaction for two years? Please comment.

6

Hi,
@bdemers this dev forum post has been mentioned in the Okta Help Center - Okta Help Center (Lightning)

It seems that there are a few of us trying to understand how to configure okta cookies so that they are considered secure by PEN testing.

In my case, the cookies in question are:

  • okta-oauth-state
  • okta-oauth-nonce
  • okta-oauth-redirect-params
  • oktaStateToken
    For each of these cookies, the PEN test suggested that they should be set to HttpOnly, and that SameSite should be set to Lax.

I was able to set SameSite to Lax for the okta-oauth-* cookies by setting that value in the configuration passed to OktaAuth (from the @okta/okta-auth-js library), however, I don’t see a way to set that for oktaStateToken.
I also have yet to find any way to configure the HttpOnly value.

Any help would be much appreciated.

Thanks,
Jaimie

7

Hi @jaimie.whiteside!

Setting cookies to HttpOnly would prevent JavaScript from reading the value. If you are building a SPA application, the JS must have access to these values (as that is where the auth flow starts)

If this is a requirement for your application you may need to move your authentication to a backend (recommended when possible), which would allow for the use of HttpOnly cookies and sessions as needed.

Can you tell us a little more about your PEN tool? Was it a generic scan of your application or a specific requirement?

8

Hi,
Thanks for getting back to me.
You are correct that we are building an SPA application, so the information about setting HttpOnly preventing Javascript reading the value is very useful.
The PEN test was executed by a company outside my org, so I can’t say for sure what tools were used.
Reading the report findings, I think it was more of a generic scan, afaik there were no specific requirements from our security team.
Thanks,
Jaimie