Skip to main content

Sensitive information in source code

Description​

The source code repository contains sensitive information such as usernames, passwords, email addresses and IP addresses, among others. Alternatively, while values may be password=123 o aws.secret_key=test, they reveal the bad practice of storing sensitive information in the repository with no encryption, and sooner or later they can be replaced for real sensitive values.

Impact​

Get sensitive information or private secrets.

Recommendation​

  • Delete all hardcoded sensitive information.
  • Change all affected access credentials.
  • Remove sensitive information from git logs.
  • Load sensitive data from safe sources such as, key vault services, configuration files properly encrypted or administrative environment variables.

Threat​

Anonymous attacker with access to the source-code from the Internet.

Expected Remediation Time​

⌚ 30 minutes.

Score​

Default score using CVSS 3.1. It may change depending on the context of the vulnerability.

Base​

  • Attack vector: N
  • Attack complexity: H
  • Privileges required: N
  • User interaction: N
  • Scope: U
  • Confidentiality: L
  • Integrity: N
  • Availability: N

Temporal​

  • Exploit code madurity: H
  • Remediation level: U
  • Report confidence: C

Result​

  • Vector string: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:H/RL:U/RC:C
  • Score:
    • Base: 3.7
    • Temporal: 3.7
  • Severity:
    • Base: Low
    • Temporal: Low

Code Examples​

Compliant code​

Sensitive information should be handled by some form of secrets encryption service

azon.aws.accesskey = ${aws_access_key}
sonar.password     = ENC(something-base64-encoded-but-encrypted)

Non compliant code​

Sensitive access keys and passwords can be seen as plain text in the source code

azon.aws.accesskey = AKIA0000000000000000
sonar.password     = 123

An example of an insecure Dockerfile configuration

version: "3.9"  # optional since v1.27.0
services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/code
      - logvolume01:/var/log
    links:
      - redis
    environment:
    - DEBUG=${VAR}
    - API_KEY='123'
    - API_KEY
    - API_KEY_CLOUD_CLIENT_SECRET=${APIKEY_CLIENT_SECRET}
  redis:
    image: redis
    environment:
    - API_NAME=name1
  db:
    image: "postgres:${POSTGRES_VERSION}"
    environment:
    - API_PASSWORD=pass
volumes:
  logvolume01: {}

Details​

Why​

When secret credentials are compromised, we always generate a vulnerability report either the credentials are mocks, or are functional only in specific scenarios such as local environments. The risk of this scenario is usually considered in the severity tab. For local environment credentials the risk is low but not zero.

Hence to solve this vulnerabilty we recommend to remove the credentials from the source code, change the compromised credentials and ideally remove the credentials from the git log. In some cases the last recommendation cannot be applied to avoid traceability issues. If that's the case, in addition to removing the credentials from the code, we require a customer confirmation that the credentials were changed to close the vulnerability.

Requirements​

free trial

Search for vulnerabilities in your apps for free with our automated security testing! Start your 21-day free trial and discover the benefits of our Continuous Hacking Machine Plan. If you prefer a full service that includes the expertise of our ethical hackers, don't hesitate to contact us for our Continuous Hacking Squad Plan.