swagger-api / swagger-api/swagger-client

Double Cookie based Authentication leads to wrong cookie serialisation

Open
#2,358 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
2.7k
Forks
765
Avg merge
1d 1h
Merged PRs (30d)
6

Description

Q&A
  • OS: Windows
  • Environment: Chrome 96
  • Method of installation: online swagger editor
  • Swagger-Client version: 4.1.0
  • Swagger/OpenAPI version: OpenAPI 3.0.3
Content & configuration

Swagger/OpenAPI definition:

openapi: 3.0.3
info:
  title: example
  version: 0.1.0
paths:
  /sample:
    post:
      security:
        - Session_ID: []
        - Correlation_ID: []
      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                type: boolean
components:
  securitySchemes:
    Session_ID:
      type: apiKey
      in: cookie
      name: ssid
    Correlation_ID:
      type: apiKey
      in: cookie
      name: correlation_id
Describe the bug you're encountering

The API I'm documenting is session based
Sessions that can be anonymous or not

Those sessions rely on :

  • a session id in a cookie
  • a correlation id in another cookie

By defining 2 apiKey security schemes and listing them both for the target route
When I click execute, the generated curl request shows an invalid Cookie header

To reproduce...

Steps to reproduce the behavior:

  1. Click on Authorize
  2. set a value for the session id cookie (ex: foo)
  3. set a value for the correlation id cookie (ex: bar)
  4. close the authorization popup
  5. tryout & execute the /sample request

The generated Cookie header is
Cookie: ssid=foo&correlation_id=bar

Expected behavior

The & is an invalid cookie separator.
The cookie separator should be ;
Cookie: ssid=foo; correlation_id=bar

Screenshots

image

Additional context or thoughts

Several thougths:

  1. the session id and the correlation id are meant to be returned by a previous request... wondering if the securityShemes are the best way to handle such use case vs using operationId and links. But targeting two seperate response cookies is not obvious. the runtimeExpression spec doesn't support cookie sources and won't help to distinguish 2 Set-Cookie headers based on the cookie names
  2. one of the reasons why there is a correlation id is because the session id is regularly updated (based on the session id renewal timeout recommended by OWasp). The authorize form will keep the initial session id value. It would be nice to be able to define that cookie as automatically renewable so it get changed when a response gives that cookie a new value. (but that should need an update to the open api spec)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue in the Swagger Editor using the supplied OpenAPI definition and authorization steps, then trace how the generated curl request serializes multiple cookie-based apiKey schemes. Done means the Cookie header uses ; between cookies instead of &, with a regression test covering both cookie values.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, openapi
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.