A Custom PHP Site Written Before Anyone Checked Inputs

A site that still works

Plenty of small business sites were written by hand in PHP around 2005 or 2006: a product catalogue, a search box, and a page for each item with its number at the end of the address.

The developer who wrote such a site has often moved on. Nobody has touched the code since, because nothing appeared to be wrong with it.

The weakness is invisible from outside. Many of these sites take whatever a visitor types, in the address bar or the search box, and hand it straight to the database as part of a command.

Plenty of tutorials from those years taught exactly that.

What checking inputs means

A catalogue page might fetch item 42 by asking the database for the product whose number is 42. The 42 comes from the address, where anyone can change it.

If the code confirms it is a number, or keeps the visitor's text separate from the command, nothing else gets through.

If it simply pastes the text into the command, a visitor can type database instructions instead of a number, and the database carries them out. This is called SQL injection, after the language most databases use.

The same applies to search boxes, login forms and any form that saves what people type.

What automated tools look for

No one needs to choose your business: scanning tools work through enormous numbers of sites, looking for familiar signs.

• Numbers in the address, such as product.php?id=42.
• Search boxes that print the search term back on the page.
• Login pages for staff, members or dealers.
• Database error messages shown to visitors.
• Old admin pages at guessable addresses.

The fourth gives the most away. A page that answers a stray quote mark with a database error tells the tool that its input reached the database unchecked, and often which database it is.

What an attacker gets

Reading usually comes first: customer details, order history and the table of staff or dealer passwords, often stored as readable text on sites of this age.

Changing comes next. Links to pharmacy sites appear in product descriptions, or a script is added that sends visitors somewhere else.

With an administrator's password, an attacker can often reach the site's own upload page and leave files behind, which survive long after the original hole is closed.

Why there is no update to install

When a flaw turns up in WordPress, its maintainers publish a fix, and most sites receive it within days.

A custom site has no maintainer and no fix on the way. The flaw is in the lines your developer wrote, repeated wherever the code accepts input.

Fixing it means someone reading that code, page by page.

Sites this old often run on old PHP as well. Version 5.3 stopped receiving security fixes last August, and the database functions these sites rely on are marked for removal.

Signs it may already have happened

Server logs with requests containing words like select and union in the address. Product descriptions with links nobody added. Staff accounts nobody recognises.

A warning in Google's results that the site may be hacked, or a message under Security Issues in Search Console, formerly Webmaster Tools.

None of these proves an injection, and their absence proves nothing either. They are reasons to stop guessing.

A worked example

A door hardware supplier sells locksets, hinges, closers and panic bars to contractors and building managers from a warehouse showroom in an industrial park.

Its catalogue site was written by hand in 2006, with a page for each product, a part number search and a login where dealers see their prices.

The host flagged a weekend of unusually heavy traffic. The logs showed tens of thousands of requests to the product page, each with database commands where the product number should have been.

A tester the supplier hired found the cause in an afternoon: the product page and the search box both passed input straight to the database, and the dealers' table could be read from outside.

The two pages were repaired within the week, every dealer was asked to choose a new password, and the site stopped storing passwords as readable text.

The rest of the catalogue, which had no phone layout and ran on PHP 5.3, was scheduled for a rebuild.

Having it tested

A proper test starts with a list of every place the site accepts input: addresses carrying values, forms, search boxes, logins and file uploads.

The tester then reads the code behind each one and runs an automated scan with your written permission, ideally against a copy of the site, since scans can fill a live database with junk.

Ask for a written report listing each finding, how serious it is and what fixing it involves. That report is also what you need for the next decision.

Pointing attack tools at the live site yourself is a poor substitute. Reading the results takes experience, and the tools can break things.

Repair or rebuild

A repair makes sense when the site is small, the code is readable, and the business is otherwise happy with how it looks and works on phones.

It means rewriting each database query so the visitor's input travels separately from the command, checking that numbers are numbers, hiding error messages from visitors and moving to a current PHP version.

A rebuild makes sense when the test finds problems on most pages, when the site also fails on phones, or when the old database functions would need replacing throughout anyway.

Then patch the worst inputs now and plan the rebuild on a maintained platform, rather than paying to repair code that is about to be replaced.

The counter-case

Not every old PHP site is vulnerable. Some developers checked inputs carefully in 2006, and a site with no database offers nothing to inject into.

A rebuild on a popular platform is not automatically safe either, though it does receive regular fixes.

And a test can be limited to the pages that matter most when the budget is small. What counts is knowing rather than assuming: test the custom code, then let the findings decide between repair and rebuild.

The order to do it in

1. List every page that accepts input.
2. Check the logs for database words in addresses.
3. Hide database errors from visitors.
4. Commission a written test of the code.
5. Repair the worst inputs first.
6. Reset passwords stored in the database.
7. Decide between repair and rebuild from the report.

Step four is the one that replaces guesswork. Until someone has read the code, nobody can say whether the site has one weak page or forty.

How a maintained platform delivers its own fixes is covered in three WordPress updates in eight days.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.