Never Trust the Client

Please, never trust the client. I’m not sure how much this can be stressed. After writing unsupported interfaces for various programs (most commercial) I find that this basic rule is not always followed. Gone are the days where people submit forms and then the server checks the inputs and will return one or more error messages for bad input. Now much of the error checking is done in the browser to make it more convenient for the end-user, as they won’t have to wait for a round-trip of their data to realize that they entered only four numbers for a U.S. zip code.

The problem is at one time all checking was done server-side. Then for end-user convenience, most or all of the checks were duplicated on the client-side. Now I am seeing developers “forget” to check things on the server-side. In the days of increased attacks on web sites, this becomes more critical. The client can never be trusted. Once the JavaScript is loaded in the end-user’s browser, it can be manipulated and checks disabled, allowing them to submit bad data. They may even just submit the data to your server by just constructing the HTTP request themselves.

Just today I was working on creating an unsupported interface to a popular commercial software that many companies use. While reverse-engineering different parts or their interface’s code, I found that they must have been lazy, because they send an “API” command that looks suspiciously exactly like PHP. I put a syntax error in it and it complained about a syntax error in an eval() statement. An eval() statement?! Yes, I can execute anything I want on the server, making any kind of access control obsolete, as I have direct access to the running PHP instance, the database server, and the file system.

So, please,

die unless $i_am_a_number =~ m{\A\d+\z}mx;

Leave a Reply