Windows Security: Path Interpretation

I've come across this MSDN article, which talks about how Windows interprets paths:
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:

string GetFile(string path)
{
	if (isok(path))
	{
		return System.IO.File.ReadAllText(path);
	}
	else
	{
		throw new Exception("Access denied");
	}
}

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:

bool isok(string path)
{
	return path != @"c:\secret location\passwords.txt";
	// THIS CODE IS WRONG
}

But then an attacker could use uppercase or mixed to represent the same file:

Code:

GetFile(@"C:\SECRET LOCATION\PASSWORDS.TXT");
GetFile(@"C:\SeCrEt LoCaTiOn\PaSsWoRdS.TxT");

So maybe this might be a possible fix:

Code:

bool isok(string path)
{
	return path.ToLower() != @"c:\secret location\passwords.txt";
	// THIS CODE IS WRONG
}

Unfortunately this code isn't sufficient either, what about:

Code:

GetFile(@"c:\aaaa\..\secret location\passwords.txt");

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.

1. Normal: @"c:\secret location\passwords.txt"
2. Upper/lower case: @"C:\Secret Location\Passwords.TxT"
3. Parent directory: @"c:\aaa\..\secret location\passwords.txt"
4. Current directory: @"c:\.\secret location\passwords.txt"
5. Current file: @"c:\secret location\passwords.txt\."
6. Spaces: @"c:\secret location\passwords.txt   "
7. Dots: @"c:\secret location\passwords.txt...."
8. Network share: @"\\localhost\c$\secret location\passwords.txt"
   or <ip_address> or <computer_name> or 127.0.0.1
9. Long path prefix: @"\\?\c:\secret location\passwords.txt"
10. MS-DOS style: @"C:\SECRET~1\PASSWO~1.TXT"
11. Relative path: @"c:secret location\passwords.txt"
    (Works if current directory is c:\, otherwise need to add ..)
12. Win32 device: @"\\.\c:\secret location\passwords.txt"
13. Long UNC: @"\\?\UNC\localhost\c$\secret location\passwords.txt"
14. ADS: @"c:\secret location\passwords.txt::$DATA"
15. Unix style: @"c:/secret location\passwords.txt"

Go on, try some of them!
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.