1

To elaborate a bit on this point, I'd like to know how secure are documents hosted on an IIS website with the following configuration:

  1. IIS Directory Listing Disabled
  2. Anonymous Access is Enabled
  3. Site is accessed via HTTPs only
  4. Files have very long, randomly generated names (similar to a guid plus other characters)

I believe that this is a relatively secure setup (I understand its not as secure as truly authenticated access.) I would like to know if I'm seeing this big wall yet it would be easily circumvented by someone with more knowledge than myself.

I guess what I'm looking for are ways one could get around the setup I have outlined above.

2 Answers 2

5

Insecure. You are relying on Security through Obscurity, which is never a good idea. If someone guesses your file names (or your "random" names aren't random enough and someone can derive what the names are after seeing one name) they can grab the files.

That being said, the level of security may be appropriate for what you're trying to do. Without knowing how sensitive your data is it's impossible to day for sure.

4
  • I understand its StO, what I'm curious about is how easily is it circumvented? Is guessing the file names the only option? Are there known exploits to trick IIS into providing a list? If the wall of StO is built, how easy is it for someone smarter than I to simply walk around it?
    – Nate
    Jun 15, 2011 at 17:05
  • @Nate Security through Obscurity is circumvented as easily as it's circumvented. For some people finding a hole is intuitive, and they can guess paths/filenames in a few minutes. For others they'll just sit there looking confused forever. Bottom line is you need to manage the risk appropriately (Will the world end if someone grabs one of these files?).
    – voretaq7
    Jun 15, 2011 at 17:48
  • So you're saying that, excluding a new zero-day exploit on IIS, in that setup, my documents are as secure as the file-names are random?
    – Nate
    Jun 15, 2011 at 22:04
  • 1
    @Nate to a random attacker yes, but you also have to worry about how secure the file name is once you send it to a 3rd party client. Once the client receives the URL then access to that file is essentially out of your control. See my answer for some more details.
    – Greg Bray
    Jun 16, 2011 at 0:07
1

While most people won't publicly admit it, many websites are setup using an approach similar to yours. You basically are using the filenames as passwords. Anyone that knows the password can access the file, but unless a vulnerability is found in IIS or some other side channel attack is used, your files cannot be accessed remotely without knowing the correct "password".

You mentioned using HTTPS, which means that the URLs will be encrypted and not visible via a packet sniffer. However, any clients that receive the URL are free to share that URL with the world. If Google ever gets a hold of a link to your files, they will instantly become publicly available (even cached if they are HTML/TXT/PDF/DOC format). You can try preventing this by changing your robot.txt file to prohibit crawling but even that cannot guarantee that the files will not be made publicly available.

Since the file name is your only access control mechanism, you should make sure that it meets minimum complexity requirements. I'd recommend at least 10-20 random characters, which would limit the effectiveness of a brute force attack. Also, you may want to consider periodically changing the file names, just like you would periodically change your password. Also you may want to adjust the local NTFS file permissions on the folder to prevent anyone but system administrators and the IIS/ASP.NET accounts from accessing that folder.

In this case your files would meet an acceptable level of security, but would still be susceptible to attacks that would be prevented by normal username/password authentication. Simple things like a client's browser history, toolbar, and extensions would all have access to the URLs that they visit, so if your files contain state secrets or federally protected information (medical records, credit card numbers, etc) you probably want to add a bit more security.

4
  • HTTPS Inspection on a TMG proxy would allow the TMG admin to collect a series of those filenames and look for a pattern; or brute-force requests to the server; or simply replay the requests.
    – TristanK
    Jun 16, 2011 at 3:48
  • (Sorry for the intrusion Greg, mentioned as an adjunct to illustrate that even HTTPS might not provide the level of protection it's generally assumed to, if the client is an active participant in a MITM HTTPS inspection setup; endpoints are always untrustworthy)
    – TristanK
    Jun 16, 2011 at 4:12
  • @TristanK Thanks for the info. I actually wasn't sure about HTTPS URLs being encrypted, but it sounds like there are some situations where they are visible to 3rd parties. I figured man in the middle (MITM) attacks might occur, but was not aware about TMG Proxy issues.
    – Greg Bray
    Jun 16, 2011 at 4:17
  • 1
    That's only when HTTPS Inspection is enabled - otherwise, proxies without HTTPSi don't see the full URL, just a CONNECT (target):443, then encrypted gunk.
    – TristanK
    Jun 16, 2011 at 4:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .