反映型檔案下載 (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」檔案。如果隨後執行此檔案，受害者機器便會執行攻擊者承載所指定的任意指令。

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;

由於指派 insecureFile 時將 sysfile 解除參照，使用 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 前從管理類別分離該指標，管理類別未來將不會再使用該指標。