Ivan Sergio Borgonovo
19/04/06, 21:40
I just came across such kind of code (php) written by a colegue:
//header.inc
if($_SESSION['UN']!='hardcoded_UN' or $_SESSION['UN']!='hardcoded_PW')
header("Location: ./login.html");
//missing else to mitigate the problem!!
//HTML stuff here...
code structure of all the other "supposed to be" private pages is:
//wannabeprotected.php
include_once("include/header.inc")
//wannabe protected code
Everything resides at something like:
http://site/admin/
of course the ONLY thing you've to do to break into the admin interface is:
- disable redirection in your preferred browser (w3m)
- guess the right address and
- point exactly to it: http://site/admin/index.php or any existing page[1] eg. http://site/admin/killingmesoftly.php
http://site/admin/ won't work. I did some research to see if you could find a way to make "educated guess" by examining the flow of HTTP responses, but I didn't came out with any good idea. Nevertheless index.php doesn't seem to be a bad educated guess (as Default.asp, index.asp, index.pl, login.asp...).
Now some questions and a proposal:
- how safe is to rely on secrecy of the URL? I'm looking for a quantification of the risk, not a "it is a bad idea" ;)
of course http://site/`pwgen -N1 30`/`pwgen -N1 30`.php is safer than http://site/admin/index.php. Any already made study? numbers?
- are SE like google going to index such kind of pages if there is no "external" link ?
- are there already many specialized vuln crawlers looking for such kind of URLs?
What about building crawlers that ignore redirection to scan for such kind of vulns?
I think that kind of mistake should be pretty popular.
Did I reinvent the wheel?
[1] this makes educated guessing easier increasing the number of potential targets: manager.php, insert.php, delete.php and it makes this [in]security model rely just on the dir path... unless the programmer is so crazy to call all his files with random names. But coding the access credential in a path makes the code not that relocable... etc... etc..
What I mean: it exists a chain of links that connect that page with a link on a homepage or an already indexed page.
BTW the colegue didn't set any association between .inc and the php interpreter. So you can even get the header.inc source with another maybe harder educated guess.
.... and happy Easter holidays.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
//header.inc
if($_SESSION['UN']!='hardcoded_UN' or $_SESSION['UN']!='hardcoded_PW')
header("Location: ./login.html");
//missing else to mitigate the problem!!
//HTML stuff here...
code structure of all the other "supposed to be" private pages is:
//wannabeprotected.php
include_once("include/header.inc")
//wannabe protected code
Everything resides at something like:
http://site/admin/
of course the ONLY thing you've to do to break into the admin interface is:
- disable redirection in your preferred browser (w3m)
- guess the right address and
- point exactly to it: http://site/admin/index.php or any existing page[1] eg. http://site/admin/killingmesoftly.php
http://site/admin/ won't work. I did some research to see if you could find a way to make "educated guess" by examining the flow of HTTP responses, but I didn't came out with any good idea. Nevertheless index.php doesn't seem to be a bad educated guess (as Default.asp, index.asp, index.pl, login.asp...).
Now some questions and a proposal:
- how safe is to rely on secrecy of the URL? I'm looking for a quantification of the risk, not a "it is a bad idea" ;)
of course http://site/`pwgen -N1 30`/`pwgen -N1 30`.php is safer than http://site/admin/index.php. Any already made study? numbers?
- are SE like google going to index such kind of pages if there is no "external" link ?
- are there already many specialized vuln crawlers looking for such kind of URLs?
What about building crawlers that ignore redirection to scan for such kind of vulns?
I think that kind of mistake should be pretty popular.
Did I reinvent the wheel?
[1] this makes educated guessing easier increasing the number of potential targets: manager.php, insert.php, delete.php and it makes this [in]security model rely just on the dir path... unless the programmer is so crazy to call all his files with random names. But coding the access credential in a path makes the code not that relocable... etc... etc..
What I mean: it exists a chain of links that connect that page with a link on a homepage or an already indexed page.
BTW the colegue didn't set any association between .inc and the php interpreter. So you can even get the header.inc source with another maybe harder educated guess.
.... and happy Easter holidays.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it