在 .NET 中，您可以使用 BinaryFormatter 類別將物件轉變為二進位串流，該二進位串流包含物件本身以及還原序列化期間重建物件所需的中繼資料。

使用 BinaryFormatter 類別可能導致不安全的還原序列化情景，攻擊者可以執行任意程式碼，濫用應用程式邏輯，或觸發 denial of service 條件。

使用 BinaryFormatter 類型是危險行為，不建議用於資料處理，因為它不能保證安全。

範例 1：該應用程式透過在 runtimeConfig.json 檔案中，將組態屬性 EnableUnsafeBinaryFormatterSerialization 設為 true，允許使用不安全的 BinaryFormatter。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

透過 AccessibleObject API，程式設計人員可以避開 Java 存取規範提供的存取控制檢查。特別是，程式設計人員可藉此允許回傳的物件避開 Java 存取控制，轉而變更私有欄位的值或呼叫私有方法、行為 (通常這是不允許的)。

在一般的 JSF 應用程式中，會使用 UI 元件指定的轉換器和驗證器來轉換值。轉換和驗證本身會在提交頁面時發生。Fusion 應用程式中可加上書籤的檢視不會導致任何頁面提交，因此預設不會執行任何類似的轉換或驗證。

範例 1：下列組態設定檔案片段顯示了一個可加上書籤的檢視範例，該檢視組態為不執行 paramName URL 參數的任何轉換或驗證。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Oracle ADF Faces 元件的屬性值通常只能在伺服器上設定。但是，有許多元件允許開發人員定義可以在用戶端上設定的屬性清單。這些元件的 unsecure 屬性可以指定此類清單。

目前，唯一能夠在 unsecure 屬性內顯示的屬性是 disabled，而且它允許用戶端定義哪些元件為啟用，而哪些元件不啟用。讓用戶端控制應該在僅能在伺服器上設定的屬性值，絕對不是個好方法。

範例 1：以下程式碼示範了 inputText 元件，該元件會從使用者收集密碼資訊，並使用 unsecure 屬性。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

根據 RFC 2109，Cookie 嚴格意義上來說是 HTTP 機制。 不應合理預期 Cookie 適用於除 HTTP 以外的通訊協定，包括 file://。 目前尚不確定其行為，以及應套用哪些安全性劃分規則。 例如，從網際網路下載到本機磁碟的 HTML 檔案是否應該與本機安裝的任何 HTML 程式碼共用相同的 Cookie？

不建議開發人員使用未記錄或隱藏的 API 建置其應用程式。 無法保證 Google 在將來不會移除或變更這些 API，因此應加以避免，採用此類方法或欄位有很高的風險性，可能中斷您對應用程式的使用。

程式碼嘗試在 Camera 物件被解除之後，使用該物件。若在未重新要求 Camera 物件的情況下參照該資源，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例 1：以下程式碼使用了切換按鈕以開啟和關閉相機預覽。在使用者點選按鈕後，相機預覽便會停止，並釋放相機資源。但是，如果再次點選按鈕，則會在先前釋放的 Camera 物件上呼叫 startPreview()。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

程式碼嘗試在媒體物件被解除之後使用該物件。若在未重新要求媒體物件的情況下參照該資源，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例 1：以下程式碼使用暫停按鈕以切換媒體播放。在使用者點選按鈕後，目前的歌曲或視訊便會停止，並釋放相機資源。但是，如果再次點選按鈕，則會在先前釋放的媒體資源上呼叫 start()。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

程式碼嘗試在 Android SQLite 資料庫處理常式已被解除後使用該處理常式。若在未重新建立資料庫連線的情況下參照該處理常式，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例 1：以下程式碼可能來自將使用者值暫時快取於記憶體中的程式，但可以呼叫 flushUpdates() 以將變更交付至磁碟。該方法會在更新寫入資料庫後正確關閉資料庫處理常式。然而，若再次呼叫 flushUpdates()，便會在重新初始化資料庫物件前再次參照該物件。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Android Class Loading Hijacking 弱點有以下兩種形式：

- 攻擊者可以變更程式為載入類別而搜尋的目錄名稱，從而指向處於其控制下之某個目錄的路徑：攻擊者明確控制應該從其中搜尋類別的路徑。

- 攻擊者可以篡改載入類別的環境：攻擊者間接控制路徑名稱代表的意義。

在此案例中，我們著重於第一種情況，即攻擊者可以控制為要載入之類別而搜尋的目錄的可能性。在以下情況下，會發生此類型的 Android Class Loading Hijacking 弱點：

1. 資料從不可信賴的來源進入應用程式。



2. 資料用作代表程式庫目錄的整個字串或一部分字串，以便搜尋要載入的類別。



3. 藉由從程式庫路徑執行程式碼，應用程式會給予攻擊者不應該擁有的權限或能力。

範例 1：以下程式碼使用使用者可變更的 userClassPath 來決定搜尋要載入的類別所在的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此程式碼能夠透過修改 userClassPath 的結果來指向所控制的其他路徑，從而讓攻擊者利用應用程式的提升權限，載入程式庫並潛在地執行任意程式碼。因為程式不會驗證從環境讀取的值，所以如果攻擊者可以控制 userClassPath 的值，則攻擊者便可使用與原始應用程式相同的權限，愚弄應用程式，讓應用程式指向他們所控制的目錄，從而載入他們所定義的類別。

範例 2：以下程式碼使用使用者可變更的 userOutput 來決定應寫入最佳化 DEX 檔案的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此程式碼可讓攻擊者指定最佳化 DEX 檔案 (ODEX) 的輸出目錄。然後，此程式碼還會讓惡意使用者將 userOutput 值變更為他們所控制的目錄，如外部儲存裝置。一旦完成竄改，便只需將輸出的 ODEX 檔案替換為惡意 ODEX 檔案，就可以使用與原始應用程式相同的權限執行該動作。

Android 應用程式可設定為產生除錯二進位程式。這些二進位程式提供了詳細的除錯訊息，不應該在生產的環境中使用。<application> 標籤的 debuggable 屬性定義編譯後的二進位程式是否應包含除錯資訊。

使用除錯二進位程式會使應用程式提供許多有關其本身的資訊給使用者。除錯二進位程式只能用於開發或測試的環境中，如果將它們部署在生產的環境中，會有安全上的風險。攻擊者可能利用這些從除錯輸出得到的額外資訊，來發動針對架構、資料庫或應用程式所使用的其他資源的攻擊。

當惡意動作執行者可以在指定 Zip 檔案中指定 Zip 檔案項目名稱時，就會出現 Zip Path Traversal 弱點。當惡意指定 Zip 檔案項目名稱時，攻擊者可以在擴充對應的 Zip 檔案時覆寫關鍵系統檔案的內容。攻擊者可能會使用此類路徑穿越習慣用法 (例如 ../ 和 /) 來存取不在程式範圍內的系統檔案。依預設，瞄準 Android 14 及更高版本的 Android 應用程式可能會在 Zip 檔案解壓縮過程中偵測到 ../ 和 / 等習慣用法時法時拋出異常。此安全功能可以被覆寫或完全停用。

範例 1：以下程式碼將停用 Zip Entry Overwrite Protection。

...
dalvik.system.ZipPathValidator.clearCallback();
...

藉由縮小檔案大小進行精簡，可提升應用程式中有 JavaScript 檔案頁面的讀取時間。精簡表示移除非必要內容的程序，這些內容包括空白字元、註解、分號、括號、縮短本機變數的名稱及移除無法取得的程式碼。

範例 1：下列 ASPX 程式碼包含 Microsoft jQuery 程式庫的未精簡版本：

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

在 ASP.NET Web API 服務中，未經驗證的輸入是弱點產生的主因之一。未經檢查的輸入資料會導致許多弱點的產生，包括 Cross-Site Scripting、Process Control、Access Control 和 SQL injection。雖然 ASP.NET Web API 服務在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 ASP.NET Web API 服務呼叫未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 ASP.NET Web API 服務中利用輸入驗證弱點發起 Buffer overflow 攻擊。

若要防止此類攻擊：
1. 使用驗證屬性將針對參數或模型繫結物件參數之成員執行的驗證檢查，以程式化方式註解至 ASP.NET Web API 服務動作。
2. 使用 ModelState.IsValid 檢查模型是否通過驗證。

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseCookiePolicy() 方法將 Cookie 原則中介軟體新增到中介軟體管道，進而允許自訂 Cookie 原則。當以錯誤的順序指定時，程式設計師聲明的任何 Cookie 原則將被忽略。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseHttpsRedirection() 方法將 HTTPS 重新導向中介軟體新增到中介軟體管道，進而允許將不安全的 HTTP 要求重新導向到安全的 HTTPS 要求。如果以錯誤的順序指定，則在透過重新導向之前列出的中介軟體處理要求之前，不會發生有意義的 HTTPS 重新導向。這將允許應用程式在重新導向到安全 HTTPS 連線之前處理 HTTP 要求。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseHttpLogging() 方法將 HTTP 記錄中介軟體新增到中介軟體管道，進而允許記錄中介軟體元件。當以錯誤的順序指定時，在呼叫 UseHttpLogging() 之前將不會記錄新增到管道的任何中介軟體。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

範例 2：UseWC3Logging() 方法將 W3C 記錄中介軟體新增到中介軟體管道，進而允許記錄中介軟體元件。當以錯誤的順序指定時，在呼叫 UseWC3Logging() 之前將不會記錄新增到管道的任何中介軟體。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

將憑證驗證模式設為 None 會停用整個憑證驗證過程，這會使應用程式暴露於 Man-in-the-Middle 攻擊之下。生產環境中永遠不應使用此模式。

Cookie 常用來儲存使用者的重要資訊，比如個人資訊、Authentication 標記以及作業的歷史資訊。如果此資訊是以純文字方式儲存，那麼任何人只要能夠存取與應用程式互動的機器，都能夠存取儲存在 cookie 中的資訊。更糟糕的是，如果攻擊者可以隨意修改 cookie 中的資料，他們便能夠偽造提供給應用程式的資訊，有可能改變系統的運作方式以對他們有利。

在許多情況下，應用程式可以根據所在的環境來驗證由 cookie 提供的輸入，但 ASP.NET 的驗證框架提供了一個非常好的方法，可保護 cookie 的內容並驗證 cookie 未遭到非期望的修改。如不使用此方法，想要建立所有輸入都經過驗證的高層級信任是非常困難、甚至是不可能的。

可設定 ASP .NET 應用程式來產生除錯二進位程式。這些二進位程式提供了詳細的除錯訊息，不應該在生產的環境中使用。<compilation> 標籤的 debug 屬性定義編譯後的二進位程式是否應包含除錯資訊。

使用除錯二進位程式會使應用程式提供許多有關其本身的資訊給使用者。除錯二進位程式只能用於開發或測試的環境中，如果將它們部署在生產的環境中，會有安全上的風險。攻擊者可能利用這些從除錯輸出得到的額外資訊，來發動針對架構、資料庫或應用程式所使用的其他資源的攻擊。