Dangerous Functions Reference

Purpose

Provide comprehensive knowledge of security-sensitive functions (sinks) across programming languages for whitebox penetration testing. These functions are common targets during code review because improper use leads to critical vulnerabilities.

When to Use

Activate this skill during:

• Code review phase of whitebox security review
• Searching for potential vulnerability entry points
• Building grep patterns for sink identification
• Understanding language-specific security risks

Core Concepts

Sources vs Sinks

Sources: Entry points where user input enters the application

• HTTP parameters, headers, cookies
• File uploads, database reads
• Environment variables, command-line arguments

Sinks: Functions where malicious input causes damage

• Command execution, SQL queries
• File operations, deserialization
• Code evaluation, template rendering

Risk Categories

Methodology

Step 1: Identify Application Language

Determine the primary language(s) used:

• Check file extensions (.php, .java, .py, .js, .cs, .go, .rb)
• Review package managers (composer.json, pom.xml, requirements.txt, package.json)
• Check framework indicators

Step 2: Load Language-Specific Reference

Consult the appropriate reference file for comprehensive sink lists:

• references/php-sinks.md for PHP applications
• references/java-sinks.md for Java applications
• references/python-sinks.md for Python applications
• references/javascript-sinks.md for Node.js/JavaScript
• references/dotnet-sinks.md for .NET/C# applications
• references/go-ruby-sinks.md for Go and Ruby
• references/rust-sinks.md for Rust applications
• references/kotlin-sinks.md for Kotlin/Android applications (preview -- not in supported language list)
• references/swift-sinks.md for Swift/iOS applications (preview -- not in supported language list)
• references/solidity-sinks.md for Solidity smart contracts

Step 3: Search for Sinks

Use Grep tool to search for dangerous functions:

• Search one category at a time (command, code, SQL, file, etc.)
• Use case-insensitive search for better coverage
• Include all relevant file extensions

Step 4: Catalog Findings

For each identified sink, document:

• File path and line number
• Function name and context
• Input sources (if visible)
• Initial risk assessment

Step 5: Prioritize for Testing

Rank findings using this framework:

Prioritization Framework

When reviewing identified sinks, consider:

1. Input Proximity: How close is user input to the sink?
2. Authentication: Does exploitation require authentication?
3. Privilege Level: What access level is needed?
4. Impact: What can an attacker achieve?
5. Exploitability: Are there filters or sanitization?

Additional Resources

Reference Files

For comprehensive function lists by language, consult:

• references/php-sinks.md - PHP dangerous functions with grep patterns
• references/java-sinks.md - Java dangerous functions with grep patterns
• references/python-sinks.md - Python dangerous functions with grep patterns
• references/javascript-sinks.md - JavaScript/Node.js dangerous functions
• references/dotnet-sinks.md - .NET/C# dangerous functions
• references/go-ruby-sinks.md - Go and Ruby dangerous functions
• references/rust-sinks.md - Rust dangerous functions (unsafe, FFI, etc.)
• references/kotlin-sinks.md - Kotlin/Android dangerous functions (preview -- not in supported language list)
• references/swift-sinks.md - Swift/iOS dangerous functions (preview -- not in supported language list)
• references/solidity-sinks.md - Solidity smart contract sinks (reentrancy, access control, flash loans)

Integration with Other Skills

• Use vuln-patterns skill for exploitation techniques per vulnerability type
• Use data-flow-tracing skill to trace input from sources to identified sinks
• Use exploit-techniques skill to develop PoC for confirmed vulnerabilities