PHP Security Tip(1)
时间：2007-06-28 来源：linxh
1. Keep your PHP version up-to-date.
As with any other language, vulnerabilities[缺陷] will be discovered. Running the most recent PHP version, and knowing about its improvements will help keep your application secure, efficient, and stable.
2. Security by obscurity is no security at all. On the other hand you don't want to give away information about your site either. Today's tip is a simple one but one that is often overlooked[没有被注意到] in production environments.
Make sure you do not display errors and potentially leak information about your site.
Simply setting display_errors = Off in your php.ini of your production server will prevent you from leaking information that may give intruders hints to the structure of your system. By default, display_errors = On.
You can find more information and error reporting options in the manual's
Error Handling and Logging Functions Introduction
section.
3. Being Security conscious[有意识的] is a good thing but that alone won’t solve the problem. Developers have to be vigilant[警惕] when it comes to security. Even then you can’t do it alone. Today’s Security tip reminds you of this.
Since your application may be harboring security vulnerabilities that you have not been exposed to, third-party security software or services should be considered to help bring a fresh perspective and find overlooked weaknesses.
As a developer you should have tools in your toolbox that will help you find security vulnerabilities in your applications. Tools like
Chorizo
will help you by performing automated scans of your code. Programs like
PHPSecInfo
will help you ensure that your environment is configured properly.
Using tools like these and other scanning tools should not be the only thing you do to ensure security. They are however, an important part of the mix. Let trusted projects and vendors help you build and maintain secure applications.
4. “Security through obscurity is no security at all.” so the adage[格言] goes. However, the flip side of that coin is, obscurity, when used as part of an overall strategy, is a good thing. There’s no sense in making things any easier for those with malicious[怀有恶意的] intent[企图]. That brings us to our security tip for the day.
Give files and folders with critical information non-default names.
Don’t rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don’t make it easy for bad people to do bad things. Don’t use default or common names for your files and directories.
Do you have a security tip you would like to share? A nugget of security truth you have gleaned through research or life’s school of hard knocks? Log-in and click the contribute button in the upper right hand corner.
5. PHP security is an ongoing mission requiring the programmer to think outside of the parameters of the application. It’s not enough these days to say in your mind “Does this do what I want it to do?” you also have to take into consideration “What else can people use it for and do I want to allow that?” Today’s Security tip is a proverb that all programmers should have to recite daily.
Never trust the user.
It’s a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking “I’m only selling small stuffed animals so how evil can my users really be?” you’ve lost the battle.
Ok, maybe it’s not quite that dire but you do have to keep a wary eye on some of your users. That’s where the second proverb that all programmers should recite daily comes in.
Filter Input, Escape Output
Yes, FIEO (ok, it’s not as cool sounding as GIGO) is one of the mantras that all security minded programmers have live by.
6. The topic of writing secure applications in PHP covers more than just writing good PHP code. Most applications make use of a database of some kind. Many times, vulnerabilities that affect the entire application, are introduced when building the SQL code. Today's Tip of the Day deals with one easy solution developers can implement.
When dealing with numbers in a SQL query, always cast.
Even if you are filtering your input, a good and easy to implement safety measure is to cast all numeric values in the SQL statement. Take for example the following code.
$myId = filter_var($_GET['id'],FILTER_VALIDATE_INT);
$sql = 'SELECT * FROM table WHERE id = '.$myId;
Even though you are applying the native PHP filters built into PHP 5.2, there is something additional you can do. Try this instead.
$myId = filter_var($_GET['id'],FILTER_VALIDATE_INT );
$sql = 'SELECT * FROM table WHERE id = '.(int)$myId;
This final cast of the variable to an int removes any doubt about what will be passed to MySQL. The example above is purposefully simplified. In real-life situations, the code would be more complex and the chance for error much greater. By applying the final cast to in building the select statement, you are adding one more level of safety into your application.
7. When using session_regenerate_id() to protect against session fixation it's usually a good idea to remove the old session ID.
For example, the script
Go to the URL once and check your /tmp directory
sess_82c6980017e100277a63983142fd454c
sess_a4bab88e6dfa6e900ade21e3fbd27a53
Go again and you'll see
sess_984c5230acca90b5a75eddb89bb48354
sess_a4bab88e6dfa6e900ade21e3fbd27a53
sess_82c6980017e100277a63983142fd454c
And again, and you'll see
sess_984c5230acca90b5a75eddb89bb48354
sess_a4bab88e6dfa6e900ade21e3fbd27a53
sess_82c6980017e100277a63983142fd454c
sess_dd88c05b724d80b30c90309847f2e919
Those sessions are still active. To remove them when regenerating the ID use the following code:
If you're using your own session handler this will also cause your destroy callback function to be called.
While this will not be make or break when building a secure application it gives you a little added security against session fixation that costs you 4 characters of code.
8. Withing PHP security topics, there is always more than one way to accomplish a task. Many times it's by combining tactics[战术] that we achieve the best security. We've already talked about filtering but beyond filtering we still need to be vigilant[警惕] and validate input coming in from a user. This brings us to our PHP security of the day.
Always validate user input.
Take for example the following code:
Calling http://example.com/file.php?file=home.php will cause your script to include the file home.php in your current directory. However, if someone comes along and requests http://example.com/file.php?file=badcode.php you will be potentially exposing yourself to executing their code, or your code that you do not want executed in that context.
Do not depend solely on file_exists(). Just because it's a local file does not mean that it's a valid file or even that it's your file. Don't give hackers an easy easy to execute their code on your server.
To protect against this, always filter and validate:
9. Sometimes it’s the simplest ideas that are the most powerful. This one sounds simple but I’m always surprised at how few people understand and actually implement this idea.
Keep sensitive data and code out of your web tree
Consider this directory structure.
/htdocs
/includes
/images
/js
If you store your database credentials in a file named db.inc and place it in the /includes directory, it is possible for someone to download your the information in that file by going to http://example.com/includes/db.inc. Since most web servers aren’t given explicit instructions on how to deal with .inc files, they are treated as text if requested directly. The ramifications[后果] of this are obvious. If you store your database credentials in a file with an extension other than .php and inside your web server’s document root, there’s a good chance that you are leaking information.
The solution is simple. Place all sensitive data outside of your web server’s document root. Many experts now advocate[提倡] placing most, if not all, of your php code outside of your web server’s document root. Since PHP is not limited by the same restrictions are you web server, you can make a directory on the same level as your document root and place all of your sensitive data and code there.
/phpinc
/includes
/htdocs
/images
/js
10. Even when doing everything correctly, it’s still possible to build PHP applications that are insecure. Security requires constant vigilance[警觉]. One thing you always have to keep your eye on is any script or form that sends an email based on use input.
Many applications written in PHP use the built-in mail() function to respond to user input by triggering an email. Do not blindly send mail using information entered into a form.As we’ve discussed in other tips on PHP security, you have to make sure you properly filter and validate your user input. If you do not properly filter your input, it becomes easy for someone to perform an email header injection and spam thousands of people before you’ll even notice.For further reading on email header injection, I recomend
this page
at securephpwiki.com.
As with any other language, vulnerabilities[缺陷] will be discovered. Running the most recent PHP version, and knowing about its improvements will help keep your application secure, efficient, and stable.
2. Security by obscurity is no security at all. On the other hand you don't want to give away information about your site either. Today's tip is a simple one but one that is often overlooked[没有被注意到] in production environments.
Make sure you do not display errors and potentially leak information about your site.
Simply setting display_errors = Off in your php.ini of your production server will prevent you from leaking information that may give intruders hints to the structure of your system. By default, display_errors = On.
You can find more information and error reporting options in the manual's
Error Handling and Logging Functions Introduction
section.
3. Being Security conscious[有意识的] is a good thing but that alone won’t solve the problem. Developers have to be vigilant[警惕] when it comes to security. Even then you can’t do it alone. Today’s Security tip reminds you of this.
Since your application may be harboring security vulnerabilities that you have not been exposed to, third-party security software or services should be considered to help bring a fresh perspective and find overlooked weaknesses.
As a developer you should have tools in your toolbox that will help you find security vulnerabilities in your applications. Tools like
Chorizo
will help you by performing automated scans of your code. Programs like
PHPSecInfo
will help you ensure that your environment is configured properly.
Using tools like these and other scanning tools should not be the only thing you do to ensure security. They are however, an important part of the mix. Let trusted projects and vendors help you build and maintain secure applications.
4. “Security through obscurity is no security at all.” so the adage[格言] goes. However, the flip side of that coin is, obscurity, when used as part of an overall strategy, is a good thing. There’s no sense in making things any easier for those with malicious[怀有恶意的] intent[企图]. That brings us to our security tip for the day.
Give files and folders with critical information non-default names.
Don’t rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don’t make it easy for bad people to do bad things. Don’t use default or common names for your files and directories.
Do you have a security tip you would like to share? A nugget of security truth you have gleaned through research or life’s school of hard knocks? Log-in and click the contribute button in the upper right hand corner.
5. PHP security is an ongoing mission requiring the programmer to think outside of the parameters of the application. It’s not enough these days to say in your mind “Does this do what I want it to do?” you also have to take into consideration “What else can people use it for and do I want to allow that?” Today’s Security tip is a proverb that all programmers should have to recite daily.
Never trust the user.
It’s a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking “I’m only selling small stuffed animals so how evil can my users really be?” you’ve lost the battle.
Ok, maybe it’s not quite that dire but you do have to keep a wary eye on some of your users. That’s where the second proverb that all programmers should recite daily comes in.
Filter Input, Escape Output
Yes, FIEO (ok, it’s not as cool sounding as GIGO) is one of the mantras that all security minded programmers have live by.
6. The topic of writing secure applications in PHP covers more than just writing good PHP code. Most applications make use of a database of some kind. Many times, vulnerabilities that affect the entire application, are introduced when building the SQL code. Today's Tip of the Day deals with one easy solution developers can implement.
When dealing with numbers in a SQL query, always cast.
Even if you are filtering your input, a good and easy to implement safety measure is to cast all numeric values in the SQL statement. Take for example the following code.
$myId = filter_var($_GET['id'],FILTER_VALIDATE_INT);
$sql = 'SELECT * FROM table WHERE id = '.$myId;
Even though you are applying the native PHP filters built into PHP 5.2, there is something additional you can do. Try this instead.
$myId = filter_var($_GET['id'],FILTER_VALIDATE_INT );
$sql = 'SELECT * FROM table WHERE id = '.(int)$myId;
This final cast of the variable to an int removes any doubt about what will be passed to MySQL. The example above is purposefully simplified. In real-life situations, the code would be more complex and the chance for error much greater. By applying the final cast to in building the select statement, you are adding one more level of safety into your application.
7. When using session_regenerate_id() to protect against session fixation it's usually a good idea to remove the old session ID.
For example, the script
Go to the URL once and check your /tmp directory
sess_82c6980017e100277a63983142fd454c
sess_a4bab88e6dfa6e900ade21e3fbd27a53
Go again and you'll see
sess_984c5230acca90b5a75eddb89bb48354
sess_a4bab88e6dfa6e900ade21e3fbd27a53
sess_82c6980017e100277a63983142fd454c
And again, and you'll see
sess_984c5230acca90b5a75eddb89bb48354
sess_a4bab88e6dfa6e900ade21e3fbd27a53
sess_82c6980017e100277a63983142fd454c
sess_dd88c05b724d80b30c90309847f2e919
Those sessions are still active. To remove them when regenerating the ID use the following code:
If you're using your own session handler this will also cause your destroy callback function to be called.
While this will not be make or break when building a secure application it gives you a little added security against session fixation that costs you 4 characters of code.
8. Withing PHP security topics, there is always more than one way to accomplish a task. Many times it's by combining tactics[战术] that we achieve the best security. We've already talked about filtering but beyond filtering we still need to be vigilant[警惕] and validate input coming in from a user. This brings us to our PHP security of the day.
Always validate user input.
Take for example the following code:
Calling http://example.com/file.php?file=home.php will cause your script to include the file home.php in your current directory. However, if someone comes along and requests http://example.com/file.php?file=badcode.php you will be potentially exposing yourself to executing their code, or your code that you do not want executed in that context.
Do not depend solely on file_exists(). Just because it's a local file does not mean that it's a valid file or even that it's your file. Don't give hackers an easy easy to execute their code on your server.
To protect against this, always filter and validate:
9. Sometimes it’s the simplest ideas that are the most powerful. This one sounds simple but I’m always surprised at how few people understand and actually implement this idea.
Keep sensitive data and code out of your web tree
Consider this directory structure.
/htdocs
/includes
/images
/js
If you store your database credentials in a file named db.inc and place it in the /includes directory, it is possible for someone to download your the information in that file by going to http://example.com/includes/db.inc. Since most web servers aren’t given explicit instructions on how to deal with .inc files, they are treated as text if requested directly. The ramifications[后果] of this are obvious. If you store your database credentials in a file with an extension other than .php and inside your web server’s document root, there’s a good chance that you are leaking information.
The solution is simple. Place all sensitive data outside of your web server’s document root. Many experts now advocate[提倡] placing most, if not all, of your php code outside of your web server’s document root. Since PHP is not limited by the same restrictions are you web server, you can make a directory on the same level as your document root and place all of your sensitive data and code there.
/phpinc
/includes
/htdocs
/images
/js
10. Even when doing everything correctly, it’s still possible to build PHP applications that are insecure. Security requires constant vigilance[警觉]. One thing you always have to keep your eye on is any script or form that sends an email based on use input.
Many applications written in PHP use the built-in mail() function to respond to user input by triggering an email. Do not blindly send mail using information entered into a form.As we’ve discussed in other tips on PHP security, you have to make sure you properly filter and validate your user input. If you do not properly filter your input, it becomes easy for someone to perform an email header injection and spam thousands of people before you’ll even notice.For further reading on email header injection, I recomend
this page
at securephpwiki.com.
相关阅读 更多 +
排行榜 更多 +
