Taking care of our Input/Output
Well … when you’re programming to the web, you MUST not trust anybody.
That’s because your application has many different kind of access, and it is, usually, something that you want.
Sometimes you want it to b accessed by a simple browser, others, from a Mobile, many times, from the computer on the intranet, or even from other server/webserver.
We can interact with desktop applications or applications that are in the other side of the world. So that, you really have to be afraid about “where has this information been?”
Then, two little rules to your life…
- DO NOT trust in the origins your information have
- Only show trustful information
How’s that? Firstly, you’ve gotta verify everything in your INPUT. To do so, I could indicate you some interesting tools PHP offers you:
strip_tags, and addslashes.
This is not everything you will use to be safe, don’t pretend you’re safe just using it. But, adding slashes to your inputs, you’ll avoid many injections, because your strings will be escaped.
Please, understand that your input is always a string, but PHP offers you the “casting”.
If your variable from post, get, or even from your $_SERVER input, is supposed to be an integer, use this.
$_POST['number']= (integer)$_POST['number'];
if something bad was there, you’ve just avoided it.
The strip_tags method allows you to remove tags you don’t want, which is the best way, once you shouldn’t imagine what you don’t want, but what you want.
Everyday someone will be looking for something to destroy something, so, you have to be aware.
If, for example, people may add comments in my application, before inserting it to my database, it’s better to use addslashes, to keep the comment 100% as the user did. BUT, when showing it, you will take care of your OUTPUT.
Before writing it to the output, you will use the strip_tags method, to avoid any < script > or < iframe > anyone may have saved in there.
Strip_tags also allows you to list the tags you WANT to leave, for example, I want < b > and < i > to be written into the comments.
An interesting thing I like to do is, in the very beginning of each php file, I include a header file. In this header, I can verify the sessions, and if that logged person has permission to be around there…I can set the charset ecoding of all pages, and also, clean my variables.
In this header, I go through all the input variables applying some methods I trust. After including this file, I know the variables are clean for use.
Of course, if I have to import data with includes, or use the file_get_contents, for example, it’s quite interesting to call again, the function to clear them all again.
Tips about your user select queries.
I try, more than simply escaping and stripping the input, build my query like this, to verify the user login.
select [fieldNames] from [tableName]
where [status]= [valueIfOk] and [userCode]= [inputCode]
and ([password]= ‘[inputPassword]‘)
Let’s analyze each line:
select [fieldNames] from [tableName] -> here, avoid to use “user” or “login” as table name…the same to the field names, try to adopt your own pattern, preferentially customizing it as much as possible to the current system. Remember, the less your enemy knows about you, safer you are.
Second line:
where [status]= [valueIfOk] and [userCode]= [inputCode] -> here, the first thing we will see is if the user login is correct, and if this is a valid user, with an OK status. If your attacker is trying some injection, he needs to know at least an authorized user’s login.
Third point:
and ([password]= ‘[inputPassword]‘) -> here, we verify between (), or even more than one parentheses, the password, as the last key to verify… if the attacker reach this point with some injection, well, he must put the correct ) to force it to work, once
and(passowrd = ‘1′ or true
will return an error, in case of his password be “1′ or true”, and it reached this point without a \’.