所有存在都是独创。
1.Internet Information Services（IIS，互联网信息服务）是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。Microsoft IIS在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件。
危害：攻击者可以利用“~”字符猜解或遍历服务器中的文件名，或对IIS服务器中的.Net Framework进行拒绝服务攻击。
解决方案：
1.关闭NTFS 8.3文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。
如果是虚拟主机空间用户，请联系空间提供商进行修复。
修改方法：
1）修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除)，或者，可以直接点此下载，然后运行,再重启下机器；
2）如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 --- Web 服务扩展 - ASP.NET 选择禁止此功能；
3）升级net framework 至4.0以上版本；
涉及程序：
windows
描述：
8.3文件格式漏洞导致web server 源代码泄露
详细：
在Windows平台上每一个长文件名（DOS 8.3 格式不支持）都有一个短文件名（DOS 8.3 格式能支持）的别名。 比如，文件名"longfilename.txt" 的短文件名别名为"longfi~1.txt", 文件名"name.jumbo" 的短文件名别名为"name~1.jum".
从长文件名到短文件名的转换基本是通过取长文件名（包括文件名的扩展部分）的一部分，整理后取6个字符，再附加"~1" 到其上，然后扩展部分取3个字符就构成了短文件名。如果转换成短文件别名后在同一目录下存在相同的文件名，则文件名附加部分的阿拉伯数字相应地加一，依次类推直到得到不同的文件名。
但是这种标准的方式存在一个问题，就是如果文件名部分只有一至两个字符长，就得使用一个不同的方法来产生文件名。
Web服务器通常是根据文件名的扩展部分使用一个相应的handler来处理源文件，当一个特殊的扩展部分没有相应的handler时，将返回未经处理的源文件。
许多运行在Windows平台上的Web服务器，无法有效地根据8.3格式文件名，正确地识别源文件，进行源文件的处理，于是只好简单地尝试着用开头我们提到的标准的方式进行处理。这将意味着和文件名扩展部分响应的handler将被迫为这个文件提供服务（如果是没有此漏洞的Web服务器就会拒绝使用8.3格式文件名服务）。
这在以下的情况中将会产生一个严重的安全问题：
- 一个scripting的扩展名有4个字符长或更长（像 jhtml/jhtm ，shtml/shtm)；
- 某些扩展名没有相应的合适的handler。
- 像hello.jhtml 和 helloworld.shtml这样的除扩展名外，文件名名长于2个字符 , 得到的别名是hello~1.jht 和 hellow~1.sht, 但是有漏洞的web服务器不能根据其别名来识别源文件名，只好尝试着使用标准方法，服务器将首先使用提取出扩展部分("jht" 和 "sht"),然后寻找一个相应的handler，但是没有为"sht" 或 "jht" 定义的handler，而将他们的源文件返回，不去运行它。也就是说脚本源代码将会作为输出返回给客户端，这将存在很大的源代码暴露风险。
风险级别：高
解决方案：
临时解决方案:
如果你使用的是 Deerfield WebSite Pro 3.1.11.0, 升级到版本version 3.1.13.0
http://www.deerfield.com/download/website/
解决方案:
1.关闭NTFS 8.3文件格式的支持
NtfsDisable8dot3NameCreation
位置：HKEY_LOCAL_MACHINE\SYSTEM
类型：REG_DWORD
范围：0, 1 (False, True)
默认值：0 (False)
建议值：1 (True)
但是这样的话将会导致16位应用程序的兼容性问题。
2. 当根据8.3格式文件名扩展部分选择相应的handler时，可使用和原文件名的扩展部分相应的handler。比如如果一个文件名的扩展部分为.jhtml, 你应该在联系.jht 相应的handler时使用.jhtml相应的handler。
from：http://www.bitscn.com/network/security/200607/36285.html
