Reflected File Download (RFD) 是一种漏洞，攻击者可以利用该漏洞创建网络钓鱼 URL 或页面，一旦有用户访问 URL 或页面，则开始下载包含看似来自受信任域的任意内容的文件。由于用户信任给定的域，他/她很可能会打开下载的文件，进而可能导致执行恶意代码。

为确保攻击者成功发动 RFD 攻击，需要满足以下要求：
- 目标应用程序在未经适当验证或编码的情况下反映用户输入。此类漏洞用于注入有效负载。
- 目标应用程序允许许可 URL。因此，攻击者可以控制下载文件的名称和扩展名。
- 目标应用程序的 Content-Disposition 标头配置错误，攻击者可以控制 HTTP 响应的 Content-Type 和/或 Content-Disposition 标头，或者目标应用程序包含 Content-Type（默认不会在浏览器中呈现）。

例如，如果应用程序使用 Spring Web MVC ContentNegotiationManager 动态生成不同的响应格式，则满足发动 RFD 攻击的必要条件。

ContentNegotiationManager 配置为根据请求路径扩展决定响应格式，使用 Java Activation Framework (JAF) 查找与客户端请求格式更匹配的 Content-Type。同时，客户端也可以通过请求的 Accept 标头中发送的媒体类型来指定响应内容类型。

示例 1：在以下示例中，应用程序配置为允许通过路径扩展策略和 Java Activation Framework 确定响应内容类型：

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="favorPathExtension" value="true" />
  <property name="useJaf" value="true" />
</bean>

示例 2：在以下示例中，应用程序配置为允许通过请求的 Accept 标头确定响应内容类型：

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="ignoreAcceptHeader" value="false" />
</bean>

请注意，Spring 4.2.1 的 ContentNegotiationManagerFactoryBean 属性默认值为：

- useJaf：true
- favorPathExtension：true
- ignoreAcceptHeader：falseExample 1 中所示的配置允许攻击者创建一个恶意 URL，例如：

http://server/some/resource/endpoint/foo.bat?input=payload

因此，ContentNegotiationManager 将使用 Java Activation Framework（如果在类路径中发现 activation.jar）尝试解析给定文件扩展名的媒体类型，并相应设置响应的 ContentType 标头。在此示例中，文件扩展名是“bat”，进而生成 application/x-msdownload 的 Content-Type 标头（尽管实际 Content-Type 可能因服务器 OS 和 JAF 配置而异）。因此，一旦受害者访问此恶意 URL，他/她的计算机将自动开始下载包含攻击者控制内容的“.bat”文件。如果随后执行此文件，受害者计算机将运行攻击者有效负载指定的任何命令。

The Linux Standard Base Specification 2.0.1 for libc 对一些内部函数的参数进行了限制 [1]。如果函数的参数不满足这些约束条件，将无法定义函数的行为。


在下列 file system 函数中，值 1 必须传递给第一个参数（版本号）：

	__xmknod

在下列宽字符字符串函数中，数值 2 必须传递给第三个参数（组参数）：

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

在下列 file system 函数中，数值 3 必须作为第一参数（版本号）进行传递：

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

根据所使用的特定 C 编译器，系统 FILE 对象的地址对于将 FILE 对象用作流可能很重要。使用没有关联地址的 FILE 对象的副本可能会导致未定义的行为，从而造成潜在的系统信息泄露、系统崩溃或者使恶意操作者能够随意读取或编辑文件。

示例 1：以下代码显示了取消引用并通过值复制的系统 FILE 对象。

FILE *sysfile = fopen(test.file, "w+");
FILE insecureFile = *sysfile;

由于 sysfile 在 insecureFile 的赋值中被取消引用，使用 insecureFile 会导致各种各样的问题。

在系统 FILE 对象关联的流关闭后对该对象执行文件操作会导致未定义的行为。根据所使用的具体 C 编译器，文件操作可能会导致系统崩溃，甚至可能导致修改或读取相同或不同的文件。

示例 1：以下代码显示在关闭相应流之后尝试读取系统 FILE 对象。

FILE *sysfile = fopen(test.file, "r+");
res = fclose(sysfile);
if(res == 0){
    printf("%c", getc(sysfile));    
}

因为 getc() 函数在 sysfile 文件流关闭之后运行，getc() 导致未定义的行为，并可能导致系统崩溃，或者可能导致修改或读取相同或不同的文件。

删除托管指针后，如果指针管理代码假设该指针仍然有效，将引发程序崩溃或执行错误的操作。以下示例可说明这一错误。

  std::auto_ptr<foo> p(new foo);
  foo* rawFoo = p.get();
  delete rawFoo;

仅当托管指针类支持“分离”操作，允许程序员控制特定指针的内存管理时，此规则不适用。如果程序在调用 delete 之前将指针从管理类中分离出来，则管理类知道以后不再使用该指针。