Newspaper publisher Z runs a self-hosted LAMP web platform for subscriptions, online editions and classified ads. Customers complain that code snippets typed into some input fields end up spread in the online ads. What is going on?

The input fields are not validated, or only weakly, so the platform stores whatever is typed and later serves it to every reader of the ad. That makes it vulnerable to cross-site scripting (XSS) and, since the application is written in PHP, potentially to remote code execution on the server.

* An unchecked ad field turns the publisher's own site into a delivery channel for an attacker's script. *

The case: publisher Z's web platform handles subscriptions to its newspapers and magazines, access to the online versions of some print media, and the placing of display ads and classifieds. It runs in Z's own data centre on a LAMP solution built years ago by an external service provider. Besides the security concerns, Z is unhappy with the platform's performance, look and functionality and wants a new solution built.

Cross-site scripting works like this: a script typed into an ad is saved in the database and delivered as part of the ad page, so every reader's browser runs it in the context of the publisher's site, where it can steal session cookies, rewrite the page or redirect to phishing. If the same missing validation reaches places where PHP evaluates or includes input, the attacker's code runs on the server itself (remote code execution). The fix is in the code (validate input, encode output), with a WAF as an additional filter in front.

Go deeper:

• OWASP — Cross Site Scripting (XSS) — stored and reflected XSS and what an injected script can do.
• OWASP Cheat Sheet — Input Validation — how to validate input properly.
• Code injection — Wikipedia — how unchecked input becomes code executed on the server.