浮雲雅築: 1月 2026

2026年1月23日星期五

[研究]NIST 安全軟體開發框架 (Secure Software Development Framework (SSDF))

[研究]NIST 安全軟體開發框架 (Secure Software Development Framework (SSDF))

2026-01-23

NIST SSDF
https://csrc.nist.gov/projects/ssdf

SP 800‑218 (SSDF)
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

SP 800‑218A (AI 專用擴充)
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218A.pdf

SP 800‑218A 的初稿（已被最終版本取代）
https://csrc.nist.gov/pubs/sp/800/218/a/ipd

1️⃣ 框架背景

NIST SSDF 是由美國國家標準與技術研究院 (NIST) 推出的指南，主要目標是幫助組織在軟體開發全生命周期中落實安全實踐，降低軟體漏洞與供應鏈風險。

發布時間：2020 年 9 月（初版），隨後持續更新
目標對象：軟體開發者、企業安全團隊、DevSecOps 團隊
性質：建議性框架（不是硬性標準），可與現有 SDLC、DevOps 流程結合

2️⃣ 核心概念

SSDF 強調在軟體全生命周期中內建安全，主要分為四大類活動：

類別	英文名稱	核心內容
1. 形成安全開發基礎	Prepare the Organization (PO)	建立安全政策、流程與資源；提供開發人員安全訓練；確保開發工具安全。
2. 保護軟體工程資產	Protect Software (PS)	管理和保護源代碼、第三方元件、配置檔及建置工件；使用安全的開發與建置工具。
3. 產出安全軟體	Produce Well-Secured Software (PW)	在軟體設計、編碼、測試階段落實安全控制，如靜態分析 (SAST)、動態分析 (DAST)、依賴性掃描、單元測試等。
4. 回應與修復安全問題	Respond to Vulnerabilities (RV)	建立漏洞回報與修復流程；追蹤與管理已知漏洞；確保快速發布安全更新。

簡單說：SSDF 就是把「安全從一開始就內建到軟體開發流程」的概念制度化。

3️⃣ 核心實踐範例

PO – 組織準備

訂定安全軟體政策和標準
安排開發人員安全培訓
評估與採購安全工具

PS – 保護軟體

管理源碼存取權限
加密敏感資料
對第三方套件進行安全檢查

PW – 產出安全軟體

實施代碼審查 (Code Review)
使用自動化靜態與動態分析工具
建立安全測試案例與 CI/CD 集成

RV – 回應漏洞

設置漏洞報告管道
評估漏洞風險與優先修復
發布安全更新與通告

4️⃣ SSDF 的價值

降低軟體漏洞與供應鏈風險
提升組織安全成熟度
可與 DevSecOps 流程無縫整合
支援合規需求（如 CISA、NIST RMF、ISO/IEC 27001）

********************************************************************************

SP 800‑218 (SSDF)、SP 800‑218A (AI 專用擴充)

📌 1. 文件主要用途比較

📄 NIST SP 800‑218 — Secure Software Development Framework (SSDF) Version 1.1

👉 定位與內容：

這是 NIST 的核心指南，定義了一套通用的安全軟體開發框架（SSDF），以降低軟體漏洞風險。它提出一系列高階安全開發實務與任務，涵蓋軟體開發生命周期（SDLC）中的安全性整合。

✔ 它的目的是提供所有軟體開發者與採購者一套可通用, 風險導向的實務框架。

✔ 不僅適合傳統軟體，也可以作為其他安全指南的基礎。

📌 內容範圍

安全開發基本實務與建議
定義如何在 SDLC 中有效地「預防、偵測、緩解」弱點
無針對特定技術（如 AI）
重點在確保所有軟體安全開發能降低軟體漏洞風險

📄 NIST SP 800‑218A — SSDF Community Profile for Generative AI and Dual‑Use Foundation Models

👉 定位與內容：

這是一份補充性（Companion）指南，以 SP 800‑218 為基礎，但專注於生成式 AI 與兩用基礎模型的安全開發實務。

✔ 它擴展 SSDF 實務，加入更多與 AI 模型相關的安全任務、考量與建議。

✔ 目的是回應美國總統行政命令對「安全及可信任 AI」的要求。

📌 內容重點

針對 AI 模型開發生命周期：資料來源、訓練、微調、評估、整合等
引入與 AI 相關的風險與威脅（如資料污染、模型偷竊、惡意訓練資料等）
建議額外的安全實務與注意事項，用於補強 SSDF 原則
主要讀者是 AI 模型生產者、AI 系統開發者、AI 系統採購者

📌 與 800‑218 的關係

SP 800‑218A 不是替代 SSDF，而是用來擴增與特定領域（AI）相關的安全實務，須搭配 SP 800‑218 一起使用。

📌 2. 兩者最主要的差異總結

方面	SP 800‑218 (SSDF)	SP 800‑218A (AI 專用擴充)
主要用途	安全軟體開發通用框架	AI／生成式模型安全開發實務
內容核心	軟體安全實務與流程	擴展 SSDF，加入 AI 特定建議
適用範圍	全部軟體開發	AI 模型與 AI 系統
受眾	軟體開發者與採購者	模型生產者、AI 系統開發／採購者
與行政命令	主要基礎框架	直接支持 AI 相關行政命令要求
是否獨立	是	不是（須配合 SSDF）

📌 3. 800‑218 系列還有其他相關文件嗎？

是的，但主要相關的是這兩份。目前並沒有太多更多的“800‑218 系列文件”在正式出版狀態。

已知與 SSDF 相關的：

📍 SP 800‑218：主 SSDF 文檔（可視為基礎款）

📍 SP 800‑218A：針對生成式 AI 與基礎模型的 SSDF Community Profile（補充）

📍 SP 800‑218A 的初稿（已被最終版本取代）：在 2024 年初公開徵求意見後，被最終版本替代。

📌 4. 關於 SP 系列是否有其他 AI 或安全相關延伸文件？

NIST 的 SP 800 系列非常龐大，包含許多與資訊安全相關的出版品（例如身份驗證指南 SP 800‑63、事件處理 SP 800‑61 等）。

不過與 SSDF（800‑218）直接相關的補充資源目前只有：

👉 SP 800‑218 — SSDF 主框架

👉 SP 800‑218A — SSDF Community Profile for Generative AI

目前尚未有 800‑218B、C 等更多子系列（如 171、171A 那樣的 pairing）。如果未來 NIST 再擴展 SSDF 為其他特定領域（如 IoT、車載系統、AI 進階），可能會出現類似 800‑218B 等，但截至目前為主僅到 218A。

📌 5. 小結

✔ SP 800‑218 是一份通用的安全軟體開發框架指南。

✔ SP 800‑218A 是一份補充資料，聚焦於生成式 AI 與基礎模型相關安全開發實務，需要與 SP 800‑218 共同使用。

✔ 目前沒有其他已發布的“800‑218 系列”正式文檔（例如 800‑218B / C…）。

(完)

[研究]GCB，IIS，"要求篩選"，"允許未列出的副檔名"取消勾選，"允許副檔名" 首頁處理

2026-01-23

.aspx 加入允許名單

下圖，同一個網站，https://localhost/default.aspx 正常

下圖，同一個網站，https://localhost/ 被攔截了

下圖，解決方法，新增一個 "." (句點)，沒有副檔名名稱的檔案

下圖，否則網站有設定預設首頁也沒用

(完)

[研究]GCB，IIS，ASP.NET設定建議，.NET信任層級(trust leve)實測(二)

[研究]GCB，IIS，ASP.NET設定建議，.NET信任層級(trust leve)實測(二)

2025-01-21

環境：Visual Studio 2022 + ASP.NET + WebForm + Web Application + C# + SQL Server 2019 + SQL Server Management Studio (SSMS) 20.2

********************************************************************************

續

[研究]GCB，IIS，ASP.NET設定建議，.NET信任層級(trust leve)實測(一)
https://shaurong.blogspot.com/2026/01/gcbiisaspnetnettrust-leve.html

上次是 ASP.NET 網頁，這次改用只有 .html 網頁

程式只有顯示 test 字串，沒別的。

Default.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title></title>
</head>
<body>
Test
</body>
</html>

********************************************************************************

Deploy 到網站後，先測試網站正常

下圖，

下圖，這次別說從 Full 改設為 High，再嚴格到 Medium，也正常顯示，因為 .html 網頁不會用到 .NET Framework

(完)

[研究] IIS 10.0 GCB "要求篩選與其他限制模組"，"允許未列出的副檔名" ，那些副檔名被攔截，實測

[研究] IIS 10.0 GCB "要求篩選與其他限制模組"，"允許未列出的副檔名" ，那些副檔名被攔截，實測

2026-01-20

********************************************************************************

Windows Server 從Windows Server 2016開始，IIS為10.0版，後續 Windows Server 2019, Windows Server 2022, Windows Server 2025 也都是 10.0版，大版本號碼相同，小版本可能不同，畫面幾乎相同。

政府組態基準(Government Configuration Baseline，簡稱GCB)

TWGCB-04-014_Microsoft IIS 10政府組態基準說明文件v1.1_1141002

https://www.nics.nat.gov.tw/core_business/cybersecurity_defense/GCB/GCB_Documentation/

https://download.nics.nat.gov.tw/api/v4/file-service/UploadFile/attachfilegcb/TWGCB-04-014_Microsoft%20IIS%2010%E6%94%BF%E5%BA%9C%E7%B5%84%E6%85%8B%E5%9F%BA%E6%BA%96%E8%AA%AA%E6%98%8E%E6%96%87%E4%BB%B6v1.1_1141002.pdf

項次	TWGCB-ID	類別	原則設定名稱	說明	設定位置	設定路徑	GCB設定值
31	TWGCB-04-014-0031	要求篩選與其他限制模組	允許未列出的副檔名	▪這項原則設定決定是否允許未列出的副檔名在網頁伺服器上被執行 ▪限制網頁伺服器只能執行特定之檔案類型，可提升安全性 ▪在取消勾選「允許未列出的副檔名」後，必須將網站中所有使用到之副檔名(例如：.asax、.cs及.html等)加入允許清單，網頁才能正常運作	伺服器	▪取消勾選： IIS管理員\伺服器\IIS\要求篩選\動作\開啟功能\動作\編輯功能設定\一般\不勾選「允許未列出的副檔名」 ▪新增允許副檔名： IIS管理員\伺服器\IIS\要求篩選\動作\開啟功能\動作\允許副檔名	不允許

下圖，程式在 Visual Studio 2019 中執行正常

下圖，

Deploy 後，照 GCB 要求設定「允許未列出的副檔名」為「不允許」

**********

HTTP 錯誤 404.7 - Not Found

要求篩選模組設定為拒絕副檔名。

最有可能的原因:

已為網頁伺服器設定要求篩選，並且明確拒絕此要求的副檔名。

解決方法:

確認 applicationhost.config 和 web.config 中的 configuration/system.webServer/security/requestFiltering/fileExtensions 設定。

詳細錯誤資訊:

模組 RequestFilteringModule

通知 BeginRequest

處理常式 ExtensionlessUrlHandler-Integrated-4.0

錯誤碼 0x00000000

要求的 URL https://localhost:443/

實體路徑 D:\Production\Test443

登入方法尚未判定

登入使用者尚未判定

詳細資訊:

此為安全性功能。除非完全瞭解變更的範圍，否則請勿變更此功能。如果要允許要求的副檔名，則移除 configuration/system.webServer/security/requestFiltering/fileExtensions 中拒絕的副檔名。

檢視詳細資訊 »

**********

下圖，上圖點 "檢視詳細資訊"

檢視網站目錄中檔案，添加允許的副檔名

移除 .config、新增 .config (預設有，但為 False，無法變更設定，只好刪除後，新增允許)

新增 .aspx、.axd、.dll、.exe、.pdb、.rsp、.targets

註：.axd 檔案是動態產生的，不在目錄中。

依然失敗，訊息沒有明確說明哪個副檔名被禁止，微軟 Microsoft 官方也沒有公布全部 ASP.NET WebForm 會用的副檔名清冊。

而且還有第三方元件用到的所有檔案的副檔名也是一個問題，看得到的好添加，若動態產生的新副檔名的也難預知。

暫時無解，建議排除。

********************************************************************************

2026-01-16補

實際測試，「網站」層級設定可以覆蓋「伺服器」層級設定。

【「允許未列出的副檔名」設定為「不允許」】

「伺服器」層級設定修改 C:\Windows\System32\inetsrv\config\applicationHost.config

<configuration>
   <system.webServer>
      <security>
         <requestFiltering>
            <fileExtensions allowUnlisted="false" />
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>

「網站」層級修改網站根目錄 Web.Config

<configuration>
   <system.webServer>
      <security>
         <requestFiltering>
            <fileExtensions allowUnlisted="false" />
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>

(看起來相同)

【副檔名白名單】

「伺服器」層級設定修改 C:\Windows\System32\inetsrv\config\applicationHost.config

<requestFiltering>
   <fileExtensions allowUnlisted="false">
      <add fileExtension=".aspx" allowed="true" />
   </fileExtensions>
</requestFiltering>

「網站」層級修改網站根目錄 Web.Config

<requestFiltering>
   <fileExtensions allowUnlisted="false">
      <add fileExtension=".aspx" allowed="true" />
   </fileExtensions>
</requestFiltering>

(看起來相同)

(完)

[研究]IIS 10.0 GCB，"要求篩選"，"允許未列出的指令動詞" 變成不勾選

[研究]IIS 10.0 GCB，"要求篩選"，"允許未列出的指令動詞" 變成不勾選

2025-01-23

TWGCB-04-014-0031 是 "允許未列出的副檔名"，

但 "允許未列出的副檔名" 不在 GCB 要求中，

ASP.NET WebForm，在測試 IIS 10.0 GCB，"要求篩選"，"允許未列出的副檔名"，"允許副檔名"，Web.Config 過程中，不知何時、何原因，某些網站 "允許未列出的指令動詞" 變成不勾選

ChatGPT 提的一堆檢查都不是，但有句話值得注意，

副檔名 (File Extensions) 與指令動詞 (HTTP Verbs) 是同一個模組：Request Filtering

關聯影響有空再研究、、、

(待研究)

2026年1月22日星期四

[研究]GCB，IIS，ASP.NET設定建議，.NET信任層級(trust leve)實測(一)

[研究]GCB，IIS，ASP.NET設定建議，.NET信任層級(trust leve)實測(一)

2025-01-21

環境：Visual Studio 2022 + ASP.NET + WebForm + Web Application + C# + SQL Server 2019 + SQL Server Management Studio (SSMS) 20.2

********************************************************************************

發現ASP.NET WebForm 預設建立的方案，使用 .NET Framework 4.8

程式只有顯示 test 字串，沒別的。

Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" 
    Inherits="WebApplication1.Default" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
        test
    </form>
</body>
</html>

Default.aspx.cs

using System;

namespace WebApplication1
{
    public partial class Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }
    }
}

********************************************************************************

Deploy 到網站後，先測試網站正常

下圖，把預設值 Full 改為 High

下圖，測試

錯誤訊息

'/' 應用程式中發生伺服器錯誤。
安全性例外狀況
描述: 應用程式嘗試執行安全原則不允許的作業。如果要授與這個應用程式所需的權限，請聯繫您的系統管理員，或在組態檔中變更這個應用程式的信任層級。

例外狀況詳細資訊: System.Security.SecurityException: 要求已經失敗。

原始程式錯誤:

在執行目前 Web 要求期間，產生未處理的例外狀況。如需有關例外狀況來源與位置的資訊，可以使用下列的例外狀況堆疊追蹤取得。

堆疊追蹤:


[SecurityException: 要求已經失敗。]
   System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type) +0
   System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName) +96
   System.Type.GetType(String typeName) +62
   System.CodeDom.Compiler.CompilerInfo.get_IsCodeDomProviderTypeValid() +15
   System.Web.Compilation.CompilationUtil.GetRecompilationHash(CompilationSection ps) +2406
   System.Web.Configuration.CompilationSection.get_RecompilationHash() +110
   System.Web.Compilation.BuildManager.CheckTopLevelFilesUpToDateInternal(Int64 cachedHash) +551
   System.Web.Compilation.BuildManager.CheckTopLevelFilesUpToDate(Int64 cachedHash) +59
   System.Web.Compilation.BuildManager.ExecutePreAppStart() +155
   System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +746

版本資訊: Microsoft .NET Framework 版本:4.0.30319; ASP.NET 版本:4.8.4797.0

********************************************************************************

ASP.NET WebForm，System.Security.Permissions.ReflectionPermission 是甚麼 ?

System.Security.Permissions.ReflectionPermission 不是第三方套件，而是：

👉 .NET Framework 內建的類別
👉 隸屬於程式碼存取安全性（Code Access Security, CAS）架構

📦 所屬 Assembly（組件）：mscorlib.dll

也就是說：

不需要安裝 NuGet
不需要額外引用 DLL
只要是 .NET Framework（非 .NET Core / .NET 5+）都一定存在

********************************************************************************

CAS被微軟棄用，建議設定Full，否則很多程式庫不能用。但微軟對 .NET 4.0 開始宣導使用 Full Trust。

Code Access Security

https://learn.microsoft.com/en-us/previous-versions/dotnet/framework/code-access-security/code-access-security

Because Code Access Security is deprecated, most modern code within the .NET ecosystem is not designed to operate within a partial trust environment. Applications that rely on CAS should not expect modern libraries to behave correctly within these environments, unless the library developer has taken explicit steps to ensure compatibility within the CAS sandbox.

由於程式碼存取安全性 (CAS) 已被棄用，.NET 生態系統中的大多數現代程式碼並非設計用於在部分信任環境中運作。依賴 CAS 的應用程式不應期望現代函式庫在這些環境中正常運行，除非函式庫開發者已採取明確措施確保其與 CAS 沙箱的兼容性。

********************************************************************************

看來以 ASP.NET WebForm 專案而言，其使用的 .NET Framerwork 的 .NET信任層級(trust leve) 必須 Full Trust。(除非你在 IIS 上不要架設 ASP.NET 網站，例如改用 PHP 或其他)

(完)

[研究]ASP.NET trust level、部分信任 (Partial Trust)、程式碼存取安全性 (Code Access Security, CAS)、.NET信任層級

[研究]ASP.NET trust level、部分信任 (Partial Trust)、程式碼存取安全性 (Code Access Security, CAS)、.NET信任層級

2026-01-22

以下用 ASP.NET 的實務脈絡，把 Trust Level、部分信任（Partial Trust）、CAS（Code Access Security）的關係一次講清楚，也會點出哪些是歷史機制、哪些在新版本已經名存實亡。

一句話先講結論

ASP.NET Trust Level 是「套用在 Web App 上的一組 CAS 權限集合」

Partial Trust：靠 CAS 限制程式能做什麼
Full Trust：幾乎不套用 CAS 限制
.NET 4.5+ / ASP.NET 4.6+：CAS 對 Web App 幾乎已廢棄

一、名詞各自是什麼？

1️⃣ Code Access Security（CAS）

最底層的安全模型（.NET Framework 傳統機制）

目的：限制程式碼「能做什麼」
判斷依據：

程式碼來源（URL、Strong Name、Zone）
授與對應的 Permission

常見 Permission：

FileIOPermission
SecurityPermission
ReflectionPermission
WebPermission

📌 重點

CAS 是一套「在 CLR 層級執行的安全沙盒」

2️⃣ Partial Trust（部分信任）

CAS 的一種實際使用模式

表示：

程式不是 Full Trust
只能使用被授權的 CAS Permissions

典型使用場景（過去）：

Shared Hosting
多租戶 IIS
不信任的第三方元件

📌 Partial Trust ≠ ASP.NET 專屬

它是 CAS 的一種狀態

3️⃣ ASP.NET Trust Level

ASP.NET 對 CAS 的「封裝設定」

用來決定：

這個 Web Application 跑在哪一組 CAS 權限集合

設定方式：

<trust level="Medium" />

📌 Trust Level 不是新的安全模型

它只是把 CAS PermissionSet 包成好用的名稱

4️⃣ .NET 信任層級 (Framework Trust Level)

定義：.NET 框架本身支援信任層級的概念，用來定義程式碼可以執行的權限範圍。

與 ASP.NET 的對應：

ASP.NET 透過 <trust> 將 ASP.NET 層級的設定，轉換為 .NET CAS 權限集。

也就是說：


ASP.NET Trust Level → 對應 .NET CAS 權限集 → 決定程式碼可做的操作

實務注意：

在 Full Trust 下，CAS 幾乎不會限制應用程式。
在 Medium / Low Trust 下，CAS 會阻擋部分 API，如 Reflection、IO 操作等。

二、ASP.NET Trust Level 與 CAS 的對應關係

ASP.NET Trust Level	本質	使用的安全模型
Full	無限制	幾乎不使用 CAS
High	少量限制	CAS
Medium	明顯限制	CAS
Low	極度限制	CAS
Minimal	幾乎不能用	CAS

👉 Trust Level = 預先定義好的 CAS PermissionSet

三、實際例子（Partial Trust 下會發生什麼）

🚫 在 High Trust 常見會失敗的事情

🚫 在 Medium Trust 常見會失敗的事情

範例：

File.ReadAllText(@"C:\test.txt");   // ❌ FileIOPermission

範例：

Assembly.LoadFrom("xxx.dll");       // ❌ Reflection / Load 權限

範例：

Environment.Exit(0);                // ❌ SecurityPermission

範例：

[DllImport("user32.dll")]
static extern int MessageBox(...);  // ❌ UnmanagedCode

📌 這些錯誤都是 CAS 在擋，不是 IIS 在擋

四、ASP.NET Trust Level 設定在哪？

Web.config

<system.web>
  <trust level="Medium" originUrl="" />
</system.web>

Machine.config（全機器）

<trust level="Full" />

五、重要歷史轉折（一定要知道）

🔥 .NET 4 之後的重大變化

時期	狀況
.NET 2.0–3.5	CAS 是主流
.NET 4.0	CAS 預設關閉多數 Policy
.NET 4.5+	ASP.NET Partial Trust 幾乎不再支援
ASP.NET Core	❌ 完全沒有 CAS

📌 Microsoft 官方立場

不再建議使用 CAS / Partial Trust

改用 OS / IIS / Container / Account-based Security

六、現代 ASP.NET 實務建議（重點）

❌ 不要再依賴

Partial Trust
Medium / Low Trust
CAS Permission

✅ 改用

層級	作法
OS	低權限 App Pool Identity
IIS	Request Filtering / Handler
檔案	NTFS ACL
程式	Sandbox Process / Container
架構	Microservice / API 隔離

七、三者關係圖（文字版）

ASP.NET Trust Level
        ↓
   CAS PermissionSet
        ↓
  Partial Trust / Full Trust
        ↓
   CLR 在 Runtime 阻擋或放行

八、快速總結表

名詞	本質
CAS	.NET Framework 的程式碼權限系統
Partial Trust	使用 CAS 限制程式能力
ASP.NET Trust Level	ASP.NET 封裝的 CAS 設定組

********************************************************************************

在 High Trust 常見會失敗的事情 ?

一、High Trust 與 Full Trust 的核心差異

能力	High Trust	Full Trust
CAS 啟用	✅ 有	❌ 幾乎無
Unmanaged Code	❌	✅
任意反射	❌（有限）	✅
任意檔案 IO	⚠️（有限）	✅
操作系統層級	❌	✅

二、High Trust 下「常見會失敗」的事情（重點）

1️⃣ 呼叫 Unmanaged Code（最常見）

[DllImport("user32.dll")]
static extern int MessageBox(IntPtr hWnd, string text, string caption, int type);

📛 結果

SecurityException:
Request for the permission of type 'System.Security.Permissions.SecurityPermission' failed.

📌 原因

High Trust 不包含 UnmanagedCode 權限
所有 P/Invoke 都會失敗

2️⃣ 載入「未完全信任」的 Assembly

Assembly.LoadFrom(@"C:\temp\plugin.dll");

📛 可能錯誤

SecurityException: Request for ReflectionPermission failed

📌 原因

High Trust 仍限制：
動態載入來源不明 DLL
非 Strong Name Assembly

3️⃣ 反射存取 Non-Public 成員

typeof(MyClass)
  .GetField("_secret", BindingFlags.NonPublic | BindingFlags.Instance);

📛 原因

High Trust 僅允許受限反射
不允許任意存取 private / internal 成員

4️⃣ 嘗試提升權限（Assert / Demand）

new FileIOPermission(PermissionState.Unrestricted).Assert();

📛 結果

SecurityException

📌 原因

High Trust 不能提升自身權限
CAS 只允許向下使用，不允許自行放大

5️⃣ 操作其他 AppDomain / Process

Process.Start("cmd.exe");

📛 原因

需要 SecurityPermission(ControlAppDomain / UnmanagedCode)
High Trust 不允許

6️⃣ 讀寫不在允許範圍內的檔案

File.WriteAllText(@"C:\Windows\test.txt", "x");

📛 結果

SecurityException: FileIOPermission

📌 說明

High Trust 通常只允許

App Root
特定 temp / data 目錄

7️⃣ 使用需要 Full Trust 的第三方套件

📛 常見套件類型：

PDF / Office COM Interop
Image 處理（GDI+ 深度操作）
系統層級監控
舊版報表元件

📌 症狀

在本機正常
部署到 High Trust Host 就爆炸

三、High Trust「看似可以，其實有坑」的事情

✔ 有時可用（取決於實作）

Reflection（public only）
部分 Environment 資訊
網路存取（HTTP / HTTPS）

❌ 絕對不行

P/Invoke
COM Interop
Registry 任意存取
操作 Windows Service

四、為什麼還會有 High Trust？

👉 歷史原因

Shared Hosting
一台 IIS 跑多個客戶
Host 想保護 OS
但現代已不建議使用

五、實務建議（非常重要）

如果你現在遇到「High Trust 才會出錯」

請直接假設：

你需要 Full Trust

然後改用：

方案	說明
Full Trust App Pool	最直接
低權限帳號 + Full Trust	比 CAS 安全
Container / VM	真正隔離
API 外掛	把危險操作拆出去

六、快速對照表

行為	High Trust
File IO（App 資料夾）	✅
HTTP 存取	✅
Reflection（public）	✅
Reflection（private）	❌
P/Invoke	❌
COM	❌
Process.Start	❌
Registry	❌

(完)

2026年1月21日星期三

[研究]IIS，要求篩選，"允許未列出的指令動詞"，甚麼是 "指令動詞" ? 勾選、不勾選的意義? 影響 ?

[研究]IIS，要求篩選，"允許未列出的指令動詞"，甚麼是 "指令動詞" ? 勾選、不勾選的意義? 影響 ?

2026-01-21

ASP.NET，WebForm，IIS，要求篩選，"允許未列出的指令動詞"，甚麼是 "指令動詞" ? 勾選、不勾選的意義? 影響 ?

ChatGPT

在 IIS（Internet Information Services）→ 要求篩選（Request Filtering）中，

「允許未列出的指令動詞」這個選項常讓人困惑，下面用清楚、偏實務的方式說明。

一、什麼是「指令動詞（Verb）」？

在 IIS 裡，「指令動詞」指的是 HTTP Method（HTTP 動作），也就是瀏覽器或用戶端對伺服器發送請求時，所使用的動作種類。

常見 HTTP 指令動詞

指令動詞	說明
GET	取得資源（最常見，瀏覽網頁）
POST	傳送資料（表單送出）
HEAD	只取得 Header，不含內容
PUT	上傳 / 覆寫資源
DELETE	刪除資源
OPTIONS	查詢伺服器支援哪些動詞
TRACE	回傳請求內容（有資安風險）
PATCH	局部更新資源
PROPFIND	WebDAV 用

👉 這些不是副檔名、不是 URL，而是 HTTP 通訊協定層級的「動作」。

二、「允許未列出的指令動詞」是什麼意思？

當用戶端送來的 HTTP Method，不在你明確列出的清單裡時，要不要放行？

白話翻譯

設定	意義
☑ 勾選（允許）	沒列出來的動詞，一律放行
☐ 不勾選（不允許）	只允許你明確列出的動詞，其它全部封鎖

三、勾選 vs 不勾選的實際差異

✅ 勾選「允許未列出的指令動詞」（預設值）

行為

IIS 只封鎖你明確拒絕的動詞
其餘 HTTP Method 全部接受

特性

相容性高
比較不會誤擋應用程式
安全性較鬆

適合

傳統 ASP.NET WebForms / MVC
舊系統、不確定會用到哪些 Method
沒有對外 API 的網站

❌ 不勾選「允許未列出的指令動詞」

行為

IIS 採用「白名單模式」
只允許「允許指令動詞」清單中的 Method
其他一律 404.6 / 405

特性

安全性高
但容易擋到功能

適合

對外 API
高資安要求系統
明確知道只用 GET / POST 的網站

四、實際影響範例

情境 1：只允許 GET、POST

IIS 設定：

❌ 不勾選「允許未列出的指令動詞」
允許指令動詞：

GET
POST

結果

動詞	結果
GET	✅ 正常
POST	✅ 正常
HEAD	❌ 404.6
OPTIONS	❌ 404.6
PUT	❌ 404.6

⚠ HEAD / OPTIONS 被擋，可能造成：

健康檢查失敗
CORS 問題
某些瀏覽器行為異常

五、與常見 IIS 錯誤碼的關係

HTTP 錯誤	意義
404.6	指令動詞被要求篩選拒絕
405	動詞不被該資源支援
404.7	副檔名被拒絕（不是動詞問題）

👉 404.6 = 動詞問題

👉 404.7 = 副檔名問題

六、實務建議（給 ASP.NET WebForms）

✔ 一般 WebForms 網站（非 API）

✅ 勾選「允許未列出的指令動詞」

不額外限制 Verb
把安全重點放在：

副檔名白名單
不需要的 Handler / Module

✔ 若要加強資安（仍是 WebForms）

不勾選
至少允許

GET
POST
HEAD
OPTIONS

七、一句話總結

「指令動詞」就是 HTTP Method（GET / POST / PUT…）
預設，勾選 = 放行未知動詞（相容性高）
不勾選 = 嚴格白名單（安全性高，但易誤擋）

(完)

2026年1月20日星期二

[研究]比較「Windows Search 服務」與第三方搜尋工具 Everything

2026-01-20

Everything

https://www.voidtools.com/

**********

Windows Serach

📌 一、基本功能 & 設計目的比較

項目	Windows Search	Everything
開發者 / 來源	Microsoft（Windows 內建）	Voidtools（獨立第三方工具）
主要用途	系統全文索引與檔案搜尋（含內容）	文件名稱與路徑即時索引與搜尋
索引類型	檔案名稱＋檔案內容（視設定而定）	只有檔案名稱 / 路徑
更新方式	自動索引，背後服務持續監控變動	利用系統 NTFS 事件快速更新
搜尋速度	快（視索引建立狀況而定）	極快（甚至比 Windows Search 更快）
介面	系統整合（開始選單搜尋、Explorer 搜尋框）	單獨視窗介面
啟動成本 / 資源佔用	有背後服務與索引資料庫	輕量，啟動即查
支援全文內容查詢	✅（可針對內容）	❌（只能依名稱／路徑）
搜尋結果預覽	Explorer / 預覽窗格	提供基本預覽支援（需另支援）

********************************************************************************

"Windows Serach" 服務檔案名稱？

在 Windows Server 2019 工作管理員看到 SerachUI.exe

在 Windows 10 工作管理員看到 SerachIndexer.exe、SearchApp.exe

不同作業系統不同？這些檔案差異？

ChatGPT

1️⃣ Windows Search 服務本質

服務名稱 (Service Name)：WSearch
作用：建立檔案名稱與內容的索引（Windows Search Indexer），讓系統搜尋與 Explorer 搜尋、Cortana 等快速回應。
啟動方式：在「服務」裡叫 Windows Search，或透過 PowerShell / sc query WSearch 查看。

2️⃣ Windows 10 與 Windows Server 2019 的差異

作業系統	工作管理員看到的檔案	檔案用途 / 解釋
Windows 10	`SearchIndexer.exe`	真正的索引服務主程式，負責建立與更新索引
	`SearchApp.exe`	搜尋介面前端 (UWP App)，用於開始選單搜尋、Cortana、設定搜尋框
Windows Server 2019	`SearchUI.exe`	對應搜尋使用者介面 (Windows 10 Server 也可能有 UWP 搜尋介面)，但 Server 版通常不預設 GUI 搜尋功能
	`SearchIndexer.exe`	同 Windows 10，負責索引服務

3️⃣ 關鍵差異

索引核心不變

不管 Windows 10 / Server 2019，索引服務都由 SearchIndexer.exe 提供。
它持續掃描檔案變動，維護資料庫。

搜尋介面不同

Windows 10: 有 UWP 前端 (SearchApp.exe)，整合開始選單和 Cortana
Windows Server: GUI 搜尋通常沒那麼完整，有時是 SearchUI.exe，提供最基本的搜尋框介面（Server Core 沒 GUI 時就沒有）

服務 vs 前端

SearchIndexer.exe → 服務核心，可以停用索引服務
SearchApp.exe / SearchUI.exe → 前端 GUI，依賴核心服務才能顯示結果
停用 Windows Search 服務，前端也會失效

4️⃣ 小結

核心服務檔案：SearchIndexer.exe（兩個 OS 都有）
前端 GUI：

Windows 10 → SearchApp.exe（UWP）
Windows Server 2019 → SearchUI.exe（Server GUI 版，功能簡化）

結論：

核心索引功能一致，但前端介面不同，這就是為什麼工作管理員看到的名稱不一樣
如果你只需要索引 / 檔名搜尋，停用 GUI 前端影響不大；如果依賴系統搜尋框，前端不能關

流程圖，對比 Windows 10 與 Windows Server 2019 的搜尋服務架構，標出「核心服務 vs 前端 GUI vs 系統整合」。

【Windows 10】
┌─────────────────────────────┐
│        使用者介面 / 前端        │
│  (Start Menu / Cortana / Explorer) │
│         ↕ 呼叫搜尋介面           │
│        SearchApp.exe (UWP)      │
└─────────────────────────────┘
               │
               │ 依賴核心服務
               ▼
┌─────────────────────────────┐
│      核心索引服務 / 索引資料庫  │
│       SearchIndexer.exe       │
│ - 檔名索引                    │
│ - 內容索引 (Word, PDF…)       │
│ - 即時更新 / NTFS 事件監控    │
└─────────────────────────────┘
               │
               ▼
        檔案系統 (NTFS / ReFS)

和

【Windows Server 2019】
┌─────────────────────────────┐
│        使用者介面 / 前端        │
│  (Server GUI 搜尋框 / Explorer) │
│         ↕ 呼叫搜尋介面           │
│        SearchUI.exe            │
│   (Server 版，功能簡化)       │
└─────────────────────────────┘
               │
               │ 依賴核心服務
               ▼
┌─────────────────────────────┐
│      核心索引服務 / 索引資料庫  │
│       SearchIndexer.exe       │
│ - 檔名索引                    │
│ - 內容索引 (視安裝 IFilter)   │
│ - 即時更新 / NTFS 事件監控    │
└─────────────────────────────┘
               │
               ▼
        檔案系統 (NTFS / ReFS)

🔹 圖解重點

1.核心一致：SearchIndexer.exe 都是核心，負責真正的索引和即時更新。

2.前端不同：

Windows 10 → SearchApp.exe (完整 UWP 搜尋整合)
Server 2019 → SearchUI.exe (簡化版)

3.停用核心服務後：

前端 GUI 也會失效 → Explorer 搜尋框 / 開始選單搜尋無法使用

4.Everything 介入：

不依賴 Windows Search 服務
自行建立檔名 / 路徑索引
提供極速搜尋回應

(完)

[研究]Windows「列印後台處理程序」（Print Spooler）、列印到 pdf 印表機、儲存成pdf

[研究]Windows「列印後台處理程序」（Print Spooler）、列印到 pdf 印表機、儲存成pdf

2026-01-20

下圖，Windows Server 2019畫面，

1️⃣ 名稱與服務

服務名稱（Service Name）：Spooler

顯示名稱（Display Name）：列印後台處理程序（Print Spooler）

可在服務管理器看到：services.msc → Print Spooler

2️⃣ 執行程式與檔案

主要執行檔（EXE）：C:\Windows\System32\spoolsv.exe

其他相關檔案：

C:\Windows\System32\spool\PRINTERS：列印暫存資料夾
C:\Windows\System32\spool\drivers：列印驅動程式

作用：負責管理列印工作，將列印請求排入列印隊列，並呼叫印表機驅動程式。

3️⃣ 主要用途

列印排程：將列印工作（文件、圖片等）存入暫存隊列，再依序送到印表機。
列印快取：避免應用程式直接與印表機通訊，提高效率。
管理多個印表機：可以同時處理多個印表機的列印請求。
支援遠端列印：網路印表機或共享印表機也由 Spooler 管理。

.pdf是否依賴「列印後台處理程序」（Print Spooler）

功能類型	運作方式	依賴 Print Spooler?
存成 PDF / 匯出 PDF	軟體內部將文件轉成 PDF 檔案，直接寫入磁碟	❌ 不依賴 Spooler
列印到 PDF 虛擬印表機	軟體呼叫 Windows 列印 API → Spooler → PDF 虛擬印表機 → 寫入磁碟	✅ 依賴 Spooler

(完)