Being safe on the internet (was Re: Here we go again - ISP DPI, but is it interception?)
nbohm at ernest.net
Wed Aug 4 12:01:23 BST 2010
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
> > 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 "/../"
> 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.
Contact and PGP key here <http://www.ernest.net/contact/index.htm>
More information about the ukcrypto