CodeGrrl PHP scripts vulnerability

[Meli]

There's a post about the discovered security flaw at CG's forum right here, which was posted just a few hours ago. Apparently you just have to replace protection.php. :3

*goes to do that for her fls that aren't moved yet* I guess it was a good thing I decided to go with Enth when I started moving instead of sticking with fanbase then. ^^; Hmmm...the word "hack/hackers/hacking" seems to be a regular in my vocabulary this week. xD;;

[Jonathan]

Yes that fix will work.

[Danielle]

Just to reinforce the importance of fixing stuff like this (hopefully she won't mind my mentioning it), our own Loki just had her domain nuked by this very vulnerability, within hours of the announcement. It happens, people. Take care. ^_^

[Karly]

Thank you so much for this information, all my fanlistings are still running on Fanbase because I haven't had the time to switch them all over to Enth.  ^_^ It's good to know that there's an easy way to fix the problem, for now at least. ^^;

[Firefly]

Thanks for posting this.  I fixed my two hostees script, so hopefully everything will be good for the time period.

[Linda]

Thank you so much for posting about this. Some of my fanlistings are still running on PHPFanbase and I have been hesitant about changing all of my fanlistings to Enthusiast. But this will make me to give a good second thought about it.

[Matx]

Thanks very much for the information Johan! I've updated my (online) fanlistings with the fixed protection.php file... ^_^

Maybe the best solution is change all the fanlistings to Enthusiast, but maybe I'll do in the future... xD

[Guan]

thank you for the information~! ^^

*sweats* I'm glad they fixed the problem... I'm really just too lazy to switch to enthusiast...

[Mura]

Hmmm... Sasha has taken the scripts offline due to other security risks. For the moment at least.

Anyway, I suppose this sort of begs the question... does anyone (glances in Johan's general direction  :kitty: ) know about security risks in the method CodeGrrl used for dynamic includes?

Code: [Select]

   <?php
    include('header.inc');
    include 'config.php'; // you can include the config file here once
    if(!$_SERVER['QUERY_STRING']) {
    ?>
    
CONTENT

    <?php
    } elseif ($_SERVER['QUERY_STRING'] == "whatever") {
    ?>

CONTENT

    <?php
    } include('footer.inc');
    ?>
Could that be used to call external documents?


And for the record (just in case), my intention isn't to attack CodeGrrl... I love the site and the tutorials. I think we all understand that sometimes things like this just happen.

[Firefly]

Oh, dear, I hope not.  

[Edit] I checked with Code Grrl, and this is the response I got:

If you are referring to NL-ConvertToPHP, don't worry, it is safe. :kitty:

Or do you mean this tutorial? *goes to look at code*

ETA: The tutorial looks ok, too. It checks the page to make sure it exists before including it.

[Jonathan]

[quote name='Mura' date='Nov 16 2005, 08:25 PM']Anyway, I suppose this sort of begs the question... does anyone (glances in Johan's general direction  :kitty: ) know about security risks in the method CodeGrrl used for dynamic includes?

Code: [Select]

   <?php
    include('header.inc');
    include 'config.php'; // you can include the config file here once
    if(!$_SERVER['QUERY_STRING']) {
    ?>
    
CONTENT

    <?php
    } elseif ($_SERVER['QUERY_STRING'] == "whatever") {
    ?>

CONTENT

    <?php
    } include('footer.inc');
    ?>
Could that be used to call external documents?[/quote]
Using the $_SERVER['QUERY_STRING'] method, at first glance, appears to be fine. (PHP.net documentation of pre-defined variables, including the $_SERVER array). The important bit is what the programmer does with that information. It is up to the programmer to, for example, check the 'QUERY_STRING' variable and make sure (1) the file exists, (2) the file is in the proper context (i.e. local vs. remote, basically not something the web server should not be accessing). THAT is where 99% of all vulnerabilities come from - programmers who do not check data the program receives. Never, ever trust your users to provide the right data. 99% of them will, but there will be that 1% who will input incorrect data because (1) they made a mistake, or (2) they're trying to break your program.

Hmmm... Sasha has taken the scripts offline due to other security risks. For the moment at least.

....


And for the record (just in case), my intention isn't to attack CodeGrrl... I love the site and the tutorials. I think we all understand that sometimes things like this just happen.

[post=\"116422\"]<{POST_SNAPBACK}>[/post]

I am encouraged that they took the scripts off-line while they fix them. Though to be honest I am troubled by the statement "We are unsure at the moment where these issues lie and how to fix them[...]". I also do not intend to attack CodeGrrl. Tutorials and open source are a wonderful way for people to learn new methods, techniques, tools, especially since php.net is better as a dictionary and not very well suited to learning the language. However it is starting to appear to me (and this is all my opinion) that the programmers there haven't quite grasped the full understanding of how powerful PHP is, and why any implementation needs to be locked down tighter than a snare drum.

[Mura]

Using the $_SERVER['QUERY_STRING']method, at first glance, appears to be fine. (PHP.net documentation of pre-defined variables, including the $_SERVER array). The important bit is what the programmer does with that information. It is up to the programmer to, for example, check the 'QUERY_STRING' variable and make sure (1) the file exists, (2) the file is in the proper context (i.e. local vs. remote, basically not something the web server should not be accessing). THAT is where 99% of all vulnerabilities come from - programmers who do not check data the program receives. Never, ever trust your users to provide the right data. 99% of them will, but there will be that 1% who will input incorrect data because (1) they made a mistake, or (2) they're trying to break your program.

So basically you're basically saying it would be best to provide additional conditionals to handle files that are not there and files that are not on the server, right?

[Jonathan]

[quote name='Mura' date='Nov 18 2005, 11:00 AM']So basically you're basically saying it would be best to provide additional conditionals to handle files that are not there and files that are not on the server, right?

[post=\"116747\"]<{POST_SNAPBACK}>[/post]

[/quote]
The basic idea is to examine the data before you use it. In the case of the bit of code we're talking about, the proper solution would be to look at the QUERY_STRING variable, determine what file it's wanting to load, and have PHP check to see if the file exists and should be loaded here before trying to load it. Additional conditionals are also helpful, espcially for development and debugging.

[Daisy]

Thank you so much for posting this information before anything drastic could've happened!  I would love to switch to Enthusiast but it's confusing to me for some reason and I love my Fanbase!  *hugs it*  I've replaced all my protection.php files.  Thank you again!

[Kari]

Thanks for posting it, I've also edited the protection.php files yesterday (And all my hostees files too!) :kitty: