Auditing Php Applications

Auditing PHP Applications

This is the PHP-specific layer on top of auditing-code-for-vulnerabilities. Take the methodology from that skill — context → attack surface → bug-class hunt → variant analysis → the four-question verification gate — and apply the PHP sink catalog below to it. This skill exists because PHP has footguns no language-agnostic methodology carries: features that turn a file read into remote code execution, and comparison rules that turn == into an auth bypass.

The collection deliberately has no per-language audit skills except this one. PHP earns the exception because it dominates the legacy-web and WordPress/Magento space where critical bugs actually live, and because its dynamic features fail in ways a reviewer must be primed for specifically.

When to Use

• Reviewing a PHP codebase or plugin for exploitable vulnerabilities
• Auditing a WordPress, Magento, Joomla, or Laravel application's source
• Tracing a suspected RCE, LFI, SQLi, or object-injection path in PHP
• Deciding whether a unserialize, include, or == on user input is exploitable

When NOT to Use

• General audit methodology, or a non-PHP language — use auditing-code-for-vulnerabilities; this skill assumes it
• Finding a planted webshell or backdoor rather than a vulnerability — use hunting-web-backdoors
• Building the deserialization exploit chain once you have the sink — use exploiting-deserialization
• Black-box testing a running app — use testing-web-applications
• Reviewing only the diff of a change — use reviewing-code-changes

Sinks by Bug Class

Trace user input (superglobals, headers, uploaded filenames, DB values that were once user input) to each of these. A sink is only a bug when a source reaches it.

Remote code execution

• Direct eval sinks: eval, assert (string arg, pre-8.0), preg_replace with /e (pre-7.0), create_function (pre-8.0), mb_ereg_replace/mb_eregi_replace with the e option.
• Command execution: system, exec, passthru, shell_exec, backticks, proc_open, popen, pcntl_exec. Watch escapeshellarg vs escapeshellcmd misuse — escapeshellcmd does not prevent argument injection.
• Dynamic dispatch: $func() where $func derives from input, call_user_func/call_user_func_array, array_map/usort/ preg_replace_callback with a user-influenced callback.

Object injection (the PHP-defining bug)

• unserialize() on any user-controlled data is object injection. Exploitation is a POP chain: existing classes with __wakeup, __destruct, __toString, or __call magic methods that do something dangerous when the object is materialized. The vulnerable file often contains no dangerous code at all — the gadget lives in a framework or dependency.
• phar:// is unserialize in disguise — but version-gated. On PHP before 8.0, any file operation (file_exists, fopen, include, getimagesize, …) on a phar:// path automatically deserializes the Phar's metadata, so a path-traversal or LFI that points a file function at an uploaded .phar (or any file carrying Phar metadata) is object injection with no unserialize call in sight. PHP 8.0 removed that automatic unserialize — only explicit Phar::getMetadata() deserializes now. So the bug is critical on the huge installed base of PHP 7.x and a non-issue on 8.x unless the code calls getMetadata() itself. Check the runtime version before ruling it in or out.
• Prefer json_decode in remediation; flag every unserialize on non-trusted data regardless of an obvious gadget — the gadget may arrive with the next dependency update.

LFI / RFI and stream wrappers

• include, require, include_once, require_once with user input.
• Wrappers that change everything: php://filter/... (read source, and a known RCE chain via convert.iconv/compression filters), php://input (RFI-style body inclusion), data:// (inline payload), phar:// (object injection), expect://, zip://. allow_url_include being on turns LFI into remote RFI.
• File-read sinks (file_get_contents, readfile, fopen, highlight_file) with traversal give source and secret disclosure.

SQL injection

• Legacy mysql_query/mysqli_query with string-concatenated input.
• $wpdb->query("... $var ...") without $wpdb->prepare() — a ->prepare that is present but interpolates outside its placeholders is still injectable.
• PDO/mysqli used with string building instead of bound parameters. Placeholder usage on the table/column name (which cannot be bound) is a common real hole.

Type juggling and magic-hash auth bypass

• == and != are loose. strcmp/hash_equals/=== are the safe forms. The classic bypass: if (md5($input) == $stored) where two inputs both hash to a 0e[0-9]+ "magic hash" compare equal, because two numeric strings compare as numbers (0e123 == 0e456 → 0.0 == 0.0).
• Version matters and it is a trap. In PHP 8.0 the number-vs-string rules changed: 0 == "foo" was true in PHP 7 and is false in PHP 8, so a in_array(0, $userStrings) or 0 == $token bypass that worked on PHP 7 fails on PHP 8. But the 0e magic-hash bypass survives PHP 8, because both sides are numeric strings and still compare as numbers. Check the target PHP version before ruling a juggling bug in or out.
• strcmp($_GET['x'], $secret) returned NULL (loosely == 0) when passed an array in PHP 7 — an auth bypass; in PHP 8 it throws a TypeError. Same code, different verdict by version.

Superglobal trust and variable variables

• extract($_GET/$_POST/$_REQUEST) lets a request set arbitrary local variables — overwrites auth flags, config, anything not yet initialized.
• $$var / ${$key} variable variables, parse_str without a result array (writes into scope), import_request_variables (removed 5.4) — all register_globals-flavoured variable injection.

SSRF and file upload

• file_get_contents/curl/fopen on a user-supplied URL is SSRF — route the exploitation reasoning through exploiting-ssrf.
• Uploads: check the destination is outside the web root, the extension is not attacker-chosen (double extensions, .phtml, .php5, null bytes on old PHP), and the server will not execute the type. A validated MIME with an attacker-controlled extension in a web-served directory is RCE.