T09 · Insecure Skill Coding Practices
Error
- Location
references/php-forms.md:37- Finding
Unencoded Form Input Enables Reflected Cross-Site Scripting
- Content
View full analysis
Your email address is: ``` The corresponding GET example contains the same flaw: ```php Welcome
Your email address is: ``` ### Technical Analysis The examples insert attacker-controlled `name` and `email` values directly into an HTML response. Neither validation nor context-appropriate HTML output encoding is applied before the values are rendered. An attacker can submit HTML containing executable JavaScript, such as an event-handler payload. The PHP application then incorporates that value into its response, and the victim's browser interprets it as active content in the application's origin. Input validation alone is not a sufficient defense because valid-looking values can still contain characters that affect HTML parsing. Output must be encoded for the precise output context. ### Attack Path 1. A developer copies the introductory form-processing example into a PHP application. 2. An attacker constructs a request in which `name` or `email` contains an HTML or JavaScript payload. 3. For the GET variant, the attacker can place the payload in a crafted URL and persuade a victim to open it. For the POST variant, the attacker can submit the payload directly or cause a victim to submit an attacker-controlled form. 4. The PHP handler reads the value from `$_GET` or `$_POST`. 5. The handler echoes the value into the HTML response without encoding it. 6. The victim's browser parses and executes the injected content under the vulnerable application's origin. ### Impact Assessment Successful exploitation permits script execution in the security context of the affected website. Depending on the ...[truncated 571 chars]- Remediation
View remediation
Welcome
Your email address is: ``` Apply the same protection to the GET example. In addition: 1. Validate field presence, length, and expected format on the server. 2. Use `filter_var($email, FILTER_VALIDATE_EMAIL)` for email-format validation, but do not treat validation as a replacement for output encoding. 3. Encode according to the output context; HTML text, HTML attributes, URLs, CSS, and JavaScript require different handling. 4. Add a restrictive Content Security Policy as defense in depth. 5. Mark the original direct-echo pattern as explicitly unsafe so generated applications do not reproduce it. 6. Add tests using HTML metacharacters and representative XSS payloads to verify that responses display input as text rather than executable markup. ]]>