Re: [PHP] Re: PHP Security
On Tue, Jun 2, 2009 at 7:39 PM, Shawn McKenzie nos...@mckenzies.net wrote: Grant Peel wrote: Hi all, I am currently setting up the next generation web server for our company and am in need of general consulting/advice on php set up security issues. Any one with knowledge and expierience please feel free to reply :-). -Grant Do not under any circumstances put the web server on the Internet. -- Thanks! -Shawn http://www.spidean.com Furthermore, disconnect all storage media to make sure no one is able to access files that they should not access, remove any network interface cards and smash them to make sure malicious users cannot even connect to the machine, and fill any I/O ports with superglue to ensure that no one can plug any unauthorized devices. Oh, and be sure to remove the power supply to prevent local terminal access. ;-) Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
??? - Original Message - From: Shawn McKenzie nos...@mckenzies.net To: php-general@lists.php.net Sent: Tuesday, June 02, 2009 7:39 PM Subject: [PHP] Re: PHP Security Grant Peel wrote: Hi all, I am currently setting up the next generation web server for our company and am in need of general consulting/advice on php set up security issues. Any one with knowledge and expierience please feel free to reply :-). -Grant Do not under any circumstances put the web server on the Internet. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Grant Peel wrote: ??? I think you can safely assume that was a joke. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
Andrew Hutchings wrote: I prefer prepared statements and would use them all the time if it wasn't for the fact that those queries aren't cached until recent versions of MySQL 5.1 Use PDO. It emulates prepared statements and doesn't avoid the query cache: $db-setAttribute(PDO::ATTR_EMULATE_PREPARES, TRUE); For more information: http://netevil.org/blog/2006/apr/using-pdo-mysql Hope that helps. Chris -- Chris Shiflett http://shiflett.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
At 11:23 AM -0400 7/4/07, Andrew Hutchings wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED](Mark Kelly) wrote: Hi. On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. In what way? Its written by Chris Shiflett, isn't that enough reason? As will post written by you will be sufficient reason for my kill file. tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. Hollow claims are disrespectful and harmful to professional discourse. Perhaps you are motivated to persuade others that this is true and will do so at any cost, even if it means spreading misinformation. I'm aware of one person who does exactly this, so maybe you're just a victim of his propaganda. I'll give you the benefit of the doubt and assume the latter. The entire errata is published online and has been maintained very diligently: http://phpsecurity.org/errata I would argue that none of these errors constitute poor security advice, whereas I can't say the same for the other books I've read on the subject. (I don't want to disparage anyone's hard work, and feel free to discount my opinion as biased.) The errata is there for you to form your own opinion, and if you actually do know about something that isn't listed, then please disclose it. Put up, or shut up. There's nothing worse than poor security advice, but the fear of being wrong can't prevent us from sharing what we've learned. I have nothing but contempt for those who, for their own personal benefit, want to silence and discredit the people who are trying to help. The PHP community is one of the most open, friendly, and helpful communities around, and I think we are also one of the most security-conscious as a result. If you'll look through the reviews, you might notice that many leading PHP and web application security experts highly recommend it: http://phpsecurity.org/reviews Are all of these people fools, or is it really a good book? Chris -- Chris Shiflett http://shiflett.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
Hi. On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. In what way? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
In article [EMAIL PROTECTED] [EMAIL PROTECTED](Mark Kelly) wrote: Hi. On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. In what way? Its written by Chris Shiflett, isn't that enough reason? -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
On Wed, 2007-07-04 at 11:23 -0400, Andrew Hutchings wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED](Mark Kelly) wrote: Hi. On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. In what way? Its written by Chris Shiflett, isn't that enough reason? Ouch. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
Andrew Hutchings wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED](Mark Kelly) wrote: Hi. On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. In what way? Its written by Chris Shiflett, isn't that enough reason? There's no need for that without justification. Please justify that comment. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
this is getting good; i want to know why its *flawed* now too. no pressure :) -nathan On 7/4/07, Stut [EMAIL PROTECTED] wrote: Andrew Hutchings wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED](Mark Kelly) wrote: Hi. On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote: Avoid the O'Reilly one as it is flawed. In what way? Its written by Chris Shiflett, isn't that enough reason? There's no need for that without justification. Please justify that comment. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
In article [EMAIL PROTECTED]quickshift [EMAIL PROTECTED] (Nathan Nobbe) wrote: --=_Part_178329_18179255.1183569772294 Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bit Content-Disposition: inline this is getting good; i want to know why its *flawed* now too. no pressure :) OK, well, for example page 3 of the book suggests making PHP output errors into Apache's error_log. To do this on Linux it means PHP would have to be run as root. -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
Andrew Hutchings wrote: In article [EMAIL PROTECTED]quickshift [EMAIL PROTECTED] (Nathan Nobbe) wrote: --=_Part_178329_18179255.1183569772294 Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bit Content-Disposition: inline this is getting good; i want to know why its *flawed* now too. no pressure :) OK, well, for example page 3 of the book suggests making PHP output errors into Apache's error_log. To do this on Linux it means PHP would have to be run as root. huh? funny thing is that on all the machines I work with Apache runs under it own user (apart from at start up when it briefly urns as root before switching), I run php as an Apache module (I'm assuming we're not talking about php cli given that we're mentioning Apache), this means php is running in the context of the apache user ... and btw is quite capable of logging to the Apache error_log running php as a CGI probably means you can't have php (which is probably running in the context of the site owners' user account) log to the general apache error_log but in such cases I would assume that the server configuration included error and access logging on a per (v)host basis. seems like your spreading FUD - I doubt Chris Shiflett is perfect and I'm sure he's probably made a few security mistakes of his own but your current example is not one of them AFAICT. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: php security books
andrew... are you sure about this... i would have thought that if you have an apache user 'apache' and allow php to be run as/by 'apache' than this would provide complete access to anything php needs to do as 'apache'. this should definitely work if you allow the 'group' for the apache err log files be accessed by this user... so.. i ask again.. are you sure about this.. -Original Message- From: Andrew Hutchings [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 04, 2007 10:39 AM To: php-general@lists.php.net Subject: Re: [PHP] Re: php security books In article [EMAIL PROTECTED]quickshift [EMAIL PROTECTED] (Nathan Nobbe) wrote: --=_Part_178329_18179255.1183569772294 Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bit Content-Disposition: inline ??? this is getting good; i want to know why its *flawed* now too. ??? no pressure :) ??? OK, well, for example page 3 of the book suggests making PHP output errors into Apache's error_log. To do this on Linux it means PHP would have to be run as root. ??? Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: RE: [PHP] Re: php security books
the root user issue aside, i still dedicate a separate file in /var/log for my php apps. -nathan On 7/4/07, Andrew Hutchings [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED][EMAIL PROTECTED] (bruce) wrote: andrew... ¾ are you sure about this... i would have thought that if you have an apache user 'apache' and allow php to be run as/by 'apache' than this would providecomplete access to anything php needs to do as 'apache'. Logging in apache is done (in standard configurations) by process owned as root, and in most configurations the logs are owned as root and are not readable by any other user. this should definitely work if you allow the 'group' for the apache err logfiles be accessed by this user... If you do this then it is possible for a apache process using PHP to read the error logs and an abused script could show a potential hacker the layout to your site or other useful information. so.. i ask again.. are you sure about this.. Yep. Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: RE: [PHP] Re: php security books
In article [EMAIL PROTECTED][EMAIL PROTECTED] (bruce) wrote: andrew... are you sure about this... i would have thought that if you have an apache user 'apache' and allow php to be run as/by 'apache' than this would providecomplete access to anything php needs to do as 'apache'. Logging in apache is done (in standard configurations) by process owned as root, and in most configurations the logs are owned as root and are not readable by any other user. this should definitely work if you allow the 'group' for the apache err logfiles be accessed by this user... If you do this then it is possible for a apache process using PHP to read the error logs and an abused script could show a potential hacker the layout to your site or other useful information. so.. i ask again.. are you sure about this.. Yep. -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: RE: [PHP] Re: php security books
In article [EMAIL PROTECTED]quickshifti [EMAIL PROTECTED] (Nathan Nobbe) wrote: [EMAIL PROTECTED] Content-Type: text/plain; charsetãO-8859-1; format\owedContent-Transfer-Encoding: quoted-printable Content-Disposition: inline the root user issue aside, i still dedicate a separate file in /var/logfor my php apps. If is a separate file then that is cool, in fact being in /var/log you could even have it rotate with log_rotate (well you could do that anywhere really, but for completeness...). -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php security books
On Wed, Jul 04, 2007 at 11:36:06AM -0700, bruce wrote: andrew... are you sure about this... i would have thought that if you have an apache user 'apache' and allow php to be run as/by 'apache' than this would provide complete access to anything php needs to do as 'apache'. this should definitely work if you allow the 'group' for the apache err log files be accessed by this user... so.. i ask again.. are you sure about this.. Hi all... the only owner with write permissions of the logs is root! I mean the standard configuration for the apache webserver. Read permissions for groups for the apache logs can be different per distribution. You can configure your environment for the PHP processes to log in seperate files. If you allow write access for the 'group' you open the door wide for hackers. greetings Mario -- - | havelsoft.com - Ihr Service Partner für Open Source | | Tel: 033876-21 966 | | Notruf: 0173-277 33 60 | | http://www.havelsoft.com| | | | Inhaber: Mario Günterberg | | Mützlitzer Strasse 19 | | 14715 Märkisch Luch | - pgpQLSOhWvwKR.pgp Description: PGP signature
Re: [PHP] Re: PHP Security
Quoting I l [EMAIL PROTECTED]: And finally, file management is much much easier when you store the files in a database. There is a kind of database that is perfectly designed and equipped to store files, and their very specific metadata properties, optimized for the correct sort of access. That kind of database is called a FILE SYSTEM. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
I l wrote: Lets say you want to store someones picture. In the database, you would insert the picture, who owns that picture, maybe the ip address and request headers of where that picture came from, the category, sub-category, sub-sub-category in which the picture belongs to, etc. You can gather and store as much information about that picture as you want with ease. I can store all this information in a db without storing the binary image in the table too. When you want to access that file and its attributes, you only have to do one database query. I would have to do one query to get the attributes regardless if the image itself was in the db or the filesystem. Wouldn't you agree that this structure is much easier to manage than storing the file in a directory, then storing that extra information in a database? Then to retrieve, you must do a database query and find the file in the FILESYSTEM (hoping it is still there). The code is much more complex One if statement...if ( file_exists (...) ); Complex? Not at all. You should be checking it regardless if the image is in the db or not...yes, an image could be deleted off of the filesystem, and it could be deleted out of the db too. Binary data in the db could become corrupt. All kinds of things can happen. Just assuming that you don't have to check your data just because it's coming from a db isn't less complex, it's lazy, and asking for problems. In the end, it boils down to personal preference, but the filesystem is still better suited to store binary data than a db. -- 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] Re: PHP Security
I never said that this method wouldn't cause you overhead. With all respect, I am simply stating that this method is much simpler. Sometimes you must choose simplicity over processing costs. What if there was another programmer editing your code? Or, you came back to the same code after one year? You better make sure that it is documented well. So, you would prefer storing the uploaded file in your directory than a database? Have you tried either method? Lets say you want to store someones picture. In the database, you would insert the picture, who owns that picture, maybe the ip address and request headers of where that picture came from, the category, sub-category, sub-sub-category in which the picture belongs to, etc. You can gather and store as much information about that picture as you want with ease. When you want to access that file and its attributes, you only have to do one database query. ...which decomposes to multiple file system accesses. Wouldn't you agree that this structure is much easier to manage than storing the file in a directory, then storing that extra information in a database? Then to retrieve, you must do a database query and find the file in the FILESYSTEM (hoping it is still there). The code is much more complex First, I'm probably doing more system work to access the file contents as part of a database record, since the attributes of that superblobby field are different from those of the short metadata describing it. Second, I'm forcing EVERY access to that picture, even the ones by standalone non-webbish utilities that don't care about the metadata at all, to use a heavyweight database engine instead of the filesystem code embedded in the operating system... which gets used by the DBMS anyway, but less efficiently. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Quoting I l [EMAIL PROTECTED]: Lets say you want to store someones picture. In the database, you would insert the picture, who owns that picture, maybe the ip address and request headers of where that picture came from, the category, sub-category, sub-sub-category in which the picture belongs to, etc. You can gather and store as much information about that picture as you want with ease. When you want to access that file and its attributes, you only have to do one database query. ...which decomposes to multiple file system accesses. Wouldn't you agree that this structure is much easier to manage than storing the file in a directory, then storing that extra information in a database? Then to retrieve, you must do a database query and find the file in the FILESYSTEM (hoping it is still there). The code is much more complex First, I'm probably doing more system work to access the file contents as part of a database record, since the attributes of that superblobby field are different from those of the short metadata describing it. Second, I'm forcing EVERY access to that picture, even the ones by standalone non-webbish utilities that don't care about the metadata at all, to use a heavyweight database engine instead of the filesystem code embedded in the operating system... which gets used by the DBMS anyway, but less efficiently. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Quoting I l [EMAIL PROTECTED]: So, you would prefer storing the uploaded file in your directory than a database? Have you tried either method? And, by the way, once you upload it into a database, it's not a file. It's just a data field. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
I l wrote: the best security practice is to store the jpg file or any other uploaded file in your mySql database. This way you never have to worry about someone executing php by the url like www.example.com/pic.jpg. To view the file, the user would type www.example.com/veiw.php?fileID=3425433345. You can also keep information about the file uploaded in your mysql such as IP address. I cann't really see any security problems here. Yeah, with any luck at all, your binary file will corrupt itself, and then make your entire database unreadable by anybody, even you. Now *THAT'S* secure! :-) Secret Tip: There is a little-known feature of an incredibly-efficient high-volume thoroughly-tested software base that makes it very very very good at storing and retrieving large binary files such as JPEGs and other rich media with very small chance of file corruption, and even less chance of file corruption affecting other data or applications. I'm not really sure I should tell you about this great secret feature, but I guess I might as well... It's called the File System and it's packaged with your Operating System. :-) Storing JPEGs in your database instead of the file system is like keeping your groceries in the trunk of your car outside in the winter instead of in the fridge. It will work, but it's not really the best idea. YMMV -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Yeah, with any luck at all, your binary file will corrupt itself, and then make your entire database unreadable by anybody, even you. really? Then my companies database should be corrupt by now...right? Haven't had any problems yet. Well, its only been running for 2 years now. I l wrote: the best security practice is to store the jpg file or any other uploaded file in your mySql database. This way you never have to worry about someone executing php by the url like www.example.com/pic.jpg. To view the file, the user would type www.example.com/veiw.php?fileID=3425433345. You can also keep information about the file uploaded in your mysql such as IP address. I cann't really see any security problems here. Yeah, with any luck at all, your binary file will corrupt itself, and then make your entire database unreadable by anybody, even you. Now *THAT'S* secure! :-) Secret Tip: There is a little-known feature of an incredibly-efficient high-volume thoroughly-tested software base that makes it very very very good at storing and retrieving large binary files such as JPEGs and other rich media with very small chance of file corruption, and even less chance of file corruption affecting other data or applications. I'm not really sure I should tell you about this great secret feature, but I guess I might as well... It's called the File System and it's packaged with your Operating System. :-) Storing JPEGs in your database instead of the file system is like keeping your groceries in the trunk of your car outside in the winter instead of in the fridge. It will work, but it's not really the best idea. YMMV -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Yeah, with any luck at all, your binary file will corrupt itself, and then make your entire database unreadable by anybody, even you. really? Then my companies database should be corrupt by now...right? Haven't had any problems yet. Well, its only been running for 2 years now. Search the archives. There are known instances of what I described happening. I'm not claiming it's common. It's *more* common than a single corrupt file in the file system trashing the entire file system, taking all your data with it. What exactly does storing the binary file in SQL get you? Does your SQL search through the binary data doing a face-recognition match in some customer MySQL library code to find criminals by facial features? [shrug] -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Quoting Richard Lynch [EMAIL PROTECTED]: Actually, internally, it *is* a file, or part of a file, depending on the database implementation details. (*) Part of a file? Usually. A file? Rarely. And as part of a file, it is likely to be accessed using a more poorly chosen I/O model than if it were in a standalone file. So you're adding overhead into the storage and retrieve of your content for some unspecified (so far) benefit. The benefit is clear. If the so-called file is only going to be used by a single PHP-plus-database application and never passed to a normal OS command that operates on files, cool. If it is to be accessed by multiple methods, especially by normal OS-level processes, extracting it from a database into a temporary file so it can be accessed by those commands each time is ridiculous. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
[EMAIL PROTECTED] wrote: Quoting I l [EMAIL PROTECTED]: So, you would prefer storing the uploaded file in your directory than a database? Have you tried either method? And, by the way, once you upload it into a database, it's not a file. It's just a data field. Actually, internally, it *is* a file, or part of a file, depending on the database implementation details. (*) So you're adding overhead into the storage and retrieve of your content for some unspecified (so far) benefit. * I'm sure somebody somewhere is storing their entire db in RAM or on Flash or whatever, but let's stick to the common usage here. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
I beleive the performance hit is much higher than the %2 increase you
are refering to:
$ cat /.../loadtest.php
?php
header('Content-Type: image/png');
readfile('placeholderimage.png');
?
$ ./ab -n 1000 -c 50 http://.../loadtest.php
Time taken for tests: 1.653 seconds
Complete requests: 1000
...
Requests per second:604.96 [#/sec] (mean)
Time per request: 82.65 [ms] (mean)
Time per request: 1.65 [ms] (mean, across all concurrent requests)
Transfer rate: 15177.50 [Kbytes/sec] received
$ ./ab -n 1000 -c 50 http://.../placeholderimage.png
Time taken for tests: 0.809 seconds
Complete requests: 1000
...
Requests per second:1236.09 [#/sec] (mean)
Time per request: 40.45 [ms] (mean)
Time per request: 0.81 [ms] (mean, across all concurrent requests)
Transfer rate: 30854.14 [Kbytes/sec] received
Apache 1.3.31, PHP 5.0.2
As you can see, once you move past the single request point, and
actually occupy the server for a few moments the hit is far more than
2%.
paul
--
Paul Reinheimer
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
I l wrote: Lets say you want to store someones picture. Okay. In the database, you would insert the picture, who owns that picture, maybe the ip address and request headers of where that picture came from, the category, sub-category, sub-sub-category in which the picture belongs to, etc. You can gather and store as much information about that picture as you want with ease. Except I can't just insert the picture. I need to store it as a BLOB, which requires a lot more code. When you want to access that file and its attributes, you only have to do one database query. Plus another chunk of code for the BLOB. Wouldn't you agree that this structure is much easier to manage than storing the file in a directory, then storing that extra information in a database? No, I would not agree at all. Then to retrieve, you must do a database query and find the file in the FILESYSTEM (hoping it is still there). The code is much more complex Actually, it's a whole lot simpler. If I use some kind of key (such as the auto_increment field) in my filename, I might not even need to query the database to find the image I want -- I already know the filename just from the key. Depends on the application, of course, and the privacy/security of the image and its related data. And finally, file management is much much easier when you store the files in a database. What have you been smoking? unlink is that much harder than a destroying a BLOB? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
I agree with the fact that apache is very secure. I also agree with you that you shouldn't be 100% comfortable with apache security because there is always a chance of a security flaw. But, how many beginner and intermediate PHP developers really know how to configure Apache for optimal security? And how many of those even have access to the Apache configurations? How many of those don't keep upto date with Apache updates and upgrades? As you probably know, it isn't apache or php that is insecure, it is the programmers ignorance that causes problems. I am suggesting that a PHP programmer should write a script to store the files in a database because they will have absolute control over file storage. Although they might now be so confident with thier apache configurations, they should be more confident with thier own code. Since this script will be simple to write and have only three operations (uploading, downloading, checkfile), security flaws will be easier to spot. Therefor a PHP programmer who doesn't really know how to securely configure apache would not have to worry too much about a hacker figuring out a way to upload a file and execute it on the server. And finally, file management is much much easier when you store the files in a database. From: Chris Shiflett [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: I l [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Date: Thu, 9 Dec 2004 18:38:49 -0800 (PST) MIME-Version: 1.0 Received: from pb1.pair.com ([216.92.131.4]) by mc8-f13.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 9 Dec 2004 18:42:23 -0800 Received: (qmail 24556 invoked by uid 1010); 10 Dec 2004 02:38:54 - Received: (qmail 24461 invoked by uid 1010); 10 Dec 2004 02:38:54 - X-Message-Info: JGTYoYF78jF3H/0o7K18tM9GRjbrgnXY Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-RocketYMMF: catfishhacker Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 10 Dec 2004 02:42:23.0070 (UTC) FILETIME=[E05E7FE0:01C4DE61] --- I l [EMAIL PROTECTED] wrote: the best security practice is to store the jpg file or any other uploaded file in your mySql database. This way you never have to worry about someone executing php by the url like www.example.com/pic.jpg. To view the file, the user would type www.example.com/veiw.php?fileID=3425433345. That's the best? :-) While I have a great deal of confidence in my code as well, I find it odd that you trust your own PHP code more than something like Apache, which has been tested by millions of people worldwide and is very mature. I would argue that it's more likely that you'll make a mistake in view.php than it is that you will misconfigure Apache to process images as PHP. Security is all about knowing what you can trust and what you cannot. A mistrust of everything (paranoid security) is not a good solution, and when there is a choice, the one with less risk is more secure. In this case, I don't agree with your decision. I would put my trust in Apache. I cann't really see any security problems here. There are security concerns with everything, even if they're hypothetical (e.g., even when you can't discover an exploit). Be careful not to ever get too comfortable. :-) Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming Soon http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Lets say you want to store someones picture. In the database, you would insert the picture, who owns that picture, maybe the ip address and request headers of where that picture came from, the category, sub-category, sub-sub-category in which the picture belongs to, etc. You can gather and store as much information about that picture as you want with ease. When you want to access that file and its attributes, you only have to do one database query. Wouldn't you agree that this structure is much easier to manage than storing the file in a directory, then storing that extra information in a database? Then to retrieve, you must do a database query and find the file in the FILESYSTEM (hoping it is still there). The code is much more complex And finally, file management is much much easier when you store the files in a database. There is a kind of database that is perfectly designed and equipped to store files, and their very specific metadata properties, optimized for the correct sort of access. That kind of database is called a FILE SYSTEM. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Quoting I l [EMAIL PROTECTED]: I never said that this method wouldn't cause you overhead. With all respect, I am simply stating that this method is much simpler. Sometimes you must choose simplicity over processing costs. What if there was another programmer editing your code? Or, you came back to the same code after one year? You better make sure that it is documented well. I'm not argiung that programming simplicity and efficiency should be sacrificed to system efficiency. I'm arguiing that your perspective is one that assumes that files will only ever be touched by a PHP application doing database queries. I believe file system interactions -- especially in a domain where files may be used by different applications -- are better understood and better known than they are database interactions. So, you would prefer storing the uploaded file in your directory than a database? Have you tried either method? Yes, of course. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
On Fri, 10 Dec 2004 14:07:21 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: And, by the way, once you upload it into a database, it's not a file. It's just a data field. And the data fields are just files on the file system. Look at the way Postgres stores data. The filesystem itself is just a low level database. I make these sort of choices by benchmark whenever possible: http://www.zend.com/zend/trick/tricks-sept-2001.php -- Greg Donald Zend Certified Engineer http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Also, you *SHOULD* force the file to be saved on your server
with the correct extension. If a user can upload a JPEG with
.php on the end, or worse, with php in the middle of the
filename, and then your server puts that file in the web tree or
otherwise allows it to be executed, *YOU* (and your server
admin) screwed up your security, not PHP.
Trusting the name provided by the client is certainly a bad practice, but
I wouldn't consider php in the middle of a filename to be worse than
extension manipulation. I'm not sure what gave you that idea, but it's
just not true.
The original article, in another newsgroup/list, referenced a server seen
by that author, where the SysAdmin had configured the server to use PHP to
parse any file whose name contained 'php'.
Not ending in '.php' ('.php$')
Nor even ending in 'php' ('php$')
But containing 'php' ('.*php.*').
phplogo.jpg, when surfed to, went through PHP.
Real-life problem.
Yes, that's a horribly-configured server.
No, I don't think you'd have that on your server.
But I'd bet at least one reader on this list misunderstands the Apache
Files directive (with and without the ~) badly enough that they've got
this gaping hole on their server.
Now combine that with putting uploaded JPEGs in the web tree, and what
have you got?
My grammar in my post incorrectly put the 'or worse' near 'php in the
middle' when it should have been near 'your server ... allows it to be
executed'
The real culprit, is, of course, the mis-configured server.
But it takes two to tango, here, and throwing the JPEGs in the web tree
should not be done unless you *NEED* to do that, for performance, after
due consideration and a security audit to be *SURE* that the JPEGs cannot
ever possibly get executed as PHP.
Under *NO* circumstances should a file uploaded by an
untrusted user be put into your web tree. You should *KEEP* it
outside the web tree, and use PHP to http://php.net/readfile it
when it needs to be displayed. Since you are using PHP's
readfile function to *READ* the file, Apache won't have any
chance to get fooled into thinking it's supposed to be a PHP file
and be parsed by PHP.
This is misleading. It is fine to put uploaded files within document root,
and in fact many applications may require this. Using readfile() is not
realistic except for small sites - the performance penalty alone makes
this a poor approach, since it provides very little value.
That being said, it's true that you should not trust the name provided by
the client (or anything provided by the client), but this is much
different than blind paranoia. If this perspective were applied to HTML
forms, no one could use them.
You don't take raw data from HTML forms and save the field values into
your web tree do you?
You scrub the incoming data from the web form and make sure, as much as
possible for the given field, that it is benign, right? And you certainly
don't http://php.net/eval that untrusted data from a user, do you?
Then why in the world would you take an untrusted, unscrubbable, binary
file and shove it into your web-tree?!
Can you be 100% certain that ?php /* bad code here */ ? is not embedded
in the JPEG? How? getimagesize() will tell you the JPEG headers are
kosher, but not confirm that the JPEG itself is really really just JPEG
data.
Even viewing it would only, at best, show you an ugly JPEG.
You could egrep for ?php.*?, and assume that that's not valid in any
JPEG, but it probably actually *IS* valid in at least one real JPEG -- And
if you allow JPEG comments, it would be trivial to have a zillion JPEGs
that would pass any automated validation of JPEG-ness that have PHP code
in the comment.
What's to stop the bad guy from taking a valid JPEG, cramming PHP code
into it, and then surfing to the image directly in such a way that the PHP
code gets executed?
Sure, your server configuration almost for sure doesn't have .jpg files
going through the PHP parser. But if they can find a way to force that to
happen:
Altering an .htaccess file somewhere, or forcing one to be uploaded.
Finding an old cgi-bin setup on the server.
Getting the CLI PHP to execute the JPG as a script.
It's hard to imagine that last one without them being able to just TYPE a
PHP script, mind you, but some whack 'sudo' setup might do it. Think
every SysAdmin who uses sudo really understands sudo completely?
Hopefully, none of these things can be done on your server. If you are
100% certain that none of these could ever possibly occur, then you are
confident that the JPEGs with PHP embedded will only be ugly JPEGs.
But if there is any doubt in your mind that a malicious user could manage
to get the JPEG to be passed through PHP (or Perl or ...) then you've got
a risk there that may not be obvious to the casual
Reader/Sysadmin/Programmer.
Busy servers may have a performance problem with using the readfile
solution -- But that's no excuse to expose that busy server by just
throwing an
Re: [PHP] Re: PHP Security
Chris Shiflett wrote: --- Greg Donald [EMAIL PROTECTED] wrote: http://seclists.org/lists/security-basics/2004/Dec/0080.html Most of this is actually true. The one statement that is unclear is the following: There are two kinds of flaws : - flaws inherent to the php langage itself, as seen before, in file uploads. - danger in uploading files at all on the server, not dependent on the langage used to handle the actual upload, but regarding the potential execution of uploaded files. This may have meant meant hypothetically, meaning that there are two areas where flaws could potentially exist - in the language or in the code. If this was meant to suggest that there are existing flaws in the language, then this is never justified. I didn't find the statemtn to be unclear: that kind of flaw can exist, and it has been seen. There was, unless I've been severely misinformed, a file upload security bug in a PHP 4 Beta (possibly even Release Candidate). Did it make it to release? I'm sure anybody on this list can dig out that answer as fast as I, so I won't. You'll learn more finding out for yourself anyway. Now, granted, that flaw was fixed IMMEDIATELY. And, granted, a SysAdmin who chooses to put Beta software on a server is responsible for the inherent risks involved. The point, however, that such potential flaws can exist, and could remain undetected even now in stable, released code (even PHP) is valid. I personally don't *believe* such flaws could have survived the scrutiny after the known problems were suffered by the PHP Development Team. But I don't think any professionial will claim that it's impossible for them to exist. PS For the inexperienced reader: This is, as far as I know, the ONLY known security flaw in actual PHP C source code to get anywhere near release form. But PHP is a powerful tool, and there are innumerable ways it can be used, mis-used, and just plain abused by yourself to make your own server insecure. Do the best you can to figure out how and when, and you'll do all right. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Richard Lynch wrote: Chris Shiflett wrote: --- Greg Donald [EMAIL PROTECTED] wrote: http://seclists.org/lists/security-basics/2004/Dec/0080.html Most of this is actually true. The one statement that is unclear is the following: There are two kinds of flaws : - flaws inherent to the php langage itself, as seen before, in file uploads. - danger in uploading files at all on the server, not dependent on the langage used to handle the actual upload, but regarding the potential execution of uploaded files. This may have meant meant hypothetically, meaning that there are two areas where flaws could potentially exist - in the language or in the code. If this was meant to suggest that there are existing flaws in the language, then this is never justified. I didn't find the statemtn to be unclear: that kind of flaw can exist, and it has been seen. There was, unless I've been severely misinformed, a file upload security bug in a PHP 4 Beta (possibly even Release Candidate). Did it make it to release? I'm sure anybody on this list can dig out that answer as fast as I, so I won't. You'll learn more finding out for yourself anyway. snip I'm pretty sure Chris is one who doesn't have to dig to find out about an old security flaw. -- 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] Re: PHP Security
the best security practice is to store the jpg file or any other uploaded file in your mySql database. This way you never have to worry about someone executing php by the url like www.example.com/pic.jpg. To view the file, the user would type www.example.com/veiw.php?fileID=3425433345. You can also keep information about the file uploaded in your mysql such as IP address. I cann't really see any security problems here. From: John Nichel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Date: Thu, 09 Dec 2004 15:53:50 -0500 MIME-Version: 1.0 Received: from pb1.pair.com ([216.92.131.4]) by mc5-f30.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 9 Dec 2004 13:36:24 -0800 Received: (qmail 37281 invoked by uid 1010); 9 Dec 2004 20:53:56 - Received: (qmail 36970 invoked by uid 1010); 9 Dec 2004 20:53:55 - X-Message-Info: JGTYoYF78jEvCuJhLNo8y5HpJ5uTOZsH Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 09 Dec 2004 21:36:24.0772 (UTC) FILETIME=[21F88840:01C4DE37] Richard Lynch wrote: Chris Shiflett wrote: --- Greg Donald [EMAIL PROTECTED] wrote: http://seclists.org/lists/security-basics/2004/Dec/0080.html Most of this is actually true. The one statement that is unclear is the following: There are two kinds of flaws : - flaws inherent to the php langage itself, as seen before, in file uploads. - danger in uploading files at all on the server, not dependent on the langage used to handle the actual upload, but regarding the potential execution of uploaded files. This may have meant meant hypothetically, meaning that there are two areas where flaws could potentially exist - in the language or in the code. If this was meant to suggest that there are existing flaws in the language, then this is never justified. I didn't find the statemtn to be unclear: that kind of flaw can exist, and it has been seen. There was, unless I've been severely misinformed, a file upload security bug in a PHP 4 Beta (possibly even Release Candidate). Did it make it to release? I'm sure anybody on this list can dig out that answer as fast as I, so I won't. You'll learn more finding out for yourself anyway. snip I'm pretty sure Chris is one who doesn't have to dig to find out about an old security flaw. -- 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
--- I l [EMAIL PROTECTED] wrote: the best security practice is to store the jpg file or any other uploaded file in your mySql database. This way you never have to worry about someone executing php by the url like www.example.com/pic.jpg. To view the file, the user would type www.example.com/veiw.php?fileID=3425433345. That's the best? :-) While I have a great deal of confidence in my code as well, I find it odd that you trust your own PHP code more than something like Apache, which has been tested by millions of people worldwide and is very mature. I would argue that it's more likely that you'll make a mistake in view.php than it is that you will misconfigure Apache to process images as PHP. Security is all about knowing what you can trust and what you cannot. A mistrust of everything (paranoid security) is not a good solution, and when there is a choice, the one with less risk is more secure. In this case, I don't agree with your decision. I would put my trust in Apache. I cann't really see any security problems here. There are security concerns with everything, even if they're hypothetical (e.g., even when you can't discover an exploit). Be careful not to ever get too comfortable. :-) Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming Soon http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
On Wed, 8 Dec 2004 08:42:50 -0500, Joshua Beall [EMAIL PROTECTED] wrote: Can you also provide a link to the relevant message in the mailing list archive? I would like to read this myself. http://seclists.org/lists/security-basics/2004/Dec/0080.html -- Greg Donald Zend Certified Engineer http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
Greg Donald wrote: On Wed, 8 Dec 2004 08:42:50 -0500, Joshua Beall [EMAIL PROTECTED] wrote: Can you also provide a link to the relevant message in the mailing list archive? I would like to read this myself. http://seclists.org/lists/security-basics/2004/Dec/0080.html Everything described herein falls under his second category of flaw, which, loosely translated, is Bad Programming Nowhere does he address the first category of flaw of an inherent flaw in PHP file uploads, which *HAS* been seen before, but was patched by the PHP Developers within hours of discovery. Some minor nit-picking and more advice: I personally think that if you can't upload your images outside your web tree then, in fact, your server admin is at fault for not providing you a directory structure that allows that. Good security requires cooperation from both admin and Programmer. If your webhost does not provide you with a directory outside your web tree, switch hosts *NOW*. I can personally recommend http://hostbaby.com, but there are a few million more providers who will do this right for you. Also, you *SHOULD* force the file to be saved on your server with the correct extension. If a user can upload a JPEG with .php on the end, or worse, with php in the middle of the filename, and then your server puts that file in the web tree or otherwise allows it to be executed, *YOU* (and your server admin) screwed up your security, not PHP. And, yes, you *SHOULD* use http://php.net/getimagesize to at least be sure the beginning portion of the file is an image. That function won't guarantee that the image didn't have PHP tacked embedded in the image file, but at least you'll weed out people trying to upload files that can't even pretend to be an image file. Under *NO* circumstances should a file uploaded by an untrusted user be put into your web tree. You should *KEEP* it outside the web tree, and use PHP to http://php.net/readfile it when it needs to be displayed. Since you are using PHP's readfile function to *READ* the file, Apache won't have any chance to get fooled into thinking it's supposed to be a PHP file and be parsed by PHP. All of this is up to a cooperative effort on the part of the sysadmin and the programmer of a site: The PHP Development Team can only do so much to keep you from doing something dangerous, just as Detroit can only do so much to keep you from driving unsafely. There are *WAY* too many sites out there that do this wrong, because Programmers can't be bothered learning their craft and understanding Security issues. My opinion on such programmers is unprintable. :-) This is not rocket science, folks. Somebody you don't trust shouldn't be allowed to dump crap into your web space willy-nilly. That's a Duh if you ask me. Granted, how to make it hard for them to do that is not all that simple, but the basic idea is quite plain, and having enough sense to FIND OUT how to make it hard is a no-brainer. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
--- Greg Donald [EMAIL PROTECTED] wrote: http://seclists.org/lists/security-basics/2004/Dec/0080.html Most of this is actually true. The one statement that is unclear is the following: There are two kinds of flaws : - flaws inherent to the php langage itself, as seen before, in file uploads. - danger in uploading files at all on the server, not dependent on the langage used to handle the actual upload, but regarding the potential execution of uploaded files. This may have meant meant hypothetically, meaning that there are two areas where flaws could potentially exist - in the language or in the code. If this was meant to suggest that there are existing flaws in the language, then this is never justified. Another misleading suggestion is that all uploaded files should be stored outside of document root. Not only is this not possible in some cases (if your application depends on this for some reason), it's also not a large risk. The point to take from this, however, is that if you don't necessarily need a file within document root (and the only reason is that you need a URL to be associated with the file), don't put it there. A risk is still a risk, and an unnecessary risk is always a poor choice. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming Soon http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security
--- Richard Lynch [EMAIL PROTECTED] wrote: I personally think that if you can't upload your images outside your web tree then, in fact, your server admin is at fault for not providing you a directory structure that allows that. Good security requires cooperation from both admin and Programmer. I agree with both of these points. In fact, if the temporary upload directory is within document root, there exists a security vulnerability, regardles of the code. I can upload a file to any PHP script, and PHP provides the script with the $_FILES superglobal array, including the temporary name and location of the file that I uploaded. You don't have to actually use $_FILES for this to happen. Also, you *SHOULD* force the file to be saved on your server with the correct extension. If a user can upload a JPEG with .php on the end, or worse, with php in the middle of the filename, and then your server puts that file in the web tree or otherwise allows it to be executed, *YOU* (and your server admin) screwed up your security, not PHP. Trusting the name provided by the client is certainly a bad practice, but I wouldn't consider php in the middle of a filename to be worse than extension manipulation. I'm not sure what gave you that idea, but it's just not true. Under *NO* circumstances should a file uploaded by an untrusted user be put into your web tree. You should *KEEP* it outside the web tree, and use PHP to http://php.net/readfile it when it needs to be displayed. Since you are using PHP's readfile function to *READ* the file, Apache won't have any chance to get fooled into thinking it's supposed to be a PHP file and be parsed by PHP. This is misleading. It is fine to put uploaded files within document root, and in fact many applications may require this. Using readfile() is not realistic except for small sites - the performance penalty alone makes this a poor approach, since it provides very little value. That being said, it's true that you should not trust the name provided by the client (or anything provided by the client), but this is much different than blind paranoia. If this perspective were applied to HTML forms, no one could use them. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming Soon http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions4.2.0
On Wed, 24 Jul 2002, Scott Fletcher wrote:
It work very nicely The whole process take 30 to 45 minutes for just
one server. I wonder how does someone did 12 computers in 10 minutes.
Cool!
cd /usr/src/local
tar -zxf php-4.2.2.tar.gz
cd php-4.2.2
../php-4.2.1/config.nice
make install
for i in server1 server2 server3 server4 server5 serverN
scp ../apache_1.3.26/src/httpd ${i}:/usr/local/apache/bin/
Most of the time was watching 'make install'.
miguel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Doing that right now! Just like a basic upgrade. Thanks, FletchSOD Matt Schroebel [EMAIL PROTECTED] wrote in message 4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3">news:4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3... From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Rebuilding from source: 1. download the new php source, extract it to whereever you do. 2. cd to php-4.2.2 copy config.nice from your existing php compile dir (this has your previous complies config command). 3. Run it: ./config.nice 4. make 5. apachectl stop 6. make install 7a. i. If php is a DSO: ii. apachectl start (you're done) 7b. i. If php is compiled into apache: ii. cd to apache compile dir iii. make clean iv. ./config.status v. make vi. make install vii. apachectl start (you're done) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
It work very nicely The whole process take 30 to 45 minutes for just one server. I wonder how does someone did 12 computers in 10 minutes. Cool! Matt Schroebel [EMAIL PROTECTED] wrote in message 4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3">news:4B08FD7DB3CBD4119F560002A508C453015B38DA@hsus3... From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Rebuilding from source: 1. download the new php source, extract it to whereever you do. 2. cd to php-4.2.2 copy config.nice from your existing php compile dir (this has your previous complies config command). 3. Run it: ./config.nice 4. make 5. apachectl stop 6. make install 7a. i. If php is a DSO: ii. apachectl start (you're done) 7b. i. If php is compiled into apache: ii. cd to apache compile dir iii. make clean iv. ./config.status v. make vi. make install vii. apachectl start (you're done) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
On Wednesday 24 July 2002 22:22, Scott Fletcher wrote: It work very nicely The whole process take 30 to 45 minutes for just one server. You've got a slow computer and/or you type too slow ;-) I wonder how does someone did 12 computers in 10 minutes. Cool! For me it was a case of 'typing' in 6 commands: 1) download php 2) untar it 3) cd 4) configure 5) make 6) make install Actually I just copy and pasted those commands which took me all of 5 seconds to do. So unless you count the download and compilation time, 12 systems in 10 minutes is in the ballpark. -- Jason Wong - Gremlins Associates - www.gremlins.com.hk Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* Yow! I just went below the poverty line! */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
At 10:22 AM 7/24/02 -0400, Scott Fletcher wrote: It work very nicely The whole process take 30 to 45 minutes for just one server. I wonder how does someone did 12 computers in 10 minutes. Cool! For me the key to upgrading many servers is to compile once then copy the resulting files to all my other servers. I also compile Apache + mod_ssl + PHP static into one file so usually all I have to do is copy the httpd file to the other machines. The machines need similar CPUs and identical library versions, but that isn't too hard to do. With Linux it is legal to copy in the new httpd file then apachectl restart to update the server. Rick -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Adam Alkins [EMAIL PROTECTED] wrote in message 050a01c231c2$d483f770$aa9303c4@alkins">news:050a01c231c2$d483f770$aa9303c4@alkins... Any real programmer should know that almost nothing is bug free, even if you test it beyond your imagination. Something is always going to elude you and be found by someone experimenting down the road. For the widespread use of PHP, I'm rather impressed by the small amount of vunerabilities discovered in PHP so far. Some humans are just never ever satisfied... -- Adam Alkins http://www.rasadam.com -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Amended to this recent posting. Already started a new posting from scratch. Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Adam Alkins [EMAIL PROTECTED] wrote in message 050a01c231c2$d483f770$aa9303c4@alkins">news:050a01c231c2$d483f770$aa9303c4@alkins... Any real programmer should know that almost nothing is bug free, even if you test it beyond your imagination. Something is always going to elude you and be found by someone experimenting down the road. For the widespread use of PHP, I'm rather impressed by the small amount of vunerabilities discovered in PHP so far. Some humans are just never ever satisfied... -- Adam Alkins http://www.rasadam.com -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 I don't know how to appy patches to the PHP software. I just finish upgrading the website to work with PHP 4.2.1 from PHP 4.0.6. And now this So, just patched it then configure openssl, mycrypt, curl, modssl then do the usual stuff for PHP then apache, right?? Rebuilding from source: 1. download the new php source, extract it to whereever you do. 2. cd to php-4.2.2 copy config.nice from your existing php compile dir (this has your previous complies config command). 3. Run it: ./config.nice 4. make 5. apachectl stop 6. make install 7a. i. If php is a DSO: ii. apachectl start (you're done) 7b. i. If php is compiled into apache: ii. cd to apache compile dir iii. make clean iv. ./config.status v. make vi. make install vii. apachectl start (you're done) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
If all you're doing is applying the patch (not adding/removing any extensions), you should be able to use ./config.nice which will use all of the configuration commands from your last compile (This is an extremely handy thing if your GD/Freetype setup was particularly ornery the first time around! ;) ) -Andy -Original Message- From: Ricky Dhatt [mailto:[EMAIL PROTECTED]] ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-ldap make make install /usr/local/apache/bin/apachectl restart Hmm...is the configure step really necessary? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions4.2.0
The correct path for the windows binary version is http://www.php.net/do_download.php?download_file=php-4.2.2-Win32.zip /lasso ([EMAIL PROTECTED]) Rouvas Stathis wrote: Hi all, Just wanting to notify everyone that the link for the PHP.4.2.2 download is broken. -Stathis. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Hi all, Just wanting to notify everyone that the link for the PHP.4.2.2 download is broken. -Stathis. -- Rouvas Stathis [EMAIL PROTECTED] http://www.di.uoa.gr/~rouvas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0
Any real programmer should know that almost nothing is bug free, even if you test it beyond your imagination. Something is always going to elude you and be found by someone experimenting down the road. For the widespread use of PHP, I'm rather impressed by the small amount of vunerabilities discovered in PHP so far. Some humans are just never ever satisfied... -- Adam Alkins http://www.rasadam.com -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
