PHP and MySQL Web Development 4th Ed-tqw-_darksiderg

376 Chapter 16 Web Application Security
Additionally, we want to be extremely careful when we let users enter the name
of a file they would like to see. If we had a directory in our document root (c:\
Program Files\Apache Software Foundation\Apache2.2.htdocs\) with a bunch of
files we were granting users access to, and they input the name of the file they wanted to
view, we could get into trouble if they asked to see
..\..\..\php\php.ini
This would let them learn about our PHP installation and see whether any obvious
weaknesses exist to exploit. Again, the fix to this problem is easy: if we do accept user
input, make sure we filter it aggressively so as to avoid any problems of these sorts. For
the preceding example, removing any instances of ..\ would certainly help prevent this
problem, as would any attempt at an absolute path such as c:\mysql\my.ini.
Code Stability and Bugs
We mentioned this briefly before, but your web application is neither likely to perform
well nor be terribly secure if the code has not been properly tested, reviewed, or is so
complicated as to be full of bugs.This should not be taken as an accusation at all, but
rather as an admission that all of us as programmers are fallible, as is the code we write.
When a user connects to a website, enters a word in the search dialog (for example,
“defenestration”), and clicks Search, the user is not going to have great confidence in the
robustness or security of it if the next thing the user sees is
¡Aiee! This should never happen. BUG BUG BUG !!!!
If we plan from the beginning for the stability of our application, we can effectively
reduce the likelihood of problems due to human error.Ways in which we can do this are
as follows:
n Complete a thorough design phase of our product, possibly with prototypes.The
more people we have reviewing what we plan to do, the more likely we are to
spot problems even before we begin.This is also a great time to do usability testing
on our interface.
n Allocate testing resources to our project. So many projects skimp on this, or hire
perhaps one tester for a project with 50 developers. Developers do not typically make
good testers! They are very good at making sure their code works with the correct
input, but less proficient at finding other problems. Major software companies have
a ratio of developers to testers of nearly 1:1, and although it may not be likely that
our bosses would pay for that many testers, some testing resources will be critical
to the success of the application.