Include File Vulnerability

I try to read Claroline source code to learn from their coding.

In index.php file, at the first line 开发者_如何学JAVAof code, they write

unset($includePath); // prevent hacking

You can see full claroline source code from here.

They commented that the line is used to prevent hacking..

I have no idea why should they unset $includePath while the variable is never defined before that line..

What is the purpose of that line of code do actually, and what hacking type that they means?

---

I have not looked at the source myself, but a bit of searches gives the following kind of security advisory :

Claroline mambo.inc.php and postnuke.inc.php "includePath" file include

Note that this relies on register_globals being enabled, which :

• is not the default : it's been disabled by default for a very long time (since PHP 4.2.0)
• is bad practice (unsafe ^^ as it allows anyone to inject variables into the PHP scripts ; which is why this one, in this case, is unset "to prevent hacking" )

---

The variable might not be set in code before that point, but if register_globals is turned on, it could be set in the URL by a malicious user.

---

It sounds like you're mostly looking for educational info, so here's a wee explanation of what register_globals used to do ... why it was there ... and why it's not any more (and you should never turn it on).

Variables come in via the $_GET and $_POST (or $_REQUEST) arrays ... what register_globals did, was make programming easier, by taking all the elements of these arrays, and putting them in the global namespace - i.e., making "regular" global variables out of them - so $_GET['includes'] could very easily be referenced simply as $includes.

This was in the happy days of the intarweb when the internet hadn't proliferated nearly as much as it has now, the technology wasn't so well know, there were fewer people who knew how to hack sites, and no one was writing worms that would automatically hack sites.

It was terribly insecure - because if a lazy programmer hadn't bothered to initialize all variables properly (e.g., checking if $includes is set, and then using it, before it's properly initialized), any of these improperly initialized variables could be set to whatever a hacker wanted. PHP was fairly new then, and many hobbyists were writing code - frequently also doing things like forgetting to properly escape variables in SQL queries. So one security flaw was usually easy to follow up with another one, allowing a hacker (or automated script) to gain deeper and deeper levels of access.

Around 2001 or so, people began very seriously warning about the consequences of register_globals - so this is a rather old issue, but it's still good to be on the lookout, especially with applications that don't have a solid reputation for security.

---

héhé it's a long story.

In fact in early "naive" version of claroline, Security was not really a target ;-)

$includePath was compute in init to buil all others paths of claroline.

With servers configured with register global=on, it's was a very easy way to hack.

ie : include($includePath."/lib/pager.lib.php");

This simple line was a "patch".

as require '../../../../inc/claro_init_global.inc.php';is included in all.

Conclusion : Claroline is an old code started in php4, with script writed for php3, secure (now) but old. The style is not a good inspiration for "modern" code :-)

Secure claroline was a great adventure -) Mathieu has done most of correction.

I remeber they work more than one month to be comptabile with register global off (I mean it 7y ago)