yep you are exactly correct. and by that way they executed the .php needed to run the trojan and then executed the trojan and they were in and pretty much did whatever I guess.

But please since you seem to know what the problem is, please explain how I can fix this to be more secure? As I said im php illitrate, so as I mentioned the "allow_url_fopen = off" command I read would disallow people from executing other .php files period but from what Im guessing is, my code still has to be fixed in some way?

As well as I dont even know where to put the "allow_url_fopen = off" line and how exactly it should be setup.

    I don't know myself how your hosting is setup but my guess is you can't turn it off. Only your network administrators can as this is a php config file directive (google php.ini) You could try setting it off through ini_set. However, the real problem is that code. Never let any variable be set externally. Especially when it is part of a parameter for a function that employs allow-url-fopen. If you want a quick fix (allthough I still discourage dynamic include paths), you might try code such as

    <?php
    
    $array['users'] = '/viewusers.php';
    $array['home'] = '/gohome.php';
    $array['update'] = '/updatethings.php';
    $array['delete'] = '/deletestuff.php';
    
    if ( array_key_exists($_GET['id']),$array) ) {
    	include($array[$_GET['id']]);
    } else {
    	include('index.php');
    }
    
    ?>

    This allows you to explicitly control which files can be included via a URL parameter.

      ok thats some good info there thank you. My home directory holds the php.ini file in which i can change the .php options myself altho nowhere in that file was I able to find the "allow_url_fopen" line for that option at all. I guess I would manually have to add that line in there once I get a dedicated IP addess? Also currently I have the php.ini file in the main directory with my main .php file's, i do have folders where I keep other .php files should I be coopying this php.ini file to every directory containing php files?

      Thanx again for your replys.

        Never let any variable be set externally.

        While I agree that external variables need to be treated carefully, this is just an important aspect of a lot of code. One easy example is search engines using externally set variables:

        http://www.google.com/search?q=bees

        Q can be manipulated by anyone and Q is both useful and not dangerous. It isn't where the variables come from, it is how you are using the variables and how you are treating ones that could be abused.

        what you can't do is leave a door open like you've done here. One alternative is:

        <?php 
        
        if($id=='about'){ 
        	include('about.php');
        }elseif($id=='links'){
        	include('about.php');
        }else{
        	include('home.php');
        }
        ?>
        

        with the above, someone putting in www.mysite.com?id=http://evilhacks.com would just get your home page.

        ps. you don't need a dedicated ip to use include(), so they are either confused or lying.

          thank you for that info, they were not saying i cant use include without a dedicated IP, they were saying the line that protects the PHP code which is the "allow_url_fopen = off" in which case when set to OFF wont allow php files to be executed from another url, that requires a dedicated IP address apparently because it needs to have a certain port open for it to function from what I understand.

            I'm no expert, but you shouldn't need a port open to turn off allow_url_fopen😕 . You should be able to turn off allow_url_fopen in the php.ini file you found, that should take care of things. or you can put the following into your .htaccess file:

            # set register globals off
            php_value register_globals 0
            
            # set allow_url_fopen off
            php_value allow_url_fopen 0

            I've never heard of anyone having to pay change their settings, but then again I haven't heard that it never happens either.

              Yes I dont know whats up I think that one tech was smoking somethin, I spoke to a next tech who didnt say anything about ports or nothing about paying extra but either way I already had a dedicated IP address so im fine anyhow. He did state that he had to do it tho, as like I said I couldnt find that option in my php.ini so it took him all 10 seconds to do it and he showed me that it was off by me viewing my phpinfo. So now in theory they shouldnt be able to execute any files from another URL, so thats one thing down couple more to go...

              I was wondering tho, since you seem familiar with that php.ini file do you have any suggestions for any other options I should check for in there wether they should be on or off?

              Next I always had my php files with the 644 setting, is that sufficent and safe?

              Now looking at the code you suggested and code bretticus provided as well, does setting it up with arrays give any more benefit or more security or is it all the same thing and is pretty safe? I see bretticus mentioned that he doesnt suggest doing dynamic include paths which both of these do, how would I go about not doing it dynamicly? Because if it isn't too hard I would love to have my page as secure as possible so this doesnt happen again.

              Thank you both very much once again for all the answers your providing, you guys are truly life savers and I appreciate the time your taking to talk to me, I have learned a lot alread since I started this topic.

                jigga wrote:

                <?php if($id == "") { include("home.php"); } else { include("$id.php"); } ?>

                Rule #1 when using globals, always clean them using stripslashes, a custom function real_escape or real_escape_string and specifiy GET or POST as well.

                  Why is a 3rd Party hosting provider allowing allow_url_fopen off to be enabled, I've never seen that in my entire experiance on the web using hosting companies for my sites.

                    allow_url_fopen is a perfectly safe option to enable; it should always be enabled as it's highly useful.

                    On the other hand, the inherent problem is people doing include($some_user_supplied_value).

                    This is an absolutely inexcusable technique and should not even be CONSIDERED for use in a production application.

                    Even with fopen_url off, poor code can still result in your application being compromised.

                    Fortunately, in PHP 5.2 allow_url_fopen has been split into two: allow_url_fopen and allow_url_include - the latter of which is off by default and there is no reason for EVER enabling it.

                    As I suggested earlier, a server which has been compromised in any way should immediately be taken down, reinstalled from scratch and have everything restored from a backup before the compromise, or from somewhere unaffected (e.g. dev server)

                    Mark

                      # set register globals off
                      php_value register_globals 0
                      
                      # set allow_url_fopen off
                      php_value allow_url_fopen 0
                      
                      # set magic_quotes_gpc off
                      php_value magic_quotes_gpc 0
                      
                      # set magic_quotes_runtime off
                      php_value magic_quotes_runtime 0

                      are the basic things to turn off

                      as far as the security of the php files goes, they are pretty safe. for more info search "secure config" and look at the first post called "question about security of php files."

                      I'm not sure that there is a safer way to have a dynamic website, and honestly I wouldn't worry about it, so long as you are careful with variables set by users you'll be fine. There are lots of dynamic websites that are very secure, if you have questions about specific code post it somewhere and ask— folks are usually pretty happy to help patch up the holes. scrypte mentioned validating your $POST & $GET's that is a very good idea, always.

                      a good basic one is:

                      function validate($value){
                      	if(get_magic_quotes_gpc()) 	$value 	= stripslashes($value);
                      	if(!is_numeric($value)) 	$value 	= mysql_real_escape_string(strip_tags($value));
                      	return $value;
                      }

                      and you'd use it like so:

                      $id=validate($_GET['id']);

                        Personally, I'd say, make sure allow_url_fopen is ON, but

                        Audit any require() or include() of a non-constant expression VERY CAREFULLY.

                        Almost any use of require() or include() on a non-constant expression could contain a compromise; I rarely use this in my applications (Exception: including all files in a directory).

                        Likewise, any use of eval() at all, should be audited with a fine-tooth comb. For preference, eval() should not be used. Its very existence in your application probably indicates a bug.

                        There is another thing which can be very dangerous and is often over looked:

                        • The "e" modifier on preg_replace expressions. At least one vulnerability I know of used this.

                        For preference, all regular expressions in preg_replace should be constant. Any which aren't should be audited very carefully.

                        Mark

                          mysql_real_escape_string is only useful if you're using a database.

                          Personally I check using file_exists everytime.....

                          $id = $_GET['id'];
                          
                          //YOU COULD ALSO STRIP OUT ANY DODGY STUFF AS PREVIOUSLY SUGGESTED BEFORE PROCEEDING
                          
                          if (file_exists("./$id.php"))
                           include('./$id.php');
                          

                            Using file_exists is not sufficient to prevent the above code being abused.

                            Almost every case of include() with a non-constant expression indicates poor practice and should be eliminated by refactoring the application.

                            Mark

                              mysql_real_escape_string is only useful if you're using a database.

                              Yes, and no. This will strip out any html and that sort of thing, which can be useful. It is what I use, though I am using it for a DB and it was written specifically with that in mind.

                              I meant it more as an example of what to do, depending on the use things need to be customized. In the case of using that either I or bretticus first suggested I don't know of a need to do it at all, though it isn't a bad idea.

                              - The "e" modifier on preg_replace expressions. At least one vulnerability I know of used this.

                              MarkR, what is it so I can avoid it?

                                jonlink wrote:

                                MarkR, what is it (the preg "e" modifier) so I can avoid it?

                                http://uk.php.net/manual/en/function.preg-replace.php

                                The "e" modifier interprets the replacement string as PHP code which is eval()ed for each replacement.

                                In the case where the replacement string is non-constant, it may be possible for a user manipulating input data to inject code to be executed- this will compromise the application.

                                Mark

                                  jonlink wrote:

                                  Yes, and no. This will strip out any html and that sort of thing, which can be useful. It is what I use, though I am using it for a DB and it was written specifically with that in mind.

                                  No, it will not strip out any html. If you want to change from HTML marks to code instead you should use [man]http://www.php.net/manual/sv/function.htmlspecialchars.php[/man] since it really does it possible to run in HTML.

                                    jonlink wrote:

                                    Yes, and no.

                                    You can only use mysql_real_escape_string if you have already connected to a mysql database, that's what I meant.

                                    If you're writing a script that doesn't require database access you can't use it to escape characters, you'd need addslashes and/or other functions.

                                      Alright lots of good info from everyone, thank you for replying you guys. For right now I will be using the code Bretticus provided which was:

                                      <?php
                                      
                                      $array['users'] = '/viewusers.php';
                                      $array['home'] = '/gohome.php';
                                      $array['update'] = '/updatethings.php';
                                      $array['delete'] = '/deletestuff.php';
                                      
                                      if ( array_key_exists($_GET['id']),$array) ) {
                                          include($array[$_GET['id']]);
                                      } else {
                                          include('index.php');
                                      }
                                      
                                      ?> 

                                      Altho he did mention this is just quick fix, so im guessing this is still somewhat vulnerable? What can I do to make it even more safe? Brtticus mentioned he discourages dynamic include paths, how do I go about not making it dynamic?

                                      These might be stupid questions but I am what you might call a PHP newbie and the newbiest of the newbies at that so please help me out, as I mentioned the person who made the site for me I dont keep contact with anymore and now that I found out its vulnerable I have to try fix it all on my own and I am just in the learning process.

                                      Thank you again guys.

                                        jigga wrote:

                                        Alright lots of good info from everyone

                                        Yeah, you got alot of good comments. I certainly recommend jonlinks php.ini settings to tighten your site up:

                                        # set register globals off
                                        php_value register_globals 0

                                        set allow_url_fopen off

                                        php_value allow_url_fopen 0

                                        set magic_quotes_gpc off

                                        php_value magic_quotes_gpc 0

                                        set magic_quotes_runtime off

                                        php_value magic_quotes_runtime 0

                                        And yes, as someone mentioned, sometimes, of course, you need to set variables externally. As that person mentioned, you must at that point, filter the users input (make sure they send what is expected.) For example, in http://www.google.com/search?q=cross+site+scripting, google will want to make sure that a remote user cannot insert SQL code to be executed at the Database server (this is all hypothetical of course as Google probably has various layers that queries pass through.) In PHP, for example, something like http://www.google.com/search?q=;+DROP *; (maybe not a legitimate example, but should give you the idea that somebody might be able to modify your data for malicious purposes) could be really bad. So you'd want (again the example is hypothetical) to use a jonlinks validate function in this case.

                                        As for your question, the way to take variables out of the include statement (dynamic paths) would either be just linking to individual pages or using GET variables to toggle content. Since the former is self-explanatory, I'll explain the latter only.

                                        I have used a similar switch statement in the past to run various content output functions:

                                        <?php
                                        switch ($_GET['mode']) {
                                        	case "users":
                                        		showusers();
                                        		break;
                                        	case "delete":
                                        		showdeleteusers();
                                        		break;
                                        	default:
                                        		showsearch();
                                        }
                                        
                                        function showusers()
                                        {
                                        	//do something	
                                        }
                                        
                                        function showdeleteusers()
                                        {
                                        	//do something	
                                        }
                                        
                                        function showsearch()
                                        {
                                        	//do something	
                                        }
                                        ?> 

                                        As you see, all of my functions are in-line in the very same script.

                                        Now, for follow-up, since changes like this may be very abrupt, you should be safe with the code I gave you, or even the example of a bunch of if elseif statements previously demonstrated by a responder here. Someone mentioned using file_exists(), which is a good idea as I don't believe it works on external (remote) files. You can throw that into the mix.

                                        As always, good luck.

                                          Write a Reply...