PHP Security Tip #12
We’ve talked about filtering, we’ve talked about validating, we’ve talked about filtering again. Filtering inputs into your application is an important concept and the pre-cursor to many good security practices. However, once you have the input filtered and validated you can’t simply sit back and relax. You have to stay vigilant when programming to ensure security throughout your application.
Filtering input gives some developers a false sense of security. They assume that since they;ve filtered the input, there’s no reason to worry. That may be true in some simple instances but in most complex applications, you have to constantly be aware of what you are using the input for. This is never more true than when using user input in the eval() command. That brings us to today’s tip:
Think carefully before using eval()
By using user-inputted values in an eval(), you are potentially giving a malicious user a gateway to your server. Even if your interface forces them to chose only predefined options, the call to your script can be spoofed and your script can potentially be used to execute commands on demand by people who want to do bad things.
Use eval() sparingly. When you do have to use it, make sure you filter and then validate the input. If there are other ways to accomplish the task then consider using them instead.
=C=
Comments
Sounds obvious? Well, you wouldn't believe how often I have seen web sites, where amazingly old versions of frameworks, etc. were left forgotten (but in use), with wide-open and well documented security holes.
This is particularly true with web sites on shared hosting providers, where PHP, MySQL, etc. are updated automatically by the provider. However, if PEAR was not part of the package (i.e. you had to install it manually into your own web space), you are also responsible to update it yourself when a new version comes out.
And the situation gets really bad in situations where the site is a "one off" job for a client who does not have an administrator to keep looking after the site - it is probably better to include a support contract to the deal and explain why you may have to update parts of the system from time to time.
The alternative? How does a 2000,- Euro bill for additional web traffic (all e-mails sent via the web interface) sound? Plus having your domain blacklisted as an open relay at most ISPs.
I've seen that. Not a nice situation, believe me!
Greetings
/sascha