The “X-Vault-Token” header is exposed for requests that don't require it

[bsbontchev]

Issue: The status, init, seal, and unseal requests expose the “X-Vault-Token” header even though they don't require it. If the token value is empty the request is not made and no error is reported. Environment: curl 7.61.1, libvault-0.52.0, Vault v1.8.2

The empty token does not produce any request: Vault::Host host("127.0.0.1"); Vault::Port port("8220"); Vault::Config config = Vault::ConfigBuilder().withHost(host).withPort(port).withTlsEnabled(false).withDebug(true).build(); Vault::Token token(""); Vault::TokenStrategy auth(token); Vault::Client root_client(config, auth, httpErrorCallback, responseErrorCallback); Vault::Sys system(root_client); auto response = system.sealStatus(); if ( response ) { std::cout << "response : " << response.value() << std::endl; }

The non empty token exposes the token in the request: Vault::Host host("127.0.0.1"); Vault::Port port("8220"); Vault::Config config = Vault::ConfigBuilder().withHost(host).withPort(port).withTlsEnabled(false).withDebug(true).build(); Vault::Token token("dummy"); Vault::TokenStrategy auth(token); Vault::Client root_client(config, auth, httpErrorCallback, responseErrorCallback); Vault::Sys system(root_client); auto response = system.sealStatus(); if ( response ) { std::cout << "response : " << response.value() << std::endl; }

• Trying 127.0.0.1...
• TCP_NODELAY set
• Connected to 127.0.0.1 (127.0.0.1) port 8222 (#0)

  GET /v1/sys/seal-status HTTP/1.1 Host: 127.0.0.1:8222 Accept: / X-Vault-Token: dummy Content-Type: application/json

< HTTP/1.1 200 OK < Cache-Control: no-store < Content-Type: application/json < Date: Thu, 13 Apr 2023 12:49:43 GMT < Content-Length: 167 <

• Connection #0 to host 127.0.0.1 left intact response : {"type":"shamir","initialized":true,"sealed":true,"t":2,"n":3,"progress":0,"nonce":"","version":"1.8.2","migration":false,"recovery_seal":false,"storage_type":"file"}

The vault app status, init, seal and unseal commands don’t require/expose the “X-Vault-Token” header.

vault status -output-curl-string curl -H "X-Vault-Request: true" -H "X-Vault-Namespace: " https://127.0.0.1:8200/v1/sys/seal-status

vault operator init -output-curl-string curl -X PUT -H "X-Vault-Request: true" -d '{"secret_shares":5,"secret_threshold":3,"stored_shares":0,"pgp_keys":null,"recovery_shares":5,"recovery_threshold":3,"recovery_pgp_keys":null,"root_token_pgp_key":""}' https://127.0.0.1:8200/v1/sys/init

vault operator seal -output-curl-string curl -X PUT -H "X-Vault-Request: true" https://127.0.0.1:8200/v1/sys/seal

vault operator unseal -output-curl-string dummy curl -X PUT -H "X-Vault-Request: true" -d '{"key":"dummy","reset":false,"migrate":false}' https://127.0.0.1:8200/v1/sys/unseal

[abedra]

A couple notes after looking through the docs

• https://developer.hashicorp.com/vault/api-docs/system/seal-status - Agreed, I'll remove the auth
• https://developer.hashicorp.com/vault/api-docs/system/init - There doesn't seem to be a PUT request in the documentation, but It would make sense not to auth given there would be no tokens available.
• https://developer.hashicorp.com/vault/api-docs/system/seal - This is an authenticated endpoint requiring root permissions. I think this still needs to send the token
• https://developer.hashicorp.com/vault/api-docs/system/unseal - Agreed, I'll remove the auth

[bsbontchev]

You are correct. The docs https://developer.hashicorp.com/vault/api-docs/system/seal do show it as an authenticated point. The init initializes the vault so no tokens exist prior to this.

[abedra]

This should all be sorted in https://github.com/abedra/libvault/releases/tag/0.55.0. Thank you for reporting