💻
Application Security Cheat Sheet
  • Application Security Cheat Sheet
  • Android Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
      • Package Manager
    • Intent Vulnerabilities
      • Deep Linking Vulnerabilities
    • WebView Vulnerabilities
      • WebResourceResponse Vulnerabilities
      • WebSettings Vulnerabilities
  • CI/CD
    • Dependency
      • Dependency Confusion
      • Dependency Hijaking
      • Typosquatting
    • GitHub
      • GitHub Actions
      • Code owners
      • Dependabot
      • Redirect
      • Releases
  • Cloud
    • AWS
      • Amazon API Gateway
      • Amazon Cognito
      • Amazon S3
  • Container
    • Overview
      • Container Basics
      • Docker Engine
    • Escaping
      • CVE List
      • Exposed Docker Socket
      • Excessive Capabilities
      • Host Networking Driver
      • PID Namespace Sharing
      • Sensitive Mounts
    • Container Analysis Tools
  • Framework
    • Spring
      • Overview
      • Mass Assignment
      • Routing Abuse
      • SpEL Injection
      • Spring Boot Actuators
      • Spring Data Redis Insecure Deserialization
      • Spring View Manipulation
    • React
      • Overview
      • Security Issues
  • Linux
    • Overview
      • Philosophy
      • File
      • File Descriptor
      • I/O Redirection
      • Process
      • Inter Process Communication
      • Shell
      • Signals
      • Socket
      • User Space vs Kernel Space
    • Bash Tips
  • iOS Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
    • Getting Started
      • IPA Patching
      • Source Code Patching
      • Testing with Objection
  • Resources
    • Lists
      • Payloads
      • Wordlists
    • Researching
      • Web Application
      • Write-ups
    • Software
      • AWS Tools
      • Azure Tools
      • Component Analysis
      • Docker Analysis
      • Dynamic Analysis
      • Fuzzing
      • GCP Tools
      • Reverse Engineering
      • Static Analysis
      • Vulnerability Scanning
    • Training
      • Secure Development
  • Web Application
    • Abusing HTTP hop-by-hop Request Headers
    • Broken Authentication
      • Two-Factor Authentication Vulnerabilities
    • Command Injection
      • Argument Injection
    • Content Security Policy
    • Cookie Security
      • Cookie Bomb
      • Cookie Jar Overflow
      • Cookie Tossing
    • CORS Misconfiguration
    • File Upload Vulnerabilities
    • GraphQL Vulnerabilities
    • HTML Injection
      • base
      • iframe
      • link
      • meta
      • target attribute
    • HTTP Header Security
    • HTTP Request Smuggling
    • Improper Rate Limits
    • JavaScript Prototype Pollution
    • JSON Web Token Vulnerabilities
    • OAuth 2.0 Vulnerabilities
      • OpenID Connect Vulnerabilities
    • Race Condition
    • Server Side Request Forgery
      • Post Exploitation
    • SVG Abuse
    • Weak Random Generation
    • Web Cache Poisoning
Powered by GitBook
On this page
  • Overview
  • Code ownership takeover
  1. CI/CD
  2. GitHub

Code owners

PreviousGitHub ActionsNextDependabot

Last updated 2 years ago

Overview

Github allows you to define for individuals or teams that are responsible for code in a repository or . To do so, you should add the CODEOWNERS file to one of the following locations:

  • .github/

  • /

  • docs/

After which you can set up rules for protected branches and require mandatory approval from code owners.

References:

Code ownership takeover

The documentation for code owners that the CODEOWNERS file can be defined in /, docs/, or .github/ directory:

To use a CODEOWNERS file, create a new file called CODEOWNERS in the root, docs/, or .github/ directory of the repository, in the branch where you'd like to add the code owners.

However, what happens if a repository contains multiple CODEOWNERS files? Actually, among the allowed paths there is the following priority:

  • .github/

  • /

  • docs/

So, if Github finds CODEOWNERS file in .github/, it will ignore CODEOWNERS files in / and docs/. In other words, if CODEOWNERS file has been created in / or docs/, an attacker with write permissions is able to add CODEOWNERS file to .github/, takeover code ownership, and bypass branch protection rules.Now the attacker is the owner of the code of the entire repository and can approve any changes.

Suppose there is a repository where .github/ has separate owners who are responsible for changes to that directory and CODEOWNERS file is stored in /. In such case, the CODEOWNERS file may look like this:

* @owner-team
.github/ @dev-team

A member of the @dev-team team, or an attacker who gains access to the account of this member, can elevate their privileges in this repository using the next steps:

  1. Using a personal Github account or other compromised account fork the repository.

  2. Add .github/CODEOWNERS file with the following content:

    * @dev-team
  3. Create a PR to the target repo.

  4. Approve the PR (since an attacker has access to the account that is an code owner of the .github/, they can approve any changes within .github/).

  5. Merge changes.

  6. Now an attacker is a code owner for the whole repository and they are able to approve any changes, including those outside .github/.

code owners
Github Docs: About code owners
said