search

docusign / docusign-esign-java-client

The Official Docusign Java Client Library used to interact with the eSignature REST API. Send, sign, and approve documents using this client.
https://javadoc.io/doc/com.docusign/docusign-esign-java/latest/index.html
MIT License
105 stars 96 forks source link

ApiClient: oAuth Api setting HTTP Header "Cache-Control: no-store" #63

Closed psytester closed 5 years ago

psytester commented 6 years ago

According to RFC-6749 OAuth 2.0 and RFC-6819 OAuth 2.0 Security the oAuth client should explicitly set in client request HTTP headers "Cache-Control: no-store" and "Pragma: no-cache" The current ApiClient code results into "Cache-Control: no-cache" and "Pragma: no-cache" is used. We do not send "Cache-Control: no-store" to oAuth server. For sure, the client application can modify the apiClient content, but to support RFC compliance out of the box in api integration, the docusign client api should set internally the related HTTP header.

LarryKlugerDS commented 6 years ago

Hi,

Thank you for the report. I just read RFC 6819, section 4.6.6

I quote:

Clients and resource servers not using an OAuth HTTP authentication scheme (see Section 5.4.1) should take care to use Cache-Control headers to minimize the risk that authenticated content is not protected. Such clients should send a Cache-Control header containing the "no-store" option [RFC2616].

Since the DocuSign eSignature REST API does use the Authorization header, it appears that the Cache-Control header setting is not an issue during normal API transactions. Am I misunderstanding something here?

I agree that the API calls to the DocuSign Authentication Server itself should use the Cache-Control: no-store setting since those calls include secret information that should not be stored. I have filed internal bug report DCM-2242 for the Java SDK and others for the other SDKs.

psytester commented 6 years ago

Hello,

my concern was about the oAuth api part only. The esign api (for us the endpoint /restapi/v2/signature) is out of scope, since I don't know if this is a must have definition in your own esign application api.

You are right on that section, but my focus was more on the beginning of RFC 6819, section 4.6.6

4.6.6. Threat: Leak of Confidential Data in HTTP Proxies:

However, [RFC2616] relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers.

In detail: However, [RFC2616] relies on the Authorization[.....] Proxies and caches, in particular, may fail to adequately protect requests not using these headers.

mmallis87 commented 5 years ago

@psytester version 2.10.0-RC1 contains the security enhancement. Please give it a try. You can see the code change as part of #108 .