PHP Security Tip(2)
时间：2007-06-28 来源：linxh
11. I think we can all agree that users are at once the boon[恩惠] and the bane[祸害] of our applications. On the one hand, if it weren’t for users, we wouldn’t have security problems. On the other hand, if we didn’t have users, we wouldn’t need the application to begin with. So we can all agree with the fact that in most cases, users aren’t going away. This means that we have to factor them into our security mind-set. One good principal to adopt[采取] is:
The Principle of Least Privileges
Grant permissions to users only to the level needed
This is a basic programming principal and can be seen most readily in Unix security. When dealing with users and resources in Unix, users have to be explicitly granted access to resources. Permissions are granted in such a way as to give the user the least permission necessary to gain access to the resource. We can adopt this concept when building our applications by considering carefully the users who will need to access each page and feature.
Most modern PHP frameworks have the concepts or authentication and access control. In the Zend Framework, authentication is handled by
Zend_Auth
but access control, a separate issue, is handled with
Zend_Acl
Whichever framework you use, good security practices suggest that you carefully consider the access restrictions you place on each page or feature. Whenever possible, limit access to the fewest number of users possible.
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.
13. Security is a mindset, not just something you do. It colors your application design as well as your coding. However, you also need to constantly monitor your production environment. That’s where selecting the right tool comes into play. I know I’ve mentioned
PHPSecInfo
before but I think this tool is important enough to warrant it’s own post.
PHPSecInfo
is a great tool to use to keep an eye on your production environment. It was written by Ed Finkler of
CERIAS
, the Center for Education and Research in Information Assurance and Security at Purdue University. It is officially a project of the
PHP Security Consortium
. Here’s what the PHPSecInfo homepage has to say about itself.
PHPSecInfo
provides an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.
If you need more info, here’s
the link
to a short interview with Ed talking about PHPSecInfo. Here is another
link
to the latest release notice for version 0.2.
As with all security measures, by itself it’s not the silver bullet. Used properly though, it can be part of a comprehensive solution.
14. Almost any application running PHP on the back-end uses web technologies for it’s front end. Many developers who think hard on PHP security, don’t spend a thought on front-end security for their application. Here’s a tip to think long and hard about when building your HTML and JavaScript.
Any data inside of a cookie can be potentially seen by others- restrict to a minimum
It’s a sad fact on today’s web but there are bad people out there. They want nothing more than for your application to leak sensitive data so they can exploit it. Make sure you look at the whole picture when evaluating the security of your application. This is very important when looking at what information you persist on the front end.
15. As developers, most of us are very messy. I’ve worked on countless projects and at each either run across or left a trail of diagnostic files laying around. (info.php, test.php, doMe.php, etc.) These tiles, if found by someone with nefarious intent, can leak valuable information about your system.
Today’s Security tip is:
Don’t forget to purge temporary system diagnostic files.
It would be a shame to spend all that time securing your application only to leave info.php or worse yet, a “quick piece of code” in test.php that could potentially leak dangerous information about your system. Don’t help the ad guys any more than you have to.
16. Make sure any framework you are using is updated regularly.
This is especially important if you are working on a ‘one-shot’ client project. It is important to think about who is going to maintain the site if (or rather: when) a security patch is issued for any of the 3rd party files.
Usually, these sites are placed on a shared hosting site, and that means the provider is responsible for keeping PHP, database system, web server, etc. up to date – but they will probably not maintain the frameworks you have installed.
Using frameworks is generally a good idea – not only because they take a lot of the work away from you, but also because any potential security issue will (usually) quickly be dealt with.
On the other side, this means that security issues in these frameworks are very well documented – and it is all to easy for a malicious hacker to search for old versions of the framework in use, and exploit these problems.
I have seen many, many sites which are still using extremely old and outdated files – simply because there is nobody there to update it. And I’m talking about old PEAR installs (with known issues with the ‘Mail’ component) and worse!
Even if it’s not you who has to pay the bill for excess server traffic – it might be your mailbox that receives some of the spam sent from this server!
17. Application security should not be a "when all else fails" situation. It's not something you can "put in later". As we've mentioned before, there is no single silver bullet to solve your application security issues. Security is something that should be rolling around in the back of your dead in the design phase, the coding phase, the testing phase, even after you've rolled your code into production.
Chris Shiflett
, noted PHP security expert, has a
PDF
on his web site that should be required reading for all PHP developers. Compiled by the PHP Security Consortium, this 37 page guide explains the terms and concepts involved in securing your PHP application. Here's how they describe security.
Security is a measurement, not a characteristic.
It is unfortunate that many software projects list security as a simple requirement to be met. Is it secure? This question is as subjective as asking if something is hot.
If security is important to you but you don't know where to start, this is a good place.
Download the PDF
and spend the hour or so reading it thoroughly. If you are already a seasoned veteran, download it and skim through it. You might pick up on something new.
18. When you allow users to upload files, your system may be at risk. Always restrict the file types that you allow. Don’t rely on a blacklist approach.
For example, a reasonable blacklist policy would seem to be Don’t allow the upload of .php files.
That’s a good policy until someone uploads a file named .htaccess. It’s not a PHP file so the blacklist won’t catch it. Placing this line in an .htaccess file and uploading it to a system only protected by a blacklist policy would open the door for the bad guys.
AddType application/x-httpd-php .php .htm
They can now upload any .htm file with PHP code in it and start poking around in your system.
For example.
Chances are good that the above code will give an attacker the name of every config file on the server. The possibilities for attacks are endless, all because of one unprotected upload form your server.
Be careful with file uploads and make sure you protect them with a whitelist policy instead. Make sure that the file that has been uploaded is of the type that you want to allow. There are several ways to do this, the easiest (and the easiest to defeat) is by checking the extension of the file uploaded. You can easily throw away any file that does not have the proper extension. However, that’s not the safest way to do it.
FOr a more secure check, look into the PECL extension,
FileInfo
. The documentation for it can be found
here
. FileInfo examins the contents of the file and tries to guess the content type based specific magic byte sequences. Using FileInfo as part of a strict whitelist policy is a much more secure way of allowing users to upload files to your system.
19. Sometimes, the best application security you can install is simply disconnecting the network cable from your server. Ok so in the real world it’s not really feasible. Thinking about it though starts you down a path that can lead to better application security.
When considering security you have to consider the hardware as well as the software. Today’s security tip comes to us from
Chris Hartjes
.
The most secure application is one with no connection to the outside world.
As we’ve covered, you can’t really disconnect the network from your web server if you are building web applications. You can however, carefully consider which servers need to be connected to the outside world and which can be inside your firewall. Beyond that, you can also evaluate how those servers that have to remain outside your firewall communicate with the ones inside.
Session Hijacking, XSS, and XSRF are all serious problems for developers and I don’t mean to minimize them. However, in many of cases, they are a means to an end. For most hackers, the pot of gold at the end of the rainbow is your database. The worst problem we as developers face today is having our application hacked, our database compromised and information that has been trusted to us by our users starting to spill out into the Net.
One simple (to explain) way to make that a little harder is to move your database server behind your firewall and limit access to it. Once you get going down this road, you will find other ideas to help secure your entire system.
This is just a short tip to get you thinking, it’s not a network security primer. I’ll leave it to you to find your quiet place today and for just a moment or two, review in your head how your physical network is structured. Think about how things are connected and consider if there’s anything you can do to make them all more secure.
Got a security tip you would like to share? Click on the
Contribute
link in the upper right corner.
20. To paraphrase an
American Patriot
"The price of security is eternal vigilance". You have to keep watch over your system but you also have to keep learning. Today's security tip is a list of resources to help you keep your security knowledge up to date. I've gathered together several resources for you to consider when looking for PHP Security information.
It should come as no surprise that you are already reading my #1 recommendation,
DevZone's PHP Security Tip series
! Each week we'll post a new security tip for you to ponder. These are usually small tips that you can read quickly and think about the rest of the day.
Books you should read
Essential PHP Security
Pro PHP Security
Professional PHP5 Security
php|architect's Guide to PHP Security
Finally,
php|architect magazine
is great resource and you should to consider subscribing to it. In addition to their in-depth feature articles they include a regular column each month called "Security Corner".
All of these are good resources for you to review and add to your collection to help you stay vigilant when securing your PHP application.
21. Today’s PHP security tip is short, sweet and easily actionable. It fits in well with the theme of the last one, to stay vigilant. Here’s another resource for you to consider.
If you are not already subscribed, you should subscribe to the Security Focus newsletter.
If you are not subscribed,
click here
to go to their mailing lists page and subscribe. You will see when you get there that they have 38 mailing lists, this begs the question, which one to join. The most popular and the busiest is their BugTraq list. This list is everything. Here’s their description of it.
BugTraq is a full disclosure moderated mailing list for the detailed discussion and announcement of computer security vulnerabilities: what they are, how to exploit them, and how to fix them.
Join bugtraq today and start keeping current on the vulnerabilities announced for PHP in specific and more generally, applications you may be running on your server.
When it comes to building secure applications, information is your biggest asset.
The Principle of Least Privileges
Grant permissions to users only to the level needed
This is a basic programming principal and can be seen most readily in Unix security. When dealing with users and resources in Unix, users have to be explicitly granted access to resources. Permissions are granted in such a way as to give the user the least permission necessary to gain access to the resource. We can adopt this concept when building our applications by considering carefully the users who will need to access each page and feature.
Most modern PHP frameworks have the concepts or authentication and access control. In the Zend Framework, authentication is handled by
Zend_Auth
but access control, a separate issue, is handled with
Zend_Acl
Whichever framework you use, good security practices suggest that you carefully consider the access restrictions you place on each page or feature. Whenever possible, limit access to the fewest number of users possible.
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.
13. Security is a mindset, not just something you do. It colors your application design as well as your coding. However, you also need to constantly monitor your production environment. That’s where selecting the right tool comes into play. I know I’ve mentioned
PHPSecInfo
before but I think this tool is important enough to warrant it’s own post.
PHPSecInfo
is a great tool to use to keep an eye on your production environment. It was written by Ed Finkler of
CERIAS
, the Center for Education and Research in Information Assurance and Security at Purdue University. It is officially a project of the
PHP Security Consortium
. Here’s what the PHPSecInfo homepage has to say about itself.
PHPSecInfo
provides an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.
If you need more info, here’s
the link
to a short interview with Ed talking about PHPSecInfo. Here is another
link
to the latest release notice for version 0.2.
As with all security measures, by itself it’s not the silver bullet. Used properly though, it can be part of a comprehensive solution.
14. Almost any application running PHP on the back-end uses web technologies for it’s front end. Many developers who think hard on PHP security, don’t spend a thought on front-end security for their application. Here’s a tip to think long and hard about when building your HTML and JavaScript.
Any data inside of a cookie can be potentially seen by others- restrict to a minimum
It’s a sad fact on today’s web but there are bad people out there. They want nothing more than for your application to leak sensitive data so they can exploit it. Make sure you look at the whole picture when evaluating the security of your application. This is very important when looking at what information you persist on the front end.
15. As developers, most of us are very messy. I’ve worked on countless projects and at each either run across or left a trail of diagnostic files laying around. (info.php, test.php, doMe.php, etc.) These tiles, if found by someone with nefarious intent, can leak valuable information about your system.
Today’s Security tip is:
Don’t forget to purge temporary system diagnostic files.
It would be a shame to spend all that time securing your application only to leave info.php or worse yet, a “quick piece of code” in test.php that could potentially leak dangerous information about your system. Don’t help the ad guys any more than you have to.
16. Make sure any framework you are using is updated regularly.
This is especially important if you are working on a ‘one-shot’ client project. It is important to think about who is going to maintain the site if (or rather: when) a security patch is issued for any of the 3rd party files.
Usually, these sites are placed on a shared hosting site, and that means the provider is responsible for keeping PHP, database system, web server, etc. up to date – but they will probably not maintain the frameworks you have installed.
Using frameworks is generally a good idea – not only because they take a lot of the work away from you, but also because any potential security issue will (usually) quickly be dealt with.
On the other side, this means that security issues in these frameworks are very well documented – and it is all to easy for a malicious hacker to search for old versions of the framework in use, and exploit these problems.
I have seen many, many sites which are still using extremely old and outdated files – simply because there is nobody there to update it. And I’m talking about old PEAR installs (with known issues with the ‘Mail’ component) and worse!
Even if it’s not you who has to pay the bill for excess server traffic – it might be your mailbox that receives some of the spam sent from this server!
17. Application security should not be a "when all else fails" situation. It's not something you can "put in later". As we've mentioned before, there is no single silver bullet to solve your application security issues. Security is something that should be rolling around in the back of your dead in the design phase, the coding phase, the testing phase, even after you've rolled your code into production.
Chris Shiflett
, noted PHP security expert, has a
on his web site that should be required reading for all PHP developers. Compiled by the PHP Security Consortium, this 37 page guide explains the terms and concepts involved in securing your PHP application. Here's how they describe security.
It is unfortunate that many software projects list security as a simple requirement to be met. Is it secure? This question is as subjective as asking if something is hot.
- Security must be balanced with expense.
It is easy and relatively inexpensive to provide a sufficient level of security for most applications. However, if your security needs are very demanding, because you're protecting information that is very valuable, then you must achieve a higher level of security at an increased cost. This expense must be included in the budget of the project.
- Security must be balanced with usability.
It is not uncommon that steps taken to increase the security of a web application also decrease the usability. Passwords, session timeouts, and access control all create obstacles for a legitimate user. Sometimes these are necessary to provide adequate security, but there isn't one solution that is appropriate for every application. It is wise to be mindful of your legitimate users as you implement security measures.
- Security must be part of the design.
If you do not design your application with security in mind, you are doomed to be constantly addressing new security vulnerabilities. Careful programming cannot make up for a poor design.
If security is important to you but you don't know where to start, this is a good place.
Download the PDF
and spend the hour or so reading it thoroughly. If you are already a seasoned veteran, download it and skim through it. You might pick up on something new.
18. When you allow users to upload files, your system may be at risk. Always restrict the file types that you allow. Don’t rely on a blacklist approach.
For example, a reasonable blacklist policy would seem to be Don’t allow the upload of .php files.
That’s a good policy until someone uploads a file named .htaccess. It’s not a PHP file so the blacklist won’t catch it. Placing this line in an .htaccess file and uploading it to a system only protected by a blacklist policy would open the door for the bad guys.
AddType application/x-httpd-php .php .htm
They can now upload any .htm file with PHP code in it and start poking around in your system.
For example.
Chances are good that the above code will give an attacker the name of every config file on the server. The possibilities for attacks are endless, all because of one unprotected upload form your server.
Be careful with file uploads and make sure you protect them with a whitelist policy instead. Make sure that the file that has been uploaded is of the type that you want to allow. There are several ways to do this, the easiest (and the easiest to defeat) is by checking the extension of the file uploaded. You can easily throw away any file that does not have the proper extension. However, that’s not the safest way to do it.
FOr a more secure check, look into the PECL extension,
FileInfo
. The documentation for it can be found
here
. FileInfo examins the contents of the file and tries to guess the content type based specific magic byte sequences. Using FileInfo as part of a strict whitelist policy is a much more secure way of allowing users to upload files to your system.
19. Sometimes, the best application security you can install is simply disconnecting the network cable from your server. Ok so in the real world it’s not really feasible. Thinking about it though starts you down a path that can lead to better application security.
When considering security you have to consider the hardware as well as the software. Today’s security tip comes to us from
Chris Hartjes
.
The most secure application is one with no connection to the outside world.
As we’ve covered, you can’t really disconnect the network from your web server if you are building web applications. You can however, carefully consider which servers need to be connected to the outside world and which can be inside your firewall. Beyond that, you can also evaluate how those servers that have to remain outside your firewall communicate with the ones inside.
Session Hijacking, XSS, and XSRF are all serious problems for developers and I don’t mean to minimize them. However, in many of cases, they are a means to an end. For most hackers, the pot of gold at the end of the rainbow is your database. The worst problem we as developers face today is having our application hacked, our database compromised and information that has been trusted to us by our users starting to spill out into the Net.
One simple (to explain) way to make that a little harder is to move your database server behind your firewall and limit access to it. Once you get going down this road, you will find other ideas to help secure your entire system.
This is just a short tip to get you thinking, it’s not a network security primer. I’ll leave it to you to find your quiet place today and for just a moment or two, review in your head how your physical network is structured. Think about how things are connected and consider if there’s anything you can do to make them all more secure.
Got a security tip you would like to share? Click on the
Contribute
link in the upper right corner.
20. To paraphrase an
American Patriot
"The price of security is eternal vigilance". You have to keep watch over your system but you also have to keep learning. Today's security tip is a list of resources to help you keep your security knowledge up to date. I've gathered together several resources for you to consider when looking for PHP Security information.
It should come as no surprise that you are already reading my #1 recommendation,
DevZone's PHP Security Tip series
! Each week we'll post a new security tip for you to ponder. These are usually small tips that you can read quickly and think about the rest of the day.
Books you should read
Essential PHP Security
Pro PHP Security
Professional PHP5 Security
php|architect's Guide to PHP Security
Finally,
php|architect magazine
is great resource and you should to consider subscribing to it. In addition to their in-depth feature articles they include a regular column each month called "Security Corner".
All of these are good resources for you to review and add to your collection to help you stay vigilant when securing your PHP application.
21. Today’s PHP security tip is short, sweet and easily actionable. It fits in well with the theme of the last one, to stay vigilant. Here’s another resource for you to consider.
If you are not already subscribed, you should subscribe to the Security Focus newsletter.
If you are not subscribed,
click here
to go to their mailing lists page and subscribe. You will see when you get there that they have 38 mailing lists, this begs the question, which one to join. The most popular and the busiest is their BugTraq list. This list is everything. Here’s their description of it.
BugTraq is a full disclosure moderated mailing list for the detailed discussion and announcement of computer security vulnerabilities: what they are, how to exploit them, and how to fix them.
Join bugtraq today and start keeping current on the vulnerabilities announced for PHP in specific and more generally, applications you may be running on your server.
When it comes to building secure applications, information is your biggest asset.
相关阅读 更多 +
排行榜 更多 +
