浮雲雅築: 6月 2026

2026年6月5日星期五

[研究]Mend (WhiteSource) 又來第五次修改建議

2026-06-05

(完)

[研究]Mend (WhiteSource) 又來第四次修改建議

2026-06-05

(完)

[研究]Mend (WhiteSource) 建議錯誤，改錯程式了

[研究]Mend (WhiteSource) 建議錯誤，改錯程式了

2026-06-05

因為速度差異太大，所以沒用參數化查詢

原來是用迴圈組字串，每一個 T-SQL 字串某些變數是從資料庫撈出，所以每個字串的該變數值不同；

Mend 修改後，

while 迴圈後才把最終資料庫中值丟給變數，造成每個字串的該變數值都相同，執行結果錯誤。

(完)

[研究]Mend (WhiteSource) 弱點掃描工具結果是否不固定？

[研究]Mend (WhiteSource) 弱點掃描工具結果是否不固定？

2026-06-05

Mend (WhiteSource) 弱點掃描工具結果是否不固定？掃描時會即時自某些平台抓取弱點資訊 ? 或定時自某些平台抓取弱點資訊 ? 所以相同原始碼專案，不同時間掃描結果可能不固定？

*****

是的，Mend（原 WhiteSource）相同原始碼專案在不同時間掃描，結果可能不完全相同，這是正常現象。

原因在於 Mend 的弱點資料庫會持續更新，而不是永遠固定不變。

例如：

時間	專案版本	結果
6/1	log4j 2.17.0	無漏洞
6/10	log4j 2.17.0	發現 1 個漏洞
6/20	log4j 2.17.0	發現 2 個漏洞
7/1	log4j 2.17.0	其中 1 個漏洞被撤銷

(完)

[研究]Mend (WhiteSource) 第三次建議修改了

[研究]Mend (WhiteSource) 第三次建議修改了

2026-06-05

已經照建議改過2次了，結果又來了第3次，每次都說有弱點 (雖然是 Low)，都建議修改。

原本

if (Uri.TryCreate(redirect, UriKind.Relative, out Uri targetUri))

第1次建議修改為

if (Uri.TryCreate(redirect, UriKind.Relative, out Uri targetUri) && targetUri.IsAbsoluteUri && targetUri.Host == Request.Url.Host)

第2次建議修改為

if (Uri.TryCreate(redirect, UriKind.Relative, out Uri targetUri) && !targetUri.IsAbsoluteUri)

=====

Remediation Description

The code is vulnerable to an Open Redirect attack (CWE-601). Added a check to ensure that the URL is a local URL before redirecting.

第3次建議修改為

if (Uri.TryCreate(redirect, UriKind.Relative, out Uri targetUri) && !targetUri.IsAbsoluteUri && targetUri.ToString().StartsWith("/"))

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

問一下 AI，

第1版，這個條件其實邏輯矛盾：

UriKind.Relative代表只允許 Relative URI。

但後面又檢查：targetUri.IsAbsoluteUri

表示必須是 Absolute URI。

兩者通常不會同時成立。

等於：幾乎永遠是 False。

推測原因，可能是：

Mend 舊版規則誤判

自動修補 AI 產生錯誤建議

套用了「驗證 Host」的通用範本，但忘記調整 UriKind

這版其實不合理。

**********

第2版，

Open Redirect 最常見攻擊：

https://evil.com

或

//evil.com

如果只允許 Relative URI：

/Home.aspx

/Login.aspx

就不能跳到外部網站。

因此：

!targetUri.IsAbsoluteUri

是合理的。

但其實有點多餘，因為 UriKind.Relative 本來就已經要求 Relative。

所以：

&& !targetUri.IsAbsoluteUri

幾乎只是再次確認。

**********

第3版，

防止：

../Admin.aspx

~/Home.aspx

這些相對路徑。

只允許：

/Default.aspx

/Account/Login.aspx

也就是：

Root Relative URL

**********

會不會又出現第 4 次修改？

有可能。

因為 Mend 並不是在理解你的商業邏輯，而是在套規則。

(完)

[研究]ASP.NET WebForm 的 Libman 會像 NuGet 判斷是否有新版 ? 相依性 ?

[研究]ASP.NET WebForm 的 Libman 會像 NuGet 判斷是否有新版 ? 相依性 ?

2026-06-05

因為有的前端js元件，NuGet沒有提供最新版，甚至不再提供更新了；而Libman有提供，故研究一下。

ASP.NET WebForm 的 Libman 會像 NuGet 判斷是否有新版 ? 相依性 ?

*****

不會，LibMan（Library Manager）和 NuGet 的設計目標不同。

LibMan 會判斷是否有新版嗎？

部分可以，但能力有限。

{
  "provider": "cdnjs",
  "library": "jquery@3.7.1",
  "destination": "wwwroot/lib/jquery/"
}

在 Visual Studio 中管理 libman.json 時，可以看到目前安裝版本與可選版本，例如：

Visual Studio 可能提示有較新版本（如 3.7.2），但：

不會像 NuGet 那樣完整分析更新影響
不會顯示相依套件更新建議
不會進行安全性弱點檢查
不會自動解決版本衝突

本質上只是從 CDN 提供者（如 cdnjs、unpkg、jsDelivr）查詢可用版本。

**********

LibMan 會處理相依性（Dependency）嗎？

基本上不會。

例如：

{
  "library": "bootstrap@5.3.8"   
}

Bootstrap 可能需要：


bootstrap.min.css
bootstrap.bundle.min.js

LibMan 只會下載你指定的檔案：


"files": [
    "dist/css/bootstrap.min.css",
    "dist/js/bootstrap.bundle.min.js"
]

但不會：

自動安裝 Popper
自動安裝 jQuery（舊版 Bootstrap）
自動解析 NPM package dependency tree
自動處理版本衝突

這些都是 NuGet 或 NPM 的工作。

**********

NuGet 與 LibMan 差異

功能	LibMan	NuGet
下載前端 JS/CSS	✔	可但不建議
下載 .NET DLL	✘	✔
相依性解析	✘	✔
版本衝突檢查	✘	✔
安全性弱點分析	✘	✔
自動升級相依套件	✘	✔
Package Graph	✘	✔
transitive dependency	✘	✔

ASP.NET WebForm 專案中常見的第三方前端元件管理方式比較：

項目	LibMan	NuGet	NPM
主要用途	下載前端 JS/CSS 檔案	管理 .NET 套件	管理前端套件
適合 WebForm	★★★★★	★★★★☆	★★☆☆☆
需安裝 Node.js	✘	✘	✔
Visual Studio 原生支援	✔	✔	部分
自動下載相依套件	✘	✔	✔
相依性衝突檢查	✘	✔	✔
版本管理能力	基本	完整	完整
可查看可升級版本	部分	✔	✔
套件鎖定版本	✔	✔	✔
支援 Transitive Dependency	✘	✔	✔
支援 Semantic Version	有限	✔	✔
安全性弱點分析	✘	✔	✔
Dependency-Track 掃描	較差	良好	良好
Mend/WhiteSource 掃描	較差	良好	良好
離線建置	✔	✔	需先下載
學習門檻	低	低	高
維護成本	低	中	高

範例

需求	LibMan	NuGet	NPM
安裝 jQuery	`jquery@3.7.1`	`Install-Package jQuery`	`npm install jquery`
安裝 Bootstrap	`bootstrap@5.3.x`	`Install-Package bootstrap`	`npm install bootstrap`
自動安裝相依套件	✘	✔	✔
更新指令	手動修改版本	Update-Package	npm update

實務建議

情境	建議
傳統 ASP.NET WebForm 維護案	LibMan 或 NuGet
公司要求 SCA（Mend、DT）完整掃描	NuGet 優先
新開發且有前端工程流程	NPM
只想放 jQuery、Bootstrap 幾個檔案	LibMan 最簡單
需要完整相依性管理與弱點追蹤	NuGet 或 NPM

若 WebForm 專案需要通過 OWASP Dependency-Track 或 Mend 稽核，我通常會建議：

類型	建議
.NET 元件	NuGet
JavaScript/CSS 元件	NPM（最佳）或 NuGet
LibMan	僅作為靜態檔案下載工具，不建議作為企業級元件管理機制

因為 LibMan 本質上只是把檔案下載到專案中，對於弱點追蹤、SBOM、相依性分析都遠不如 NuGet 或 NPM。

(完)

[研究]OWASP Dependency Track (DT) 元件弱點掃描工具結果是否不固定

[研究]OWASP Dependency Track (DT) 元件弱點掃描工具結果是否不固定

2026-06-05

OWASP Dependency Track (DT) 元件弱點掃描工具，掃描時會即時自某些平台抓取元件弱點資訊 ? 或定時自某些平台抓取元件弱點資訊 ? 所以相同原始碼專案，不同時間掃描結果可能不固定？

*****

是的，OWASP Dependency-Track（DT）對同一套原始碼、同一份 BOM（SBOM），在不同時間掃描，結果可能不同，這是正常現象。

Dependency-Track 本身不會在每次掃描時即時到各弱點平台查詢，而是透過背景工作（Background Tasks）定期同步弱點資料庫，之後再將已同步的弱點資料與您的元件進行比對。

DT 主要弱點來源

常見來源包括：

National Vulnerability Database（NVD）
GitHub Security Advisories（GHSA）
Sonatype OSS Index
VulnDB（商業資料庫）
其他生態系專屬 Advisory Database

DT 的運作方式

一般流程：


NVD / GHSA / OSS Index
         ↓
    定期同步
         ↓
Dependency-Track 內部資料庫   
         ↓
   比對您的 SBOM
         ↓
    產生弱點報告

因此：

掃描時通常不會逐一連線到 NVD 查詢
而是使用 DT 已同步到本機資料庫的弱點資訊
弱點資料會依設定定期更新（例如每小時、每天等）

為什麼相同專案結果會變化？

即使原始碼完全沒改，也可能出現：

1. 新 CVE 公布

例如：


2026/06/01
log4j 2.20.0
沒有弱點

2026/06/05
新增 CVE-2026-xxxxx   

重新分析後
出現 Critical

專案沒變，但弱點資料庫變了。

2. CPE 比對規則修正

NVD 或 DT 的 Matching 規則可能更新。

例如原本：


jackson-databind   
↓
無法對應 CPE
↓
0 個弱點

後來：


jackson-databind   
↓
成功對應 CPE
↓
新增 5 個 CVE

3. CVSS 分數變動

某 CVE 可能被重新評分：


High 7.5
↓
Critical 9.8

掃描結果的風險等級就會改變。

4. GHSA / OSS Index 新增 Advisory

有些弱點先出現在 GHSA：


Day 1
無弱點

Day 7
GHSA 發布公告   

DT 更新資料後
出現弱點

甚至 NVD 還沒收錄。

5. BOM 解析器升級

Dependency-Track 或 BOM Parser 升級後：

識別出更多元件
Package URL (PURL) 解析更準確
CPE Mapping 改善

結果也可能增加或減少弱點。

結論

對於 Dependency-Track：

情況	掃描結果是否可能改變
原始碼相同	是
套件版本相同	是
BOM 相同	是
DT 弱點資料庫更新	會改變
NVD/GHSA 新增 CVE	會改變
CPE Mapping 修正	會改變
DT 升級	可能改變

因此在實務上：

Dependency-Track 的掃描結果代表「目前已知的弱點狀態」，而不是「建立 SBOM 當時的弱點狀態」。

所以同一個專案今天掃描是 10 個弱點，一個月後重新分析可能變成 15 個，也可能因誤判修正而變成 8 個，這都屬於正常現象。

(完)

2026年6月4日星期四

[研究]sa帳號可以刪除嗎 ? (SQL Server 2019)

2026-06-04

Principals (Database Engine)
https://learn.microsoft.com/en-in/sql/relational-databases/security/authentication-access/principals-database-engine?view=sql-server-ver17
The sa login can't be dropped, but it can be disabled so that no one can use it.
sa 登入不能刪除，但可以停用，這樣就沒人能用了。

sp_droplogin
https://documentation.help/tsqlref/ts_sp_drop_2q0e.htm
A login mapped to an existing user in any database cannot be removed. The user must be removed first by using sp_dropuser. Additionally, these logins cannot be removed:
* The system administrator (sa) login.

已對應到任何資料庫中現有使用者的登入名稱無法刪除。必須先使用 sp_dropuser 刪除該使用者。此外，以下登入名稱也無法刪除：
* 系統管理員 (sa) 登入名稱。

結論：sa 可以改名、停用，但刪除不掉。

(完)

[研究]administrator帳號可以刪除嗎？ (Windows Server 2025)

[研究]administrator帳號可以刪除嗎？ (Windows Server 2025)

2026-06-04

有人說，為了安全，另外建系統管理員帳號，把預設的administrator帳號刪除吧。

能停用，不等於可以刪除；能刪除，也未必保證系統能正常；不管如何，測試看看。

(1)以 administrator 帳號登入，刪除自己。

(2)以 admin1帳號 (屬於 Administrators 群組) 登入，刪除 administrator 帳號。

結論，作業系統直接拒絕刪除 administrator 帳號。

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

本機帳戶

https://learn.microsoft.com/zh-tw/windows/security/identity-protection/access-control/local-accounts

預設的本地使用者帳號

預設的本地使用者帳號是作業系統安裝時自動建立的內建本地使用者帳號。你無法移除或刪除預設的本地使用者帳號。

系統管理員

你無法刪除或鎖定預設的管理員帳號。不過，你可以重新命名或停用它。

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

(完)

2026年6月3日星期三

[研究]ASP.NET WebForm 方案，搜尋甚麼字串可知有使用 js.cookie 套件 ?

[研究]ASP.NET WebForm 方案，搜尋甚麼字串可知有使用 js.cookie 套件 ?

2026-06-03

NuGet 只到 2.2.1 版
https://www.nuget.org/packages/js-cookie/3.0.0-rc1#versions-body-tab

GitHub到 3.0.8 版
https://github.com/js-cookie/js-cookie/releases

ASP.NET WebForm 方案，搜尋甚麼字串可知有使用 js.cookie 套件 ?

******

快速判斷是否有使用 js-cookie 套件，可以搜尋以下幾類關鍵字。

1. 搜尋 Cookies.（最有效）

js-cookie v2/v3 最常見用法：


Cookies.set(...)
Cookies.get(...)
Cookies.remove(...)
Cookies.getJSON(...)

直接搜尋：


Cookies.

或個別搜尋：


Cookies.set(
Cookies.get(
Cookies.remove(

例如：


Cookies.set('UserName', 'Tom');
var user = Cookies.get('UserName');   
Cookies.remove('UserName');

2. 搜尋 js.cookie

很多專案會直接引用檔案名稱：


<script src="/Scripts/js.cookie.min.js"></script>   
或：
<script src="/Scripts/js.cookie.js"></script>

搜尋：js.cookie

3. 搜尋 CDN 路徑

常見引用：


https://cdn.jsdelivr.net/npm/js-cookie
https://cdnjs.cloudflare.com/ajax/libs/js-cookie

搜尋：


js-cookie
或：
cdn.jsdelivr

4. 搜尋 NuGet / LibMan 安裝痕跡

packages.config

可能有：


<package id="js-cookie" version="3.0.5" />

搜尋：js-cookie

libman.json可能有


{
  "library": "js-cookie@3.0.5"   
}

搜尋：js-cookie

5. 搜尋實體檔案名稱

在 Visual Studio 的「搜尋檔案」或檔案總管搜尋：


js.cookie.js
js.cookie.min.js

常見位置：


/Scripts/js.cookie.js
/Scripts/js.cookie.min.js
/lib/js-cookie/js.cookie.min.js

6. 搜尋 BundleConfig

Web Forms/MVC 專案可能透過 Bundle 載入：


bundles.Add(
    new ScriptBundle("~/bundles/common")
        .Include(
            "~/Scripts/js.cookie.min.js"   
        ));

搜尋：js.cookie 或：cookie.min.js

7. 注意可能的誤判

有些專案沒有用 js-cookie，而是原生 Cookie：


document.cookie = "UserName=Tom";   
或：
var cookie = document.cookie;

這種情況搜尋：document.cookie即可找到。

建議在整個 Solution 搜尋

依序搜尋：


Cookies.
js-cookie
js.cookie
document.cookie

其中 Cookies. 通常是判斷專案是否使用 js-cookie 套件最快、最準確的關鍵字。因為 js-cookie 的 API 幾乎都透過全域物件 Cookies 呼叫。

(完)

2026年6月1日星期一

[研究]Mend (WhiteSource) 建議修改的，又建議改回

[研究]Mend (WhiteSource) 建議修改的，又建議改回

2026-06-01

(完)

[研究]Mend (WhiteSource) 硬把組字串查詢轉成參數化查詢，導致結果錯誤

2026-06-01

雖然組字串查詢在資安角度並不推薦，源碼掃描都會報告出來，因為掃描工具無法判斷來源是否安全；但因此段是2分鐘和3小時差異，且來源是資料庫 (若不安全，該先檢討寫入資料庫那段)；Mend 硬拆開，在 while 迴圈後 AddWithValue，結果插入的每一筆值都相同，是錯誤的。

(完)

2026年6月5日 星期五

2026年6月4日 星期四

2026年6月3日 星期三

2026年6月1日 星期一

2026年6月5日星期五

2026年6月4日星期四

2026年6月3日星期三

2026年6月1日星期一