http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx
Why is this a security concern?
Let's say you have an application that allows a user to write a file path as input, and to get the content of the file as output. You want to restrict access to a specific file, let's say:
c:\secret location\passwords.txt
This code is a possible way of writing such functionality:
Code:
Maybe the best option is limiting the permissions of the application so it can't access the file, but then what about a web server that needs to hide .htaccess from the user but must be able to read it?So maybe you choose another option - examining the file path.
For example:
Code:
But then an attacker could use uppercase or mixed to represent the same file:
Code:
So maybe this might be a possible fix:
Code:
Unfortunately this code isn't sufficient either, what about:
Code:
Note that it works even if aaaa doesn't exist. This can go on and on. I tried to put some of those "path features" in the following list.
- Normal: @"c:\secret location\passwords.txt"
- Upper/lower case: @"C:\Secret Location\Passwords.TxT"
- Parent directory: @"c:\aaa\..\secret location\passwords.txt"
- Current directory: @"c:\.\secret location\passwords.txt"
- Current file: @"c:\secret location\passwords.txt\."
- Spaces: @"c:\secret location\passwords.txt "
- Dots: @"c:\secret location\passwords.txt...."
- Network share: @"\\localhost\c$\secret location\passwords.txt"
or <ip_address> or <computer_name> or 127.0.0.1 - Long path prefix: @"\\?\c:\secret location\passwords.txt"
- MS-DOS style: @"C:\SECRET~1\PASSWO~1.TXT"
- Relative path: @"c:secret location\passwords.txt"
(Works if current directory is c:\, otherwise need to add ..) - Win32 device: @"\\.\c:\secret location\passwords.txt"
- Long UNC: @"\\?\UNC\localhost\c$\secret location\passwords.txt"
- ADS: @"c:\secret location\passwords.txt::$DATA"
- Unix style: @"c:/secret location\passwords.txt"
There are probably many more ways that aren't on that list.
For conclusion, restricting access to a file simply by examining the input path is probably a bad idea. An alternative better solution should be chosen depending on the project requirements.
No comments:
Post a Comment