Suppression of URL details

[coder]

This has probably been answered a 1000 times, but I haven't found it in a
search.

I have an application where the user uploads documents and I have logic for
him to view them. All documents are put into a user specific directory.
Any give user can only see his documents and documents for which the admin
level is less than or equal to his admin level (these are stored in a
database along with file location and other data).

The problem is that if the user can determine the location of his files,
then he could construct a URL for other files to which he does not have
access simply by finding the path , changing a user ID number, and
guessing/knowing the desired file name to look at. This would be extremely
difficult if I could make the top level directory dificult to find. So, how
does one go about hiding the path name to a file in the URL?

 

[Harlan Messinger]

This has probably been answered a 1000 times, but I haven't found it in a
search.

I have an application where the user uploads documents and I have logic for
him to view them. All documents are put into a user specific directory.
Any give user can only see his documents and documents for which the admin
level is less than or equal to his admin level (these are stored in a
database along with file location and other data).

The problem is that if the user can determine the location of his files,
then he could construct a URL for other files to which he does not have
access simply by finding the path , changing a user ID number, and
guessing/knowing the desired file name to look at. This would be extremely
difficult if I could make the top level directory dificult to find. So, how
does one go about hiding the path name to a file in the URL?

You can't. Anything a user can do from his browser to cause a particular
document to be downloaded is visible to him because it's visible to the
browser and is therefore viewable in the source code. If it wasn't
visible to the browser, the browser wouldn't be able to request it.

You can either establish the operating system's built-in file security
mechanism to deny access to materials a user doesn't have the authority
to see, of you can use an intermediary web application that takes care
of it:

http://www.example.com/showdoc?docid=123/456

where showdoc is a web app (ASP.NET page, PHP page, whatever) that
checks whether the authenticated user is authorized to see document 456
belonging to user 123 and, if so, opens it and pipes its contents into
the response, or else returns an "Access Not Permitted" response.

 

[coder]

You can't. Anything a user can do from his browser to cause a
particular document to be downloaded is visible to him because it's
visible to the browser and is therefore viewable in the source code.
If it wasn't visible to the browser, the browser wouldn't be able to
request it.
You can either establish the operating system's built-in file security
mechanism to deny access to materials a user doesn't have the
authority to see, of you can use an intermediary web application that
takes care of it:

http://www.example.com/showdoc?docid=123/456

where showdoc is a web app (ASP.NET page, PHP page, whatever) that
checks whether the authenticated user is authorized to see document
456 belonging to user 123 and, if so, opens it and pipes its contents
into the response, or else returns an "Access Not Permitted" response.

Thanks. While waiting for a response I cam up with a similar solution.
Upon registration I generate a random eight character code for each new
user. (The randomness is over 62 possibilies for each character so there
are 62**8, or about 10**28, possiblities) His upload directory is

{his userID}_{the random eight character code}

All uploaded files are given an access level of one by default. All new
users are given an access level of zero by default. The only files that
show in a user's list are his own files and those for which he has
sufficient access level. Upon a click of a file in the list, I do a futher
check on permissions (a little redundant, but being slightly paranoid) and
then display that file if it is OK.

This way, it would be almost impossible for some other user to both know the
the path to a file that he should not have access to and also know its name.

Opinions?

 

[Bone Ur]

Well bust mah britches and call me cheeky, on Tue, 11 Dec 2007 17:51:17
GMT coder scribed:

Thanks. While waiting for a response I cam up with a similar
solution. Upon registration I generate a random eight character code
for each new user. (The randomness is over 62 possibilies for each
character so there are 62**8, or about 10**28, possiblities) His
upload directory is

{his userID}_{the random eight character code}

All uploaded files are given an access level of one by default. All
new users are given an access level of zero by default. The only
files that show in a user's list are his own files and those for which
he has sufficient access level. Upon a click of a file in the list, I
do a futher check on permissions (a little redundant, but being
slightly paranoid) and then display that file if it is OK.

This way, it would be almost impossible for some other user to both
know the the path to a file that he should not have access to and also
know its name.

Opinions?

Why don't you just impliment a password scheme? P/ws could be db-linked
to usernames and access levels, etc.

 

[Nick Theodorakis]

This has probably been answered a 1000 times, but I haven't found it in a
search.

I have an application where the user uploads documents and I have logic for
him to view them. All documents are put into a user specific directory.
Any give user can only see his documents and documents for which the admin
level is less than or equal to his admin level (these are stored in a
database along with file location and other data).

The problem is that if the user can determine the location of his files,
then he could construct a URL for other files to which he does not have
access simply by finding the path , changing a user ID number, and
guessing/knowing the desired file name to look at. This would be extremely
difficult if I could make the top level directory dificult to find. So, how
does one go about hiding the path name to a file in the URL?

Google for mod_rewrite tutorial (assuming your running Apache, I don't
know what the equivalent on a Windows server is).

Nick

 

[coder]

Well bust mah britches and call me cheeky, on Tue, 11 Dec 2007
17:51:17 GMT coder scribed:


Why don't you just impliment a password scheme? P/ws could be
db-linked to usernames and access levels, etc.

I already have one in place. The problem I was solving was that for someone
who logged into his own account could see the path for the files he
uploaded. Then, by modifying the path a little he might be able to see
someone else files just by putting in that URL without even logging in. My
scheme that I cam up with makes that extremely difficult, if not next to
impossible.

 

[coder]

One more thing. A user can always do "Save As" for a web page and pull it
down to his computer. That's fine. However, what is the software behind
when a user clicks "Download" and the actual file comes down.

 

[Bone Ur]

Well bust mah britches and call me cheeky, on Tue, 11 Dec 2007 23:38:02
GMT coder scribed:

I already have one in place. The problem I was solving was that for
someone who logged into his own account could see the path for the
files he uploaded. Then, by modifying the path a little he might be
able to see someone else files just by putting in that URL without
even logging in. My scheme that I cam up with makes that extremely
difficult, if not next to impossible.

What url, -the directory? You can block general access to a folder with an
..htaccess file or even just putting an index.html in that folder. It's
even possible to p/w-protect a folder, though I've never done it.
Furthermore, as a hypothetical example and assuming that the passwords are
unique and unknown to other users, you could name the folders the passwords
(or something similarly secure). Heck, if you're really paranoid and use
php, you can create folders on the fly for each logon, transfer files, then
delete the lot after a certain time.

 

[André Gillibert]

The problem is that if the user can determine the location of his files,
then he could construct a URL for other files to which he does not have
access simply by finding the path , changing a user ID number, and
guessing/knowing the desired file name to look at.

Send a 403 error if he doesn't have the required authorization.

Use HTTP authentication and authorization.
For Apache, the HOWTO tutorial is at:
http://httpd.apache.org/docs/2.2/howto/auth.html

This would be extremely
difficult if I could make the top level directory dificult to find.

This would also be extremely unsecure.
Security by obfuscation is obsolete since the twentieth century.

 

[Harlan Messinger]

Send a 403 error if he doesn't have the required authorization.

Use HTTP authentication and authorization.
For Apache, the HOWTO tutorial is at:
http://httpd.apache.org/docs/2.2/howto/auth.html


This would also be extremely unsecure.
Security by obfuscation is obsolete since the twentieth century.

Public key encryption is nothing more than security by extreme
obfuscation. In that case, you're relying on a third party not to
stumble on the value of a private key, which is selected using a method
that causes that to be highly unlikely. Using a path generation method
where genuine paths are only a minuscule fraction of all possible paths
can be plenty secure.

 

[Andy Dingley]

Public key encryption is nothing more than security by extreme
obfuscation.

Only if you stretch the terms beyond the breaking point of their usual
meanings.

"extreme" here means a level of difficulty (for competent
implementations) that makes it technically impossible for the socially
significant lifetime of the data protected. Comptent work involves
assessing both of these: necessary lifetime and predicted point at
which brute-force cracking becomes practical.

Enigma didn't fail because modern PCs can break it today, it failed
because Bletchley Park pushed the cryptanalysis technology further
forward more quickly than was expected, and (mainly) because of errors
in its operation. It doesn't matter to Hitler that we can read them
today with our incredible computing powers, it did matter that they
were unexpectedly readable within a useful time.

 

[Harlan Messinger]

Only if you stretch the terms beyond the breaking point of their usual
meanings.

"extreme" here means a level of difficulty (for competent
implementations) that makes it technically impossible for the socially
significant lifetime of the data protected. Comptent work involves
assessing both of these: necessary lifetime and predicted point at
which brute-force cracking becomes practical.

Enigma didn't fail because modern PCs can break it today, it failed
because Bletchley Park pushed the cryptanalysis technology further
forward more quickly than was expected, and (mainly) because of errors
in its operation. It doesn't matter to Hitler that we can read them
today with our incredible computing powers, it did matter that they
were unexpectedly readable within a useful time.

 

[Harlan Messinger]

Only if you stretch the terms beyond the breaking point of their usual
meanings.

The word "extreme" already means "at or beyond the limits". How can
"extreme" be stretched beyond that meaning? Your objection makes no
sense as stated.

"extreme" here means a level of difficulty (for competent
implementations) that makes it technically impossible for the socially
significant lifetime of the data protected. Comptent work involves
assessing both of these: necessary lifetime and predicted point at
which brute-force cracking becomes practical.

Enigma didn't fail because modern PCs can break it today, it failed
because Bletchley Park pushed the cryptanalysis technology further
forward more quickly than was expected, and (mainly) because of errors
in its operation. It doesn't matter to Hitler that we can read them
today with our incredible computing powers, it did matter that they
were unexpectedly readable within a useful time.

How does all this alter the validity of my remark?

 

[Andy Dingley]

The word "extreme" already means "at or beyond the limits". How can
"extreme" be stretched beyond that meaning?

I don't object to "extreme", so much as it's use to qualify
"obfuscation".

You appear to be using obfuscation to imply "camouflage" (potentially
discoverable, with effort) and qualifying it with "extreme" makes it
hard to find fault with the statement. PK (for practical algorithms,
such as factorising the products of long primes) is of course merely
obfuscation because we know exactly _how_ to break it, it's just that
we cannot do this (for any practical or anticipated approach).

Yet the phrase "extreme obfuscation" still embodies the term
"obfuscation", and the impression that will inevitably generate in the
mind of the reader is as something that's basically insecure. Weasel
words, used to create an impression that PK is somehow insecure,
without going so far as to make a statement that's provably false.
"When did you stop beating your wife?"

There's also the issue that "obfuscation" in the crypto world is
generally used to mean a process that's deliberately lossy and thus
absolutely irreversible (albeit thus no use for encryption), eg.
displaying only the last 4 or 5 digits of a card number.

 

[Harlan Messinger]

I don't object to "extreme", so much as it's use to qualify
"obfuscation".

You appear to be using obfuscation to imply "camouflage" (potentially
discoverable, with effort) and qualifying it with "extreme" makes it
hard to find fault with the statement.

So your objection is that you wanted to pick apart my statement but I
didn't leave room for you to do so, so you tried to recast my remark in
a manner that would let you pick it apart, and I caught your bluff.
Sorry for the inconvenience.

PK (for practical algorithms,
such as factorising the products of long primes) is of course merely
obfuscation because we know exactly _how_ to break it, it's just that
we cannot do this (for any practical or anticipated approach).

Yet the phrase "extreme obfuscation" still embodies the term
"obfuscation", and the impression that will inevitably generate in the
mind of the reader is as something that's basically insecure. Weasel
words, used to create an impression that PK is somehow insecure,
without going so far as to make a statement that's provably false.

It isn't false, so how could I make it provably false? Don't explain
"falsifiability" to me--I already understand it just fine. There isn't
anything unfalsifiable about what I said. You just want to believe that
PK is inherently secure, and my point was that its security lies
*solely* in the impracticality of testing quadrillions or quintillions
or however many -illions of possible keys would be necessary to hit upon
the one that was used in the encryption. This differs from the case we
were discussing with respect to the OP's situation only in orders of
magnitude, and if ten years from now processors become octillions of
times faster than they are now, PK keys would be broken like *that*.
This isn't news. It's obvious and well-known to everyone in the field.
So as I said, the only difference is the order of magnitude, and, as I
said, PK is an extreme case.

 

[Andy Dingley]

So your objection is that you wanted to pick apart my statement but I
didn't leave room for you to do so, so you tried to recast my remark in
a manner that would let you pick it apart, and I caught your bluff.
Sorry for the inconvenience.

OK, I'll make it simple for you: Disparaging PK as "no more than
obfuscation" (either "obfuscation" or "extreme obfuscation") is
disingenuous bollocks.
Happy now?

 

[Harlan Messinger]

OK, I'll make it simple for you: Disparaging PK as "no more than
obfuscation" (either "obfuscation" or "extreme obfuscation") is
disingenuous bollocks.
Happy now?

Fine. And I'm still right, and you're still wrong.

 

[Harlan Messinger]

Fine. And I'm still right, and you're still wrong.

To make it more specific, I've explained why I'm right, and nothing
you've said contradicts me, and almost as if to prove that point you
resorted to attack mode. If I'm really incorrect, would you please
provide something informative that demonstrates that fact instead of
waving your hands and calling it bollocks?

I don't understand what your problem is with it: there isn't anything
controversial or surprising about it to anyone who understands it. It
may be *disturbing* to anyone who thought that there was anything more
to it than there actually is and who, given genuine information on the
subject, is seized with visions of all our current modes of security
disappearing twenty years from now if someone designs a processor that's
orders of magnitudes more powerful than the ones we have now.

In one sense, that fear is well grounded: eventually, if processor
speeds keep improving, then, for example, our current 128-bit or 256-bit
key SSL encryption will break like a stick! (This is OBVIOUS. It's the
same reason why we don't use, say, only *16-bit* encryption now!) But on
the other hand the day is saved, because it will likewise be no more
time-consuming to use, say, 2048-bit encryption once that time has come
than it is now to use 128-bit encryption.

 

[dorayme]

<[email protected]
m>,

OK, I'll make it simple for you: ... is
disingenuous bollocks.
Happy now?

Psychiatrist: You're mad.

Patient: I want a second opinion.

Psychiatrist: OK, You're also fat and ugly.

 

[dorayme]

<[email protected]
m>,

I don't object to "extreme", so much as it's use to qualify
"obfuscation".

You appear to be using obfuscation to imply "camouflage" (potentially
discoverable, with effort)

Anyway... without wanting to get involved between this business
with Harlan and you, it did make me wonder how to categorize a
kill-switch I am fond of wiring up for friend's cars.

I like the idea of not hiding a switch because the damn thing can
be found if the thief suspects it is somewhere. I prefer to put
it right under his nose where there is nothing like a simple
verification procedure for finding it:

Ah! A toggling thingmajig, click, click!

No. Best for it not to physically be this at all.

Next there is another layer of ? obfus... what was the word?
Anyway, I have a scheme to discourage the thief even suspecting a
kill switch. Or at least to encourage a different theory in his
evil head, namely that the car is just hard to start or flooded
or out of petrol. I can reveal that I do this by ensuring the
starter motor is *not* disabled.

Naturally I can say no more. But I need a name for the general
scheme. Perhaps I might patent it. (btw. anyone interested in
investing, please send $US10 without asking anything in return -
to show good faith.)