05. Secure Coding Principles

OWASP Top 10 (Class)

1. Broken Access Control:

• Users can act outside their intended permissions
• Causes:
  • Not following principle of last privilege
  • Lack of access control on some endpoints
  • Account manipulation: manipulating URLs, cookies, unique IDs
  • CORS misconfiguration
• Countermeasures:
  • Deny by default
  • Only allow resource owners, not all users, to CRUD
  • Re-use authentication systems (e.g. middleware)
  • Follow standards (e.g. JWT)
• Example:
  • MV720 GPS tracker: unsecured HTTP endpoint

2. Cryptographic failure:

• Sensitive data exposed due to weak or non-existent cryptographic algorithms
• Causes
  • Plain-text communication
  • Old/insecure algorithms
  • Hardcoded passwords
  • Insufficient randomness
• Countermeasures
  • Store only required data
  • Don’t cache sensitive data
  • Key rotation, proper IV generation etc.
• Example:
  • Solana Slope wallet: seed phrases sent in plaintext to central server

3. Injection attack:

• Executing user-provided code through an app to another system
• Most frequent: SQL Injection
• Causes:
  • Unsanitized user input
  • Dynamic queries with no content escaping
• Countermeasures:
  • Prepared statements, parameterized queries
  • Escape user input
• Example:
  • SonicWall (~500K customers): SQL injection issue

4. Insecure Design

• Some service with insecurities caused by its design and architecture, not the implementation

5. Security Misconfiguration:

• Very broad: security not set up, set up poorly, or misconfigured
• Causes:
  • Unnecessary features enabled:
    • Ports, services accounts
    • Default/unused applications may have vulnerabilities, be outdated
    • Revealing too much information through logs/error messages
  • Poor coding practices, default passwords, forgetting to re-enable firewall after testing
• Countermeasures:
  • Update configuration policies regularly
  • Minimize attack surface
  • Automatic configuration deployment (e.g. containers): make redeployment easy
• Example:
  • Jira: visibility of new projects was set to public by default? Adversary that link had access to all data in the project?

6. Vulnerable Components

• Part of system/application which extends the functionality
• Causes:
  • The component may be unsupported, out-of-date, or otherwise vulnerable
  • An attacker may be able to exploit that vulnerability to attack other systems
• Countermeasures:
  • Remove unused dependencies
  • Check they are being maintained
  • Keep a centralized list of dependencies and have a process in place to maintain it
  • Obtain dependencies from trusted sources
  • Don’t broadcast your dependencies

7. Authentication Failure

• Bad handling of user identity, authentication, session management
• Causes:
  • Brute-force attacks, credential stuffing
  • Default/well-known passwords
  • No/bad 2FA
  • Mishandling session identifiers (e.g. session ID in URL, re-use of identifiers after login)
  • ‘Forgot password’ flaws
  • Weak password storage
• Countermeasures:
  • Good 2FA
  • Secure admin credentials, not default
  • Check password against requirements, bad password lists
• Example:
  • CVE-2022-26138: Atlassian Confluence contains account with hard-coded user (disabledsystemuser) and password defined in plaintext config file
  • UC library room booking: HTTP

8. Security Logging/Monitoring Failures

• Insufficient logging
• Exposure of sensitive information in log files
• Causes:
  • Relevant information not logged
  • Logs not examined
  • Logs not backed up in case of server failure or breach
  • Logging systems not tested
  • Logging levels not used appropriately, exposing sensitive data
• Countermeasures:
  • Ensure logs include sufficient context (and are encoded correctly to prevent injection)
  • Ensure logs are in more than on place
  • Regular system monitoring
• Examples
  • CodeFusion 8: failed authentication attempts not logged; brute force attacks possible
  • NetProxy 4.03: did not log requests that did not have ‘http://’ in the URL

9. Server-side request forgery

• Application reads data from a URL; attacker can supply their own credential to their own URL or an internal path (e.g. to file containing credentials)
• Causes:
  • Trusting user credentials
  • Not following principle of least privilege
• Countermeasures:
  • Use allowlists for IP addresses, hosts that the application should be able to access
  • Block requests to private IPs
  • Verify response bodies
  • Block non-HTTP/HTTPS protocols
• Example:
  • UC Scrumboard: can specify GitLab URL. Server checks if they get a response, and if they get a valid Git response
    • If you pass in localhost:$port, attacker can iterate through ports to determine what ports are in use

Unsafe Constructs

See OWASP Secure Coding Practices

TOCTOU Race

When there is a time lapse between time-of-check to time-of-use:

• Two elements (e.g. processes, threads) concurrently making use of the same shared resource
• System interruptions can allow an adversary to substitute files
  • May often be exploited with temporary files, especially those with a known/predictable path
  • Example:
    • Process checks if user can access the file
    • Attacker replaces file with a symlink/hardlink (e.g. to /etc/passwd)
    • Process allows user to read restricted file
  • Countermeasures:
    • Use file descriptors instead (i.e. open once)
    • Span child processes with restricted permissions
    • Disallow creation of files by root (e.g. C compilation)
      • Lots of temporary files with well-known file paths?
      • If process reuses existing files instead of re-creating, attacker could inject malicious code?

Overflow Issues (Mostly C/C++)

This may cause the system may crash or read garbage data. However, an attacker may be able to exploit this.

Weak type safety: C will silently convert integers by keeping the least significant bits. After overflow of a signed integer, the value will be the maximum negative number.

Pointer arithmetic:

• C uses pointer + offset
• Array element size defines the step in bytes, with index for the offset
• No bounds-checks on array accesses by default
• If index is user-controlled and not sanitized, it may allow an attacker to read/write to arbitrary memory

Buffer overflow and NOP slide:

• For each function call, the stack contains function arguments, local variables, return address
• Buffer overflow of local variables may allow attacker to overwrite the return address, allowing them to jump to any address
• No-operation (NOP) slide:
  • Hard to predict where exactly the attacker-controlled payload is
  • Fill memory before the payload with NOPs: processor will simply go through the NOP instructions until it gets to the payload
  • The NOP sled means that the attacker does not need to know the exact memory address of the payload

Coding practices:

• Type-safety, static code analysis:
  • Uses languages with type-safe construct/libraries where possible
  • Bounds-checking e.g. overflow flags, unchecked memory overwrites
  • Non-executable stacks or heaps (although it prevents just-in-time interpretation/execution)
  • OS-level protection: address space layout randomization (ASLR)
• Least privilege, zero-trust knowledge:
  • Authorized access by default: public access should be the exception
  • Use securely-generated tokens, HTTP-only flags in cookies (to prevent client-side JS (e.g. malicious extensions) from reading it)
  • Treat other components with care, segment internal networks