Sending digest authentication credentials as cleartext allowed
Issue ID: v3-global-securityscheme-http-digest-clear
Average severity: Minimal
Description
One or more global security schemes in the API allows to set security requirements that accept credentials for HTTP digest access authentication sent in cleartext over an unencrypted channel. Attackers can easily intercept API calls and retrieve the credentials. They can then use the credentials to make other API calls.
This is a potential risk, because the definition is in security schemes. However, it easily turns into an actual risk when the unsafe method is used in a security requirement.
For more details, see the OpenAPI Specification.
Example
The following is an example of how this type of risk could look in your API definition. The scheme digestAuth
defines that using HTTP digest access authentication is allowed. The server
object sets HTTP as the supported transportation protocol. This means that the API could accept an API call over an unencrypted HTTP connection, and expects it to have the credentials in the clear:
{
"servers": [
{
"url": "http://my.api.server.com/",
"description": "API server"
}
],
// ...
"components": {
"securitySchemes": {
"digestAuth": {
"type": "http",
"scheme": "digest"
}
}
}
}
Possible exploit scenario
Attackers can intercept the credentials simply by listening to the network traffic in a public WiFi network. They could also use a traffic logging tool on a smartphone, computer, or browser, or sniff the traffic in the network to get the credentials. HTTP digest access authentication has become obsolete and insecure, with the long lifetime of credentials providing extended opportunity for exploits.
Remediation
Set all server
objects to support HTTPS only so that all traffic is encrypted.
Use a more secure authentication method, like OAuth 2.0. It uses access tokens with limited lifetime and authorizations (the scopes) granted that the resource owner grants from an authorization server.
An API operation can be consumed only if the request includes an access token and the scopes of the token match the scopes that the API operation requires. Even if attackers successfully retrieved access tokens, they can only use the token on a subset of the API operation and for a limited time.
{
"servers": [
{
"url": "https://my.api.server.com/",
"description": "API server"
}
],
// ...
"components": {
"securitySchemes": {
"OAuth2": {
"type": "oauth2",
"flows": {
"authorizationCode": {
"scopes": {
"write": "modify objects in your account",
"read": "read objects in your account"
},
"authorizationUrl": "https://example.com/oauth/authorize",
"tokenUrl": "https://example.com/oauth/token"
}
}
}
}
},
// ...
"security": [
{
"OAuth2": [
"write",
"read"
]
}
]
}