Update: The above URL doesn't use reverse directory traversal. Stupid me. It should actually read:

http://www.somehost.com/path/to/script/badscript.cgi?name=x-../../../b
+in/ls|
[download]

Update: Adam of course has raised the age-old "Security through Obscurity" question. The problem listed above is a classic on that many sites have. A resourceful hacker can easily write a Perl script that automatically probes for a number of common holes without necessarily knowing the holes are there. Even if you don't mention the hole, just having one can leave it exposed.

Security through obscurity is simply hoping they don't find the holes. All it takes is one lucky guess to earn the programmer a pink slip. If we plug the holes in the first place, we don't have to sit at home worrying.

On another note, this demonstrates why we shouldn't allow users to specify files names. Some programmers think the following can help protect:

$filename =~ tr/\.\.//;
[download]

This fails miserably. We can't disallow periods completely if there is a chance that a legitimate file to be opened is named something like datafile.dat, so we are concerned with two periods in a row. The hacker could simply specify \.\./\.\./\.\./bin/ls| as the path and our tr/// fails. If you don't believe me, hop on your linux box and see what ls \.\./ does.

Update 2: I noticed that someone downvoted Adam's post. He stated that he was playing the Devil's Advocate "for fun". His intention was clearly to start good discussion, not to defend "security through obscurity." I gave him a ++. Don't downvote him for it!

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.