Cookie still active even after logout

Security
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
OpenSearch: v 2.17.1
Dashboard: v.2.17.1

Describe the issue:
One of the finding during our pentest for OpenSearch Dashboard is that the cookie is still active even after the user logouts. This could be used for session hijacking and has potential security risk.

Scenario:

  • User logs in to dashboard
  • Copy a request with the cookie (using browser developer tools and Copy as curl)
  • User logs out
  • User redirected to login page and browser expects user to login
  • Run the copied curl command (which includes the cookie) in a terminal

Expectation:

  • Not authorized response since user logged out

Actual:

  • Got a valid response as if user is still logged in

Basically, after logout, the response clears the cookie and browser works as expected since the cookie is not there anymore. But apparently the user session is still persisted in the backend and treats the cookie valid even after logout. Is this behavior expected?

And of course the cookie becomes invalid when the session expires.

Configuration:
This can be reproduced with the latest docker images. I used the sample docker compose provided by OpenSearch.

No changes made to the configuration except setting up password for the cluster. The sample uses basic auth.

For context, the actual pentest is done in a different environment which has OIDC auth type. But to eliminate other possibilities we decided to start with a vanilla setup and we are able to reproduce the issue.

Relevant Logs or Screenshots:

Copying the request using copy as curl

image
image1920×1962 157 KB

2

Hi @srid00,

Could you please share your opensearch_dashboards.yml, have you tried setting opensearch_security.session.keepalive: false

best,
mj

3

Hi @Mantas ,

Thanks for the reply. I tried opensearch_security.session.keepalive: false but it didn’t do the trick. To be honest I am not even sure if this setting is picked up since I still see keepalive timeout as 120 in response. I would expect it to be 0.

Keep alive timeout in response:

< HTTP/1.1 200 OK
< warning:
< content-type: application/json; charset=utf-8
< osd-name: c51b7cd52677
< cache-control: private, no-cache, no-store, must-revalidate
< content-length: 387
< Date: Mon, 14 Oct 2024 16:08:03 GMT
< Connection: keep-alive
< Keep-Alive: timeout=120
<
* Connection #0 to host localhost left intact

opensearch_dashboards.yml

---
# Copyright OpenSearch Contributors
# SPDX-License-Identifier: Apache-2.0
# Description:
# Default configuration for OpenSearch Dashboards

opensearch.hosts: [https://localhost:9200]
opensearch.username: <redacted>
opensearch.password: <redacted>
opensearch.requestHeadersWhitelist: [authorization, securitytenant]

opensearch.ssl.verificationMode: none # if not using HTTPS

opensearch_security.auth.type: basicauth
opensearch_security.auth.anonymous_auth_enabled: false
opensearch_security.cookie.secure: false # set to true when using HTTPS
opensearch_security.cookie.ttl: 3600000
opensearch_security.session.ttl: 3600000
opensearch_security.session.keepalive: false
opensearch_security.multitenancy.enabled: false
opensearch_security.readonly_mode.roles: [kibana_read_only]

server.host: '0.0.0.0'
4

hi @srid00, have you rebooted your OSD after updating opensearch_dashboards.yml ?

Best,
mj

5

Yeah, the setup is docker based. So yeah, I restarted the docker containers. I also verified if the configuration file is updated. It did pickup the other settings which I tried though.

6

Just to reconfirm, I tried it again. It didn’t work. I did change the cookie and session ttl values to 60 seconds and those changes are picked up. After 60 seconds the cookie expires and so does the session.

Any other suggestions?

opensearch_security.cookie.ttl: 60000
opensearch_security.session.ttl: 60000
7

I did some further search and found out I am not the first to report such issue. And there is an open bug related to keepalive setting not working.

2 Likes
8

@Mantas @kris do you know how to proceed. This is blocking us from using OpenSearch for one of our customer.

9

@scrawfor - would you be able to take a look at this one? Is it related to the open bug @srid00 mentions?

10

any update?