Skip to content

Discussion on owasp:api2:2023 (Broken Authentication) rules #548

@rartych

Description

@rartych

Should the following linting rules be used for CAMARA APIs:
Descriptions from https://apistylebook.stoplight.io/docs/owasp-top-10-2023

Errors

owasp:api2:2023-auth-insecure-schemes

There are many HTTP authorization schemes but some of them are now considered insecure, such as negotiating authentication using specifications like NTLM or OAuth v1.

owasp:api2:2023-jwt-best-practices

JSON Web Tokens RFC7519 is a compact, URL-safe, means of representing claims to be transferred between two parties. JWT can be enclosed in encrypted or signed tokens like JWS and JWE.

The JOSE IANA registry provides algorithms information.

RFC8725 describes common pitfalls in the JWx specifications and in their implementations, such as:

  • the ability to ignore algorithms, eg. {"alg": "none"};
  • using insecure algorithms like RSASSA-PKCS1-v1_5 eg. {"alg": "RS256"}.

An API using JWT should explicit in the description that the implementation conforms to RFC8725.

components:
securitySchemes:
JWTBearer:
type: http
scheme: bearer
bearerFormat: JWT
description: |-
A bearer token in the format of a JWS and conformato
to the specifications included in RFC8725.

owasp:api2:2023-no-api-keys-in-url

API Keys are are passed in headers, cookies or query parameters to access APIs Those keys can be eavesdropped, especially when they are passed in the URL as logging or history tools will keep track of them and potentially expose them.

owasp:api2:2023-no-credentials-in-url

URL parameters MUST NOT contain credentials such as API key, password, or secret. See RAC_GEN_004

owasp:api2:2023-no-http-basic

Basic authentication credentials transported over network are more susceptible to interception than other forms of authentication, and as they are not encrypted it means passwords and tokens are more easily leaked.
owasp:api2:2023-short-lived-access-tokens

Using short-lived access tokens is a good practice, and when using OAuth 2 this is done by using refresh tokens. If a malicious actor is able to get hold of an access token then rotation means that token might not work by the time they try to use it, or it could at least reduce how long they are able to perform malicious requests.

owasp:api2:2023-write-restricted

All write operations (POST, PUT, PATCH, DELETE) must be secured by at least one security scheme. Security schemes are defined in the securityScheme section then referenced in the security key at the global or operation levels.

Warnings

owasp:api2:2023-read-restricted

Read operations (GET, HEAD) should be secured by at least one security scheme. Security schemes are defined in the securityScheme section then referenced in the security key at the global or operation levels.
Read operations (GET, HEAD) should be secured by at least one security scheme. Security schemes are defined in the securityScheme section then referenced in the security key at the global or operation levels.

Discussion

As the default oas3-operation-security-defined rule is not fully compatible with OpenIdConnect.
It may be worth to use owasp:api2:2023-write-restricted and owasp:api2:2023-read-restricted - other rules are not relevant (not triggered in current CAMARA APIs)

Probably the CAMARA specific rule can be created to check if correct security scheme is defined:

components:
  securitySchemes:
    openId:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration 

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions