nginx config with proxy_cookie_path

[jon.t...@gmail.com]

Hi folks

I am trying to remove an issue whereby my website is failing a vulnerability check due to 

SSL/TLS: Missing `secure` Cookie Attribute

Missing `httpOnly` Cookie Attribute

currently in an ever decreasing spiral trying fixes in both tomcat and nginx.....

suspect I am badly reinventing a wheel someone already has.

Does anyone have an nginx config with a  proxy_cookie_path in it?

regards

Jon

[John Flavin]

Can you give us more information on the vulnerability check that is failing?

Is this an automated test? Is it available for us to run it ourselves to reproduce, or is it something built in-house?

Are the particular rules in the test (including but not limited to the failing rules) mandated by someone? If so, who? Do you have any flexibility in which rules to apply? 

John Flavin

Backend Team Lead

johnf...@flywheel.io

He/Him

flywheel.io

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/88b74ed9-ac14-4bdd-8e71-f9dd693cbfbfn%40googlegroups.com.

[jon.t...@gmail.com]

I was only telling half the story. and I am not suggesting anything wrong with xnat :-))))
the most likley problem is I dont understand nginx properly....and am overlooking the obvious.

My setup is xnat + nginx as the reverse proxy.

All our live instances are in house and thus not seen by the outside world.

But before our in  security team will let me make one externally visible they want me to follow up a few things their vulnerabilty scanner finds.
which are:

SSL/TLS: Missing `secure` Cookie Attribute

and
The application is missing the 'httpOnly' cookie attribute

I can replicate/test against this using
https://www.greenbone.net/en/ with a copy of Kali linux.

( https://www.kali.org/tools/gvm/ )  

Reading around the web suggests I should be able to set directives inside nginx, such as this
 proxy_cookie_path / "/; HTTPOnly; Secure";

but when I do it breaks the xnat session timeout. I login and the session immediately expires.

right now I am sitting with the firefox developer tools trying to see exactly what is happening.

hoping I might have a eureka moment shortly.....

But if anyone out there has an good working xnat + nginx and they are willing to show me the relevent bits of config files of I'd appreciate it 

(I belive thats bits of tomcat server.xml  and nginx config )

I had found this link http://imaging-genetics.camh.ca/guides/xnat-nginx/

 but so far not helped...

Jon

 
the report from the vulnerability scanner is below..... and will probably contain some obvious clue Ive missed!


==============================================================
Summary
a server with SSL/TLS is prone to an information disclosure vulnerability.
Detection Result

==============================================================

The cookies:

Set-Cookie: JSESSIONID=***replaced***; Path=/; HttpOnly
Set-Cookie: SESSION_EXPIRATION_TIME="1665579682505,900000"; Version=***replaced***; Path=/

are missing the "secure" attribute.

Insight
The flaw is due to cookie is not using 'secure' attribute, which
  allows cookie to be passed to the server by the client over non-secure channels (http) and allows attacker
  to conduct session hijacking attacks.
Detection Method
Details:
    
SSL/TLS: Missing `secure` Cookie Attribute OID: 1.3.6.1.4.1.25623.1.0.902661
Version used:
    
2022-02-15T13:40:32Z
Affected Software/OS
Server with SSL/TLS.
Solution
Solution Type:
Mitigation
Set the 'secure' attribute for any cookies that are sent over a SSL/TLS connection.
References
Other
    
https://www.owasp.org/index.php/SecureFlaghttp://www.ietf.org/rfc/rfc2965.txthttps://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)


==============================================================
Summary
The application is missing the 'httpOnly' cookie attribute
Detection Result
==============================================================
The cookies:

Set-Cookie: SESSION_EXPIRATION_TIME="1665587461869,900000"; Version=***replaced***; Path=/

are missing the "httpOnly" attribute.

Insight
The flaw is due to a cookie is not using the 'httpOnly' attribute. This
  allows a cookie to be accessed by JavaScript which could lead to session hijacking attacks.
Detection Method
Check all cookies sent by the application for a missing 'httpOnly' attribute
Details:
    
Missing `httpOnly` Cookie Attribute OID: 1.3.6.1.4.1.25623.1.0.105925
Version used:
    
2020-08-24T15:18:35Z
Affected Software/OS
Application with session handling in cookies.
Solution
Solution Type:
Mitigation
Set the 'httpOnly' attribute for any session cookie. 

[John Flavin]

I think I can explain part of this. Specifically the missing httpOnly attribute on the SESSION_EXPIRATION_TIME cookie.

The vulnerability scan says

The flaw is due to a cookie is not using the 'httpOnly' attribute. This allows a cookie to be accessed by JavaScript...

What the scanner says is a "flaw" is a behavior our code relies on. We want that cookie to be accessed by JavaScript! The front-end JavaScript reads the SESSION_EXPIRATION_TIME cookie to, among other things, alert you when your session has expired. If it can't read that cookie, it ends your session.

Which is exactly what you observed when you tried setting it yourself.

...it breaks the xnat session timeout. I login and the session immediately expires.

I'm afraid that, for the time being, you may not be able to set the httpOnly attribute on that cookie without breaking things. (But it's possible other people see something that I don't and could chime in.)

The other attribute, secure, could possibly be set without breaking anything. Try just that one and see what happens.

John Flavin

Backend Team Lead

johnf...@flywheel.io

He/Him

flywheel.io

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/7df355cc-b38c-436b-9841-b98a0deef72dn%40googlegroups.com.

[jon.t...@gmail.com]

So a resolution, and largely a non problem..... I think.

Thanks to John noting that the apprent "flaw" is something xnat (and indeed any javascript wanting to read a cookie) needs to do.

(thats the hhtponly flag on the cookie) so Ive convinced our security  that their reporting while accurate 

it is something that is known and behaving as intended for the application.

To remove the reporting of cookies are missing the "secure" attribute.

this line 

proxy_cookie_path / "/; Secure";

in nginx seems to work and doesnt seem to have broken xnat (that we've noticed thus far).

regards

Jon