Being safe on the internet (was Re: Here we go again - ISP DPI, but is it interception?)

[Nicholas Bohm]

Matthew Pemble wrote:
> On 4 August 2010 10:44, Nicholas Bohm <nbohm at ernest.net
> <mailto:nbohm at ernest.net>> wrote:
>
>     Matthew Pemble wrote:
>
>      Or is the point that people are becoming confused between URL
>     > truncation and a "Directory Traversal Attack", using the well-known
>     > '/../' syntax (just the same as, at the time, appending '.' to a
>     .php
>     > URL often gave you the script source rather than the product)?
>     > Although Peter's pdf doesn't make it clear although other
>     > contemporaneous sources
>     > (http://www.samizdata.net/blog/archives/008118.html) do mention the
>     > method.
>
>     Yes, I certainly confused the two.  What exactly does the "/../"
>     syntax
>     do, and why does it matter to the host?  (The article you link isn't
>     explicit enough for me to follow.)
>
>
> Apologies to those folks on-list for whom this is sucking on a
> "thousand year egg".

This is a policy list; I don't think you need apologise!

> "Directory Traversal" is a penetration testing technique where you
> attempt to gain access to parts of the server file system that are not
> supposed to be shared online - in this case ones outside of the
> context of the web-server files.
>
> ".." normally (i.e. in common Unix and Microsoft filesystems) means
> "parent directory" - so "cd .." should take you back up one level in
> the filesystem. However. a well-engineered (and configured) webserver
> should never provide information outside of the "webroot" - either
> returning an error (RFC compliant behaviour - I'd guess at a 403
> error) or simply returning the default page (normal behaviour).
>
> However, IIS 4 and 5 had a number of problems that Microsoft
> classified variously as "File Permission Canonicalization" and "Web
> Server Folder Traversal" patched from Aug 2000 to Aug 2001 (although
> the first patch was against a completely different problem.) 
> Essentially, if you encoded '/..' in Unicode and included it in a URL,
> you could would be returned files outside of the webroot, including
> critical system configuration files and you could also run programs on
> the local machine.
>
> At the time, a well known vulnerability and, I believe, exploited by
> the Nimda worm.
>

That suggests to me that entering a URL designed to exploit a weakness
in order to get "behind" the root of a server for a particular site is
doing something very different from truncating a URL in order to explore
a site.  I can much more easily see why it might be concluded a
particular user knew it was unauthorised.

Nicholas
-- 
Contact and PGP key here <http://www.ernest.net/contact/index.htm>