Re: [PHP] PHP Security Workbook
Chris Shiflett wrote: This news is a bit old, but I have made the workbook for my OSCON tutorial freely available from this URL: http://shiflett.org/php-security.pdf It's a 55 page PDF that has a lot of information (more than the slides) about some of the more important security topics. I hope you find it helpful. Chris I printed this out the day you sent it, but it had been sitting on my desk, unread, until today. Just got finished with it. Very helpful methods. I thank you sir. -- John C. Nichel ÜberGeek KegWorks.com 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
--- John Nichel [EMAIL PROTECTED] wrote: Chris Shiflett wrote: This news is a bit old, but I have made the workbook for my OSCON tutorial freely available from this URL: http://shiflett.org/php-security.pdf It's a 55 page PDF that has a lot of information (more than the slides) about some of the more important security topics. I hope you find it helpful. Chris I printed this out the day you sent it, but it had been sitting on my desk, unread, until today. Just got finished with it. Very helpful methods. I thank you sir. No problem - thanks for the kind feedback. :-) I'm glad you find it helpful. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
Thanks for the article Chris. Printing it out now and will read it later. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
Chris Shiflett wrote: This news is a bit old, but I have made the workbook for my OSCON tutorial freely available from this URL: http://shiflett.org/php-security.pdf It's a 55 page PDF that has a lot of information (more than the slides) about some of the more important security topics. Nice article. Most of the stuff was common sense to me (and I was glad I was doing those things unconsciously). However, I do have issue with one paragraph: Page 29, * Using POST rather than GET in forms. Specify POST in the method attribute of your forms. Of course, this isn't appropriate fot all your forms, but it is appropriate when a form is performin an action, such as buying stocks. In fact, the HTTP specification requires that GET be considered safe. Don't you mean In fact, the HTTP specification requires that POST be considered safe? Didn't make sense to me when I read it last night. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
--- Burhan Khalid [EMAIL PROTECTED] wrote: Most of the stuff was common sense to me (and I was glad I was doing those things unconsciously). That's good to hear. :-) Most of the people that have heard me give this talk (which is a few hundred now) have realized several vulnerabilities in their current applications, bad development habits, etc. I actually get tired of giving the same (or very similar) talks, but I'll keep giving this one as long as it keeps surprising a lot of the audience. The fewer excuses we give people to equate PHP with poor security, the better off we'll all be. However, I do have issue with one paragraph: Page 29, * Using POST rather than GET in forms. Specify POST in the method attribute of your forms. Of course, this isn't appropriate fot all your forms, but it is appropriate when a form is performing an action, such as buying stocks. In fact, the HTTP specification requires that GET be considered safe. Don't you mean In fact, the HTTP specification requires that POST be considered safe? Didn't make sense to me when I read it last night. Nope, it's correct as written. Perhaps it just needs to be rephrased, or maybe I need to elaborate about what safe means in this context. The piece of the HTTP specification I'm referring to is within section 9.1.1 of RFC 2616, entitled Safe Methods, and it has the following to say: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Thus, as developers, we should never perform an action when the request method is GET. This means that forms intended to perform actions such as buying stocks should specify the POST method, and we should also not rely on register_globals or $_REQUEST, because both of these hide whether the data we are using was sent in a GET request or a POST request. Specify POST, and use $_POST. Hope that clarifies what I mean a bit. Of course, I elaborate more in the actual talk; this was just the workbook for people to reference and take home to help remember the points. I just decided to give it away, since I had put so much work into it. :-) But, I'm always looking for improvements. I'll try to add a bit of clarification in there somehow. Thanks for the feedback. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
I have also read that pdf document and I have found another interesting advice. The author says that a good way of hiding the username/password is to put a file that exports 2 environment variables in a directory that can be read only by the root, then include a call to that file in httpd.conf in order to let the web server to have access to those variables. Well, I don't really understand why this is so secure. I understand that the web server is run by root, which sees that file and exports the variables, then another user without many priviledges runs the child process of the web server, but if there are more than one user that run PHP files or files made in other languages on that server, they will also be able to see those environment variables. Did I understand correctly? Teddy - Original Message - From: Chris Shiflett [EMAIL PROTECTED] To: Burhan Khalid [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, August 15, 2004 4:05 PM Subject: Re: [PHP] PHP Security Workbook --- Burhan Khalid [EMAIL PROTECTED] wrote: Most of the stuff was common sense to me (and I was glad I was doing those things unconsciously). That's good to hear. :-) Most of the people that have heard me give this talk (which is a few hundred now) have realized several vulnerabilities in their current applications, bad development habits, etc. I actually get tired of giving the same (or very similar) talks, but I'll keep giving this one as long as it keeps surprising a lot of the audience. The fewer excuses we give people to equate PHP with poor security, the better off we'll all be. However, I do have issue with one paragraph: Page 29, -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
--- Octavian Rasnita [EMAIL PROTECTED] wrote: I have also read that pdf document and I have found another interesting advice. The author says that a good way of hiding the username/password is to put a file that exports 2 environment variables in a directory that can be read only by the root, then include a call to that file in httpd.conf in order to let the web server to have access to those variables. I can't take credit for thinking of this approach. This comes from David Sklar and Adam Trachtenberg, authors of PHP Cookbook (and others). Well, I don't really understand why this is so secure. I understand that the web server is run by root, which sees that file and exports the variables, then another user without many priviledges runs the child process of the web server, but if there are more than one user that run PHP files or files made in other languages on that server, they will also be able to see those environment variables. Did I understand correctly? Yes, this is another thing that I mention in the talk but failed to include in the workbook. When this approach is being applied to a shared hosting environment, you want to put the Include directive within a VirtualHost block of httpd.conf, so that it only applies to a single virtual host. Also, each unprivileged child process that handles requests for this virtual host has this sensitive information in memory. So, while the data is safer, it is not completely safe (nothing is). If a user can exploit a vulnerability in your application that lets them execute arbitrary code, they can access this data. Of course, they can do a lot of bad things in this case. :-) Hope that clarifies. Thanks for the feedback. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security Workbook
Oh thank you for this information. This is very important for me to know. Yes, this is another thing that I mention in the talk but failed to include in the workbook. When this approach is being applied to a shared hosting environment, you want to put the Include directive within a VirtualHost block of httpd.conf, so that it only applies to a single virtual host. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP Security Workbook
This news is a bit old, but I have made the workbook for my OSCON tutorial freely available from this URL: http://shiflett.org/php-security.pdf It's a 55 page PDF that has a lot of information (more than the slides) about some of the more important security topics. I hope you find it helpful. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
