[研究]比較 WinDirStat , TreeSize Free , WizTree 及其他相類似 Freeware

[研究]比較 WinDirStat , TreeSize Free , WizTree 及其他相類似 Freeware

2026-07-26

ChatGPT

Windows 磁碟空間分析工具（Disk Space Analyzer） 來比較

軟體	授權	掃描速度	是否讀取 MFT	視覺化	重複檔	可攜版	支援 Win11	推薦度
WizTree	免費（個人）	⭐⭐⭐⭐⭐ 最快	✔ NTFS MFT	✔	✔	✔	✔	★★★★★
TreeSize Free	免費	⭐⭐⭐⭐	部分支援	✔	部分	✔	✔	★★★★★
WinDirStat 2.x	GPL	⭐⭐⭐	否	⭐⭐⭐⭐⭐ Treemap最佳	否	✔	✔	★★★★☆
SpaceSniffer	免費	⭐⭐⭐⭐	否	⭐⭐⭐⭐⭐	否	✔	✔	★★★★☆
RidNacs	免費	⭐⭐⭐	否	一般	否	✔	✔	★★★☆☆
JDiskReport	免費	⭐⭐	Java	一般	否	✔	✔	★★★☆☆
Xinorbis Free	免費	⭐⭐⭐	否	報表多	部分	✔	✔	★★★☆☆

(完)

[研究]台灣，評論一下 LINE, Messenger, Discord, 其他, 用戶族群 ? 安全性? 用戶百分比 ?

[研究]台灣，評論一下 LINE, Messenger, Discord, 其他, 用戶族群 ? 安全性? 用戶百分比 ?

2026-07-23

ChatGPT

如果以 台灣 2026 年來看，通訊軟體的生態其實非常明顯：LINE 幾乎是全民通訊工具，Messenger 次之，而 Discord 則集中於特定族群。

平台	台灣主要用戶族群	普及程度	安全性	適合用途
LINE	幾乎所有年齡層（學生、上班族、公家機關、公司、長輩）	★★★★★	★★★☆☆	日常聯絡、家庭、工作
Messenger	Facebook 使用者、30～60歲	★★★☆☆	★★★☆☆	FB朋友聊天
Discord	遊戲玩家、學生、工程師、社群	★★☆☆☆	★★★★☆	社群、語音、直播
WhatsApp	外商、跨國公司、外籍人士	★☆☆☆☆	★★★★★	國際聯絡
Telegram	科技族、投資圈、匿名社群	★☆☆☆☆	★★★★☆	大型群組、頻道
WeChat	台商、中國往來人士	★☆☆☆☆	★★☆☆☆	中國聯絡

1. LINE（台灣霸主）

• 主要族群
• 幾乎全民
• 家庭
• 公司
• 學校
• 政府單位
• 醫院
• 社區管委會

很多事情甚至只提供 LINE 通知。

市占率

根據 TWNIC《2025 台灣網路報告》：

• 即時通訊使用率：約 88%
• LINE 是最常使用的通訊軟體：約 80.1%（全體人口）
• 若只看有使用即時通訊的人，約 90% 以上都以 LINE 為主要工具。

LINE 在台灣約有 2,200 萬月活躍用戶，覆蓋約 94% 人口。

優點

• ✓ 長輩都會用
• ✓ 公司普遍採用
• ✓ LINE Pay
• ✓ 官方帳號
• ✓ 群組成熟

缺點

• 廣告偏多
• 功能很多，App 較肥大
• 隱私不是強項

2. Messenger

主要就是 Facebook 使用者。

常見：

• 同學
• 舊朋友
• 社團
• Marketplace 買賣

很多年輕人 Facebook 用得少，因此 Messenger 也下降。

TWNIC 調查：

最常使用 Messenger 約 5% 左右。

Meta 的廣告資料則顯示，Messenger 在台灣仍有約 1,050 萬可觸及使用者，代表不少人仍安裝使用，但未必是主要通訊工具。

3. Discord

十年前幾乎都是：

遊戲玩家

現在已經變成：

程式設計

• AI
• 開源社群
• YouTuber
• VTuber
• 學生社團
• 線上課程

最大的特色：

• ✓ 語音品質很好
• ✓ 頻道分類
• ✓ Bot
• ✓ 權限管理

不像 LINE 群組容易洗版。

台灣整體普及率仍不高，TWNIC 2024 調查中，「最常使用」Discord 的比例僅約 0.24%。

4. Telegram

族群很兩極：

正常用途：

• 科技圈
• 投資圈
• 加密貨幣
• 開源社群

另一面：

• 大型公開頻道
• 匿名社群

因匿名性較高，也較容易被濫用於詐騙或非法內容散播。

5. WhatsApp

全球第一大聊天軟體之一。

但是在台灣：

使用者不多。

通常：

• 外商公司
• 外籍人士
• 歐美朋友

會大量使用。

6. WeChat（微信）

主要：

• 台商
• 中國工作
• 中國客戶
• 中國朋友

若沒有中國需求，

一般台灣人幾乎不會每天使用。

安全性比較

平台	傳輸加密	預設端對端加密(E2EE)	隱私評價
Signal	有	是	★★★★★
WhatsApp	有	是	★★★★★
Telegram	有	否（秘密聊天才有）	★★★★☆
Discord	有（傳輸）	否	★★★★☆
LINE	有	多數一對一聊天可使用 Letter Sealing	★★★☆☆
Messenger	有	新聊天多採 E2EE	★★★☆☆
WeChat	有（傳輸）	否	★★☆☆☆

台灣大致使用版圖（綜合觀察）

若以實際生活中遇到的人估計：

平台	約略使用情況
LINE	約 90～95% 都有
Messenger	約 40～60% 有帳號，但主要使用者遠少於 LINE
Discord	約 10～20%（以年輕族群較高）
Telegram	約 5～10%
WhatsApp	約 5～10%
WeChat	約 3～5%

上表屬於整體生活中的概略普及度；而 TWNIC 的 80.1%（LINE）、5.2%（Messenger） 等數字，是「最常使用的即時通訊軟體（單選）」調查，因此兩者不能直接比較。

綜合評價

• 一般台灣民眾：LINE 幾乎不可取代，是生活、工作、政府服務的標準工具。
• 與 Facebook 好友互動：Messenger 仍有一定價值，但重要性已下降。
• 社群經營、遊戲、AI、程式設計：Discord 的體驗最佳。
• 重視隱私：Signal、WhatsApp 通常比 LINE、Messenger 更有優勢。
• 需要與中國往來：WeChat 幾乎是必要工具。

(完)

[研究]本機AI軟體LM Studio 0.4.19 for Windows 安裝架設

[研究]本機AI軟體LM Studio 0.4.19 for Windows 安裝架設

2026-07-16

https://lmstudio.ai/

LM-Studio-0.4.19-2-x64.exe，588 MB (616,793,128 位元組)

(完)

[研究]GIMP 3.2.4 + PhotoGIMP 3.0 好像怪怪

[研究]GIMP 3.2.4 + PhotoGIMP 3.0 好像怪怪

2026-07-09

GIMP 3.2.4安裝(Windows Server 2025)正常

https://www.gimp.org/

安裝PhotoGIMP 3.0好像怪怪

https://github.com/Diolinux/Photogimp

(完)

[研究]大通 PX UCP-165CB 165W氮化鎵GaN(含 240W 線)能否頂替Dell Pro Max 16 Premium c 筆電 官方165w 變壓器實際測試

[研究]大通 PX UCP-165CB 165W氮化鎵GaN(含 240W 線)能否頂替Dell Pro Max 16 Premium MA16250 筆電 官方165w 變壓器實際測試

2026-07-01

實際測試，不行，NB顯示變成電池供電。

Dell 原廠 165W = 28V × 5.893A

而不是 USB PD 3.1 標準的

28V × 5A = 140W

Dell 多出的 0.893A 屬於 Dell 自家的延伸協議。

充電器	輸出	MA16250 可望辨識
Dell 原廠 165W	28V × 5.893A	165W
PX UCP-165CB	28V × 5A	約 100W（依目前 Dell 行為）
Apple 140W	28V × 5A	約 100W
UGREEN 140W	28V × 5A	約 100W
Anker 140W	28V × 5A	約 100W

註解：敝人實際拿數顯轉接頭測試，只有供電19.7V。

(完)

[研究]Bootstrap 3.4.1弱點漫談

[研究]Bootstrap 3.4.1弱點漫談

2026-06-17

NVD 是國家漏洞數據庫（National Vulnerability Database），由NIST （美國國家標準暨技術研究院）所維護的一個項目。

曾經發生記錄過的 Bootstrap 3.4.1 弱點

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

CVE-2024-6484

Published: 2024-07-11Rejected: 2025-08-01
https://nvd.nist.gov/vuln/detail/CVE-2024-6484
Rejected
This CVE has been marked Rejected in the CVE List. These CVEs are stored in the NVD, but do not show up in search results by default.
此 CVE 已在 CVE 清單中標記為「已拒絕」。這些 CVE 儲存在 NVD 中，但預設不會顯示在搜尋結果中。

https://www.cve.org/CVERecord?id=CVE-2024-6484
This was not a security issue in Bootstrap. Bootstrap’s JavaScript is not intended to sanitize unsafe or intentionally dangerous HTML. As such, the reported behavior fell outside the scope of Bootstrap’s security model, and the associated CVE has been rescinded.
這並非 Bootstrap 的安全問題。 Bootstrap 的 JavaScript 程式碼並非要清理不安全或故意包含危險程式碼的 HTML 內容。因此，所報告的行為超出了 Bootstrap 安全模型的範圍，相關的 CVE 編號已被撤銷。

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

CVE-2024-6485

https://nvd.nist.gov/vuln/detail/CVE-2024-6485
Not Scheduled
This CVE record is not being prioritized for NVD enrichment efforts due to resource or other concerns.
由於資源或其他方面的考慮，該 CVE 記錄不會被優先納入 NVD 增強工作。

https://www.cve.org/CVERecord?id=CVE-2024-6485
A security vulnerability has been discovered in bootstrap that could enable Cross-Site Scripting (XSS) attacks. The vulnerability is associated with the data-loading-text attribute within the button plugin. This vulnerability can be exploited by injecting malicious JavaScript code into the attribute, which would then be executed when the button's loading state is triggered.
Bootstrap 中發現了一個安全漏洞，可能導致跨站腳本攻擊 (XSS)。該漏洞與按鈕插件中的 data-loading-text 屬性有關。攻擊者可以透過向該屬性注入惡意 JavaScript 程式碼來利用此漏洞，當按鈕進入載入狀態時，這些程式碼將被執行。

攻擊成立通常需要同時滿足：

• 使用受影響的 Bootstrap 版本。
• 頁面存在 data-loading-text 屬性。
• 該屬性的內容可被攻擊者控制。
• 程式呼叫按鈕 Loading 功能（例如 .button('loading')）。
• Bootstrap 將內容寫入 DOM 時未適當處理。

-----

若攻擊條件不成立，報告建議可寫

經程式碼檢查，專案未使用 Bootstrap Button Plugin 的 data-loading-text 功能，亦未呼叫 button('loading') API，因此 CVE-2024-6485 所描述之攻擊路徑不存在，評估為 Not Exploitable（不可利用）。

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

CVE-2024-6531
https://nvd.nist.gov/vuln/detail/CVE-2024-6531
NVD Published Date: 07/11/2024
NVD Last Modified: 08/01/2025
Rejected
This CVE has been marked Rejected in the CVE List. These CVEs are stored in the NVD, but do not show up in search results by default.
此 CVE 已在 CVE 清單中標記為「已拒絕」。這些 CVE 儲存在 NVD 中，但預設不會顯示在搜尋結果中。

https://www.cve.org/CVERecord?id=CVE-2024-6531
Published: 2024-07-11
Rejected: 2025-08-01
Rejected Reason: This was not a security issue in Bootstrap. Bootstrap’s JavaScript is not intended to sanitize unsafe or intentionally dangerous HTML. As such, the reported behavior fell outside the scope of Bootstrap’s security model, and the associated CVE has been rescinded.
拒絕理由：這並非 Bootstrap 的安全問題。 Bootstrap 的 JavaScript 並非設計用來清理不安全或故意包含危險內容的 HTML。因此，所報告的行為超出了 Bootstrap 安全模型的範圍，相關的 CVE 編號已被撤銷。

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

CVE-2025-1647

https://nvd.nist.gov/vuln/detail/CVE-2025-1647
Not Scheduled
This CVE record is not being prioritized for NVD enrichment efforts due to resource or other concerns.
由於資源或其他方面的考慮，該 CVE 記錄不會被優先納入 NVD 增強工作。

https://www.cve.org/CVERecord?id=CVE-2025-1647
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Bootstrap allows Cross-Site Scripting (XSS).This issue affects Bootstrap: from 3.4.1 before 4.0.0.
Bootstrap 中存在網頁產生期間輸入處理不當（XSS 或「跨站腳本」）漏洞，允許跨站腳本攻擊 (XSS)。此問題影響 Bootstrap：4.0.0 之前的 3.4.1 版本。

https://www.herodevs.com/vulnerability-directory/cve-2025-1647?nes-for-bootstrap
This Medium-severity vulnerability is found in the Popover and Tooltip components of Bootstrap in versions greater than or equal to 3.4.1 and less than 4.0.0.
此中等嚴重性漏洞存在於 Bootstrap 的 Popover 和 Tooltip 元件中，版本大於等於 3.4.1 且小於 4.0.0。

對 ASP.NET WebForm，CVE-2025-1647 要成功利用，通常至少需要：

• 使用 Bootstrap 3.4.1 的 Tooltip 或 Popover。
• 設定 html:true。
• 攻擊者能控制 Tooltip/Popover 內容或頁面 HTML。
• 輸入未經 HtmlEncode。
• 攻擊者能注入造成 DOM Clobbering 的 HTML 元素。
• 瀏覽器成功讓 sanitizeHtml() 失效。
• 最後再注入可執行 JavaScript 的內容。

-----

若查到攻擊無法成立條件，報告建議可寫

CVE-2025-1647 影響 Bootstrap Tooltip 與 Popover 元件。

經檢視本系統原始碼：

1.系統引用 Bootstrap 3.4.1。

2,全專案搜尋結果未發現 Tooltip 元件相關使用方式：

    * tooltip()

    * data-toggle="tooltip"

3.全專案搜尋結果未發現 Popover 元件相關使用方式：

    * popover()

    * data-toggle="popover"

4.未發現 html 或 data-html="true" 等設定。

5.因未使用受影響元件，CVE-2025-1647 所描述之 sanitizeHtml() DOM Clobbering 攻擊路徑無法進入。

評估結果：

本系統不存在 CVE-2025-1647 之可利用攻擊面（Attack Surface），因此判定為 Not Affected。

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

Bootstrap 3.4.0 在 NVD 有列 1 個弱點
https://nvd.nist.gov/vuln/search#/nvd/home?cpeFilterMode=cpe&cpeName=cpe:2.3:a:getbootstrap:bootstrap:3.4.0:*:*:*:*:*:*:*&resultType=records

Bootstrap 3.4.1 在 NVD 有列 0 個弱點
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=bootstrap+3.4.1

https://nvd.nist.gov/products/cpe/detail/6D2FBAA4-7EB8-42ED-9BD3-6209BECA01CF?namingFormat=2.3&orderBy=CPEURI&keyword=bootstrap+3.4.1&status=FINAL

點下方 "View Vulnerabilities" 後
https://nvd.nist.gov/vuln/search#/nvd/home?cpeFilterMode=cpe&cpeName=cpe:2.3:a:getbootstrap:bootstrap:3.4.1:*:*:*:*:*:*:*&resultType=records

截至目前為止，NVD 並未將 Bootstrap 3.4.1 關聯任何已完成分析（Enriched）的 CVE，因此經 NVD 明確分析並確認影響 Bootstrap 3.4.1 的漏洞數量為 0。

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

注意，

• 某些掃描工具可能還會報告這些，因為該工具不知道 NVD 已經取消2個，掃描工具沒有修正更新。
• 沒取消的2個是 NVD 尚未完成分析，最後也可能 REJECT。
• 元件有弱點，不等於系統有弱點；因為可能並未使用有弱點的功能或屬性，攻擊條件無法成立。或有其他防護措施，該弱點無法發生。

(完)

[研究]Mend(WhiteSource)建議了不合理的for避免SQL Injection

[研究]Mend(WhiteSource)建議了不合理的for避免SQL Injection

2026-06-16

其中 choiceIDs 是 id=1 OR id=9 OR、、、的字串。

(完˙)

[研究]Mend(WhiteSource)建議了不合理的foreach避免SQL Injection

[研究]Mend(WhiteSource)建議了不合理的foreach避免SQL Injection

2026-06-12

Mend 建議把

SqlCommand command = new SqlCommand(sqlCommandString, conn); conn.Open();

改成

SqlCommand command = new SqlCommand(sqlCommandString, conn); foreach (string id in choiceIDs.Split(',')) { command.Parameters.AddWithValue("@id", id); } conn.Open();

因為同一個 SqlCommand.Parameters 集合裡面，參數名稱必須唯一，添加的名稱都是相同@id，這不合理，會導致 Exception。

(完)

[研究]Mend(WhiteSource)誤判NuGet 安裝 vue 的 .nupkg 有問題，砍掉會怎樣？

[研究]Mend(WhiteSource)誤判NuGet 安裝 vue 的 .nupkg 有問題，砍掉會怎樣？

2026-06-12

*****

.nupkg 通常只是 NuGet 套件安裝檔（壓縮包），並不是網站執行時實際使用的檔案。

刪掉：

不會影響

• ASP.NET 網站執行
• Vue.js 載入
• IIS 運作
• 瀏覽器執行 Vue

因為實際使用的是：

/Scripts/vue.js

/Scripts/vue.min.js

不在 packages 目錄

**********

敝人實際測試砍掉 vue.2.6.11.nupkg，用 Visual Studio 開啟方案操作後，vue.2.6.11.pkg 又自動建立回去。

Git 上傳時，因 packages 目錄都沒上傳， vue.2.6.11.nupkg 自然沒上傳。

詢問AI，

一般情況下，Fortify SAST（Fortify Static Code Analyzer, SCA）不會像 Visual Studio 或 NuGet 那樣自動幫你下載缺少的 packages 目錄。

一般情況下，Mend 通常不會主動幫您執行 NuGet Restore，也不會自動編譯 ASP.NET WebForm 專案。

因為 Jenkins 有設定

nuget.exe restore .\WebApplication1\WebApplication1.sln

會在 Jenkins Server 主機重新下載 packages 目錄所有檔案。

(完)

[研究]BootStrap 5.3.8(NuGet安裝)版本隱藏測試

[研究]BootStrap 5.3.8(NuGet安裝)版本隱藏測試

2026-06-12

下圖，預設 Wappalyzer 無法辨識 BootStrap 版本

下圖，看 HTML Source 可以辨識版本

(完)

[研究]vue 3.5.22(Libman安裝)版本隱藏測試

[研究]vue 3.5.22(Libman安裝)版本隱藏測試

2026-06-12

為了安全，有時候會把版本號碼隱藏，有些可能做得到，有些不行。

以 Libman 安裝的 vue 3.5.22 測試。

下圖，

下圖，

下圖，

另外，libman.json 可以在 Visual Studio 中設定不要 Deploy。

(完)

[研究]vue 2.6.11(NuGet安裝)版本隱藏測試

[研究]vue 2.6.11(NuGet安裝)版本隱藏測試

2026-06-12

為了安全，有時候會把版本號碼隱藏，有些可能做得到，有些不行。

以 NuGet 安裝的 vue 2.6.11 測試。

NuGet 最新只提供到 2.6.11版
https://www.nuget.org/packages/vue

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> <script type="text/javascript" src="Scripts/vue.min.js"></script> </head> <body> <form id="form1" runat="server"> <div> test </div> </form> </body> </html>

下圖，　

下圖，

注意，因為 Git Commit 時候，一般不會上傳 packages 目錄，Git 下載方案時，會重新下載 vue 2.6.11。

如果是為了弱點，最好升級到 3.x，可用 libman 安裝目前最新 3.5.22 版。2.x 和 3.x 語法有些差異，要花些時間學習和修改。

根據實際測試，若修改

/Scripts/vue.js

/Scripts/vue.min.js

內容，NuGet 移除時，只會移除 /packsges 下檔案，這兩個檔案不會移除；若沒有修改過，這2個檔案會被移除。

(完)

[研究]Mend (WhiteSource)對 Path Traversal建議導致程式異常

[研究]Mend (WhiteSource)對 Path Traversal建議導致程式異常

2025-06-11

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

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

因為 Path/Directory Traversal，Mend建議把

string fileName = fd + FileUpload1.FileName; ㄍㄞ

改成

string fileName = fd + FileUpload1.FileName; string normalizedPath = Path.GetFullPath(fileName); if (!normalizedPath.StartsWith(fd)) { throw new InvalidOperationException("Invalid file path."); }

結果功能異常。

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

做了些研究，

(1)參考這篇 (此狀況下，非必須改)

[研究]Web.Config 中路徑變數最後要加上 倒斜線嗎 ?
https://shaurong.blogspot.com/2026/06/webconfig.html

路徑結合推薦用 string file = Path.Combine(folder, "test.jpg");

(2)Path.GetFullPath 能正規化路徑，Mend 只對 fileName 做，沒對 fd 做。

程式改成下面

string fileName = fd + FileUpload1.FileName; string normalizedPath = Path.GetFullPath(fileName); if (!normalizedPath.StartsWith(GetFullPath(fd))) { throw new InvalidOperationException("Invalid file path."); }

結果功能異常。

實際測試正常了ˊ。

(完)

相關

[研究]Imperva DAM Agent只能保留 8GB

[研究]Imperva DAM Agent只能保留 8GB 

2026-06-11

Imperva DAM (Database Activity Monitoring) 資料庫稽核

Imperva DAM Server 的服務無反映，維護人員說 安裝於 SQL Server 主機的Imperva DAM Agent只能保留 8GB ，甚麼意思 ? 

最近剛好發生 DAM Server「拒絕連線」，從別台用 Chrome 連過去看到。

會導致 Web Server 的 Elmah 一值發信說 "資料庫 的交易記錄已滿，因為發生 'LOG_BACKUP'。" 嗎 ?

**********

指 Agent 本機磁碟緩衝區（Disk Buffer / Quota）預設只有 8GB。預設 Agent 會保留約 8GB 的本機稽核資料緩衝空間，以防止網路中斷時稽核紀錄遺失。此值可以調整。

DAM Administrator Guide
https://studylib.net/doc/27987194/imperva-dam-administration-guide-2025-11-20-08-29-00

SQL Server │ ├─ Imperva Agent │ │ │ ├─ 即時送資料到 Gateway │ └─ 若網路異常或 Gateway 無法接收 │ ↓ │ 暫存到本機磁碟 │ Gateway / MX

Imperva 官方文件入口如下：

Imperva Documentation Portal
https://docs-cybersec.thalesgroup.com/

不過大部分 DAM / SecureSphere 文件需要客戶帳號登入才能完整查看。

「Agent 保留 8GB」內容，在 Imperva DAM Administration Guide 中有明確描述：

The agent requires 8GB of disk space for normal operation, and to ensure audit information is preserved in the event of network problems. This quota of 8 GB can be increased if needed.（Agent 需要 8GB 磁碟空間，以確保網路異常時稽核資料不會遺失，且此配額可調整。）

另外 Imperva 社群中也多次提到：

• 預設 Agent Buffer 配額為 8GB
• 可於 Agent 設定中調整
• 當 Gateway 無法接收資料時，Agent 會暫存 PCAP/Audit 資料於本機磁碟
• 超過配額可能出現 Disk Quota Warning 或監控異常

https://community.imperva.com/communities/community-home/digestviewer/viewthread?CommunityKey=39c6092a-d67a-4bc2-8134-bfbb25fc43af&GroupId=49&MessageKey=af6f1fd0-054c-499f-92a7-fb8ae5e86ac7

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

DAM Server「拒絕連線」 + SQL Server LOG_BACKUP + ELMAH 交易記錄滿，三個現象其實可能是同一條鏈上的問題。

先講結論（重點）

Imperva DAM「拒絕連線」本身不會直接造成 SQL LOG_BACKUP。

但它「可能間接造成 SQL Server 壓力暴增」，進而引發：

Transaction Log 無法截斷 → LOG_BACKUP → ELMAH 發信

(完)

[研究]Web.Config 中路徑變數最後要加上 倒斜線嗎 ?

[研究]Web.Config 中路徑變數最後要加上 倒斜線嗎 ? <add key="TempFolder" value="D:\WWW\Temp\" />

2026-06-11

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

Web.Config 中路徑變數最後要加上 倒斜線嗎 ? <add key="TempFolder" value="D:\WWW\Temp\" />

*****

最後的 \ 並非一定要加，但建議統一規範。

建議用 Path.Combine 自動處理

string folder = ConfigurationManager.AppSettings["TempFolder"]; string file = Path.Combine(folder, "test.jpg");

如果是團隊開發，建議：

<add key="TempFolder" value="D:\WWW\Temp" />

路徑最後不要放 \，然後程式一律使用：

Path.Combine(...)

這樣最不容易出錯，也符合 .NET 的慣用寫法。

(完)

[研究]Mend(WhiteSource)因XSS增加HttpUtility.HtmlEncode成功比例

[研究]Mend(WhiteSource)因XSS增加HttpUtility.HtmlEncode成功比例

2026-06-10

Mend(WhiteSource)因Cross-Site Scripting (XSS) 增加所建議的HttpUtility.HtmlEncode程式碼，

掃描隔天看，一堆還是說有弱點，

66個被報告仍有54個有弱點，成功率 18%，失敗率 82%，

Mend 亂改把 HTML Tag 包入 HttpUtility.HtmlEncode 的有 9個 (昨天發現後就改正了)，Mend 亂改導致結果錯誤佔 13.63%。

而且說有弱點，給不出建議。

(完)

[研究]Mend(WhiteSource)為何連 ASP.NET WebForm 專案排除但未刪除的檔案都在掃瞄 ? Fortify SAST (SCA) 就不會 ?

[研究]Mend(WhiteSource)為何連 ASP.NET WebForm 專案排除但未刪除的檔案都在掃瞄 ? Fortify SAST (SCA) 就不會 ?

2026-06-10

Fortify SAST（SCA）通常以 Visual Studio 專案（.csproj/.sln） 為主。

它會依照：

<Compile Include="xxx.cs" />

<Content Include="xxx.aspx" />

來決定哪些檔案屬於專案。

因此：

• 不在 .csproj 的檔案
• 不參與 Build 的檔案

通常不會進入分析範圍。

*****

Mend SAST / Mend Code

很多情況下採用的是：檔案系統掃描（Filesystem Scan）

而非：MSBuild 專案掃描（Project Scan）

因此它會直接掃描：

D:\Project\

    aaa.cs

    bbb.cs

    old\

       test.aspx

只要副檔名符合規則：

*.cs

*.vb

*.aspx

*.js

*.ts

就可能被分析。

*****

如何避免？

方法 1：直接刪除

方法 2：設定 Mend Ignore

Mend 通常支援：

.mendignore

方法 3：將備份移出 Repository

(完)

[研究]Mend(WhiteSource)因SQL Injection亂改TSQL內容、亂改foreach結構

[研究]Mend(WhiteSource)因SQL Injection亂改TSQL內容、亂改foreach結構

2026-06-10

亂改(1) whereString 字串變數直接被抽掉，程式結果就不對。

亂改(2) 直接做了新的 foreach 內容，原來的被往下擠出 foreach

(完)

[研究]Mend (WhiteSource)用Server.HtmlEncode取代HttpUtility.HtmlEncode依然有問題且沒建議

[研究]Mend (WhiteSource)用Server.HtmlEncode取代HttpUtility.HtmlEncode依然有問題且沒建議

2026-06-10

下圖，Mend 給不出建議

(完)

[研究]Mend(WhiteSource)把不該做HttpUtility.HtmlEncode的處理掉了

[研究]Mend(WhiteSource)把不該做HttpUtility.HtmlEncode的<br />處理掉了

2025-06-08

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

********************************************************************************
.cs 內容

//lblError.Text = lblError.Text + "匯入 " + affectRow.ToString() + " 筆<br />"; //lblError.Text = HttpUtility.HtmlEncode(lblError.Text + "匯入 " + affectRow.ToString() + " 筆<br />"); //Mend亂建議，上面應該改成下面 lblError.Text = HttpUtility.HtmlEncode(lblError.Text + "匯入 " + affectRow.ToString() + " 筆") + "<br />";

(完)