Source Code Security Review

---

name: source-code-security-review description: | Perform a systematic white-box security review of web application source code to find exploitable vulnerabilities. Use this skill when: you have authorized access to an application's source code and need to identify security flaws faster or more thoroughly than black-box testing alone; auditing a codebase prior to launch or after a security incident; reviewing open-source or purchased software for embedded vulnerabilities; complementing an active penetration test with source-level analysis. Applies a three-phase methodology: (1) identify all user-input entry points via platform-specific source APIs — Java HttpServletRequest, ASP.NET Request.Params/Form/QueryString, PHP $_GET/$_POST/$_COOKIE/$_REQUEST, Perl CGI param(), JavaScript document.location/URL; (2) trace data flow forward to dangerous sink APIs — Runtime.exec()/Process.Start() for OS command injection, Statement.execute()/mysql_query() for SQL injection, FileInputStream/include() for path traversal, sendRedirect()/header() for open redirect, eval() for script injection; (3) line-by-line close review of authentication, session management, access control, and native code components. Covers 8 vulnerability signature categories: cross-site scripting, SQL injection, path traversal, arbitrary redirection, OS command injection, backdoor passwords, native software bugs (buffer overflow, integer flaw, format string), and incriminating source code comments. Also covers database code components (stored procedures with dynamic SQL) and environment configuration checks (web.xml, Web.config, php.ini). Produces a prioritized findings report with evidence and countermeasures. Maps to CWE-79 (XSS), CWE-89 (SQL Injection), CWE-22 (Path Traversal), CWE-601 (Open Redirect), CWE-78 (OS Command Injection), CWE-798 (Hardcoded Credentials), CWE-120/121/122 (Buffer Overflow), CWE-134 (Format String). For authorized security review engagements, appsec engineers, and security-minded developers. version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/web-application-hackers-handbook/skills/source-code-security-review metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: draft depends-on: [] source-books: - id: web-application-hackers-handbook title: "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" authors: ["Dafydd Stuttard", "Marcus Pinto"] edition: 2 chapters: [19] pages: "701-745" tags: [code-review, white-box-testing, source-code-analysis, xss, sql-injection, path-traversal, open-redirect, command-injection, backdoor, buffer-overflow, java, aspnet, php, perl, javascript, penetration-testing, appsec, cwe-79, cwe-89, cwe-22, cwe-601, cwe-78, cwe-798, cwe-120, cwe-134] execution: tier: 1 mode: full inputs: - type: codebase description: "Web application source code — server-side handlers, data access layer, database stored procedures, configuration files (web.xml, Web.config, php.ini), client-side JavaScript" - type: document description: "Build manifests, dependency lists, architecture diagrams — optional but useful for scoping" tools-required: [Read, Grep] tools-optional: [Bash, Write] mcps-required: [] environment: "Run directly against the source code repository. No live application required. Authorized review context required." discovery: goal: "Identify exploitable security vulnerabilities in web application source code using a structured three-phase approach — entry points, dangerous sinks, and line-by-line review of high-risk components — and produce a prioritized findings report" tasks: - "Establish platform and establish custom wrapper awareness before proceeding" - "Map all user-input entry points using platform-specific source APIs" - "Trace data flow from sources to dangerous sink APIs for each vulnerability category" - "Perform line-by-line review of high-risk components: authentication, session management, access control, native code" - "Audit database stored procedures for dynamic SQL construction" - "Review environment configuration files for security-relevant settings" - "Document findings with CWE mapping, severity, evidence, and countermeasures" audience: roles: ["penetration-tester", "application-security-engineer", "security-minded-developer"] experience: "intermediate-to-advanced — assumes familiarity with at least one server-side web platform (Java, .NET, PHP, Perl) and common web vulnerability classes" triggers: - "Penetration test engagement where source code access has been granted" - "Security audit of a web application prior to production deployment" - "Reviewing an open-source project or purchased component for embedded vulnerabilities" - "Root-cause analysis after a security incident — understanding how the vulnerability existed in code" - "Supplementing automated SAST tool output with manual verification" not_for: - "Black-box behavioral testing without source access — use the relevant black-box testing skills" - "Infrastructure or network security review — different scope" - "Mobile application source review — different platform APIs"

---

Source Code Security Review

When to Use

You have authorized access to a web application's source code and need to find security vulnerabilities systematically.

This skill applies when:

A penetration test or security audit includes source code access, and you want to find more vulnerabilities faster than black-box alone

You need to identify backdoor passwords, hardcoded credentials, or logic flaws that are invisible to behavioral testing

A black-box test revealed anomalous behavior and you want to trace its root cause in code

You are reviewing an open-source component before integrating it into production

The foundational insight: Black-box testing is powerful but incomplete. Automated fuzzing can send hundreds of test cases per minute, but it cannot identify a backdoor password that only activates for a specific hardcoded value, a condition-guarded XSS that only triggers when a secondary parameter equals "3", or a buffer overflow buried in a native helper library. Source code review finds a different population of vulnerabilities than black-box testing. The two approaches are strongest when combined — code review guides where to probe interactively; interactive testing confirms whether code-level findings are actually exploitable.

Before starting: Establish the extent of any custom wrappers, library extensions, or application-specific abstractions around standard APIs. Applications may implement their own session storage, input sanitization utilities, or database access layers. Understanding these customizations is essential — a call to a custom safeQuery() wrapper may or may not prevent SQL injection depending on its implementation.

Authorized review only. This skill is for security professionals with explicit written authorization.

---

Context and Input Gathering

Required Context

Platform(s) in use (Java, ASP.NET, PHP, Perl, JavaScript, or mix):

Why: each platform has distinct source APIs for reading user input and distinct dangerous sink APIs. The Grep patterns and review focus differ entirely between a Java servlet application and a PHP script. - Check for: pom.xml / build.gradle (Java), *.csproj / Web.config (ASP.NET), *.php files, *.pl files, package.json (Node.js/JS)

Scope of review (full codebase, specific modules, authentication only):

Why: a large enterprise application may have hundreds of thousands of lines. Time-boxed reviews require prioritizing the highest-risk components. Without a defined scope, coverage is uneven. - If unspecified, start with authentication, session management, access control, and any component that processes user file access or external command execution

Any existing SAST tool output:

Why: avoids duplicating what automated analysis already found and focuses manual effort on classes of issues that tools reliably miss (logic flaws, race conditions, backdoors).

Observable Context (gather from codebase)

Platform-specific configuration files: web.xml, Web.config, php.ini, .htaccess

Framework identification: Spring, Struts, Django, Laravel, Rails annotations and imports

Database access layer: ORM vs raw SQL, presence of prepared statement APIs

Custom security utilities: classes or functions named sanitize, validate, encode, escape, filter

Native code integration: JNI calls, P/Invoke, C extension includes, Runtime.exec / Process.Start

---

Process

Phase 1 — Map User-Input Entry Points

ACTION: Grep the codebase for platform-specific source APIs. Every location where user-controlled data enters the application is a potential source of tainted data. Build a catalog of entry points before tracing data flows.

WHY: Vulnerabilities arise when user-controlled data reaches a dangerous operation without proper validation or encoding. You cannot trace data flow without first knowing all the places data enters. Applications frequently receive input through less-obvious channels — HTTP headers, cookies, session-derived data from user registration, even the URL path itself. Missing an entry point means missing all vulnerabilities that originate from it.

AGENT: EXECUTES — Grep for platform-specific source APIs:

Java (HttpServletRequest / ServletRequest):

getParameter|getParameterNames|getParameterValues|getParameterMap
getQueryString|getHeader|getHeaders|getHeaderNames
getRequestURI|getRequestURL|getCookies|getRequestedSessionId
getInputStream|getReader|getRemoteUser|getUserPrincipal

ASP.NET (System.Web.HttpRequest):

Request\.Params|Request\.Item|Request\.Form|Request\.QueryString
Request\.ServerVariables|Request\.Headers|Request\.Url|Request\.RawUrl
Request\.UrlReferrer|Request\.Cookies|Request\.BinaryRead
Request\.Browser|Request\.UserAgent|Request\.AcceptTypes

PHP:

\$_GET|\$_POST|\$_COOKIE|\$_REQUEST|\$_FILES|\$_SERVER
\$HTTP_GET_VARS|\$HTTP_POST_VARS|\$HTTP_COOKIE_VARS
\$GLOBALS

Note: if register_globals is enabled in php.ini, any variable name may receive request parameter values. Line-by-line review is then required to track all uses of uninitialized variables.

Perl (CGI.pm):

->param\(|->param_fetch\(|->Vars\b|->cookie\(|->raw_cookie\(
->query_string\b|->referer\b|->self_url\b|->url\b
ReadParse

JavaScript (DOM sources):

document\.location|document\.URL|document\.URLUnencoded|document\.referrer
window\.location|location\.search|location\.hash|location\.href

NOTE: Also search for $GLOBALS (PHP), any class names ending in Request, HttpContext, HttpInput, or equivalent — applications commonly abstract input access behind wrapper classes.

---

Phase 2 — Trace Data Flow to Dangerous Sinks (Signature Scanning)

ACTION: For each vulnerability category below, grep for the dangerous sink APIs. For each hit, trace backward to determine whether user-controlled data from Phase 1 sources flows into that sink without adequate validation or encoding. Confirm or dismiss each candidate finding.

WHY: Signature scanning targets the highest-density locations of potential vulnerabilities first. A hard-coded SQL query fragment like "SELECT appearing in application code is almost always part of a SQL injection–vulnerable pattern. An eval() call receiving user input is almost always dangerous. This approach finds low-hanging fruit quickly, leaving remaining time for the subtler line-by-line review in Phase 3.

---

#### 2.1 — Cross-Site Scripting (XSS)

Grep for output APIs that write user data to responses:

Java: response.getWriter().print|println|write, out.print|println, .InnerHtml, response.setHeader

ASP.NET: Response.Write|Response.Output.Write, \.InnerHtml\s*=, \.InnerText\s*=

PHP: echo\b|print\b|printf\b|vprintf\b,

JavaScript (DOM sinks):

document\.write\(|document\.writeln\(|\.innerHTML\s*=
eval\(|window\.execScript\(|window\.setInterval\(|window\.setTimeout\(

Pattern to find: User input from a Phase 1 source is incorporated into HTML output without HTML-encoding. Example:

// Vulnerable: m_pageTitle set from request.getParameter("title") and
// later written into a