2026年6月12日 星期五

[研究]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個檔案會被移除。

(完)

2026年6月11日 星期四

[研究]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 的慣用寫法。

(完)

2026年6月10日 星期三

[研究]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 給不出建議


(完)

2026年6月9日 星期二

[研究]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 />";

(完)

[研究]Mend (WhiteSource) 不明原因突然掛了

[研究]Mend (WhiteSource) 不明原因突然掛了

2026-06-09

雲端Mend (WhiteSource) 不明原因突然掛了,不過沒幾秒又正常了。(可能不到10秒,甚至5秒)


(完)

[研究]RestSharp.106.15.0 升級 RestSharp.114.0.0 測試

[研究]RestSharp.106.15.0 升級 RestSharp.114.0.0 測試

2026-06-09

升級 RestSharp.106.15.0 -> RestSharp.114.0.0,結果 NuGet 要求

更新:

RestSharp.106.15.0 -> RestSharp.114.0.0

System.Text.Json.9.0.16 -> System.Text.Json.10.0.0

System.ValueTuple.4.5.0 -> System.ValueTuple.4.6.1

但此專案不可用到 System.ValueTuple.4.6.x,只能到 System.ValueTuple.4.5.x,

選較低版本測試

**********

更新:

RestSharp.106.15.0 -> RestSharp.112.1.0

**********

更新: (不穩,有時會說不用另外2個)

RestSharp.106.15.0 -> RestSharp.113.0.0

System.Text.Json.9.0.16 -> System.Text.Json.10.0.0

System.ValueTuple.4.5.0 -> System.ValueTuple.4.6.1

**********

更新:

RestSharp.106.15.0 -> RestSharp.113.1.0

System.Text.Json.9.0.16 -> System.Text.Json.10.0.0

System.ValueTuple.4.5.0 -> System.ValueTuple.4.6.1

**********

測試升級 RestSharp.106.15.0 -> RestSharp.112.1.0 後編譯

  • error CS0117: 'Method' 未包含 'POST' 的定義
  • error CS1061: 'string' 未包含 'HasValue' 的定義,也找不到可接受類型 'string' 第一個引數的可存取擴充方法 'HasValue' (是否遺漏 using 指示詞或組件參考?)

因為編譯 Error 中太多 CODE 不是敝人負責,放棄。

**********

目前弱點

CVE 影響版本 嚴重度 106.15.0 是否受影響
CVE-2021-27293 (ReDoS) < 106.11.8-alpha.0.13 High ❌ 不受影響
CVE-2024-45302 (CRLF Injection) < 112.0.0 Medium~High ⚠️ 受影響

https://www.appsecure.security/vulnerability-database/cve-2024-45302/

(完)

[研究]Mend (WhiteSource)能分辨 ASP.NET WebForm 和 MVC嗎?Fortify SAST (SCA) 、Checkmarx呢?

[研究]Mend (WhiteSource)能分辨 ASP.NET WebForm 和 MVC嗎?Fortify SAST (SCA) 、Checkmarx呢?

2026-06-09

Mend (WhiteSource) 對 ASP.NET WebForm 專案卻建議用 MVC 才有的 IsLocalUrl() 進行修改,Mend 不認得專案是 WebForm 或 MVC ? Fortify SAST (SCA) 源碼掃描可以認得 ? Checkmarx 源碼掃描可以認得 ?

*****

是的,這種情況其實很常見。

Mend(前身 WhiteSource)許多安全規則是以 Pattern Matching(模式比對) 或 Framework-Agnostic(框架無關) 的方式運作,因此有時候會出現:

  • ASP.NET WebForm 專案
  • 掃描結果卻建議使用 MVC 的 Url.IsLocalUrl()
  • 或建議使用 ASP.NET Core 的 API

這不代表程式一定有問題,而是 Mend 的 Rule Engine 偵測到「Open Redirect 風險」,然後套用了通用修復建議。

**********

Mend 是否能分辨 WebForm / MVC?

理論上可以部分辨識:

  • .aspx → WebForm
  • .cshtml → MVC/Razor
  • Controller 類別
  • Page 類別

但實務上:修補建議(Remediation Guidance)通常是共用的。

**********

Fortify SAST (SCA) 呢?

Fortify 比較強。

它有:

  • ASP.NET WebForms Rules
  • ASP.NET MVC Rules
  • ASP.NET Core Rules

能分析:

public partial class Login : System.Web.UI.Page

知道是 WebForm。

**********

Checkmarx 呢?

Checkmarx 介於兩者之間。

它的 C# Query Engine 能辨識:

  • WebForm
  • MVC
  • ASP.NET Core

**********

三者比較

項目 Mend Fortify SAST (SCA) Checkmarx
分辨 WebForm/MVC 部分 很好
Data Flow Analysis 較弱 很強 很強
Open Redirect 偵測
修補建議是否依框架調整 經常不準 通常準確 多半合理
ASP.NET WebForm 支援 基本 完整 完整
誤給 MVC API 建議 常見 少見 偶爾

**********

若 Mend 建議:Url.IsLocalUrl(returnUrl)

那幾乎可以判定:Mend 是套用了通用 Open Redirect 修補範本,沒有依據 WebForm 產生專屬修補建議。

(完)

[研究]Gmail 信件在眼前從 "收件匣" 信件列表消失

[研究]Gmail 信件在眼前從 "收件匣" 信件列表消失

2026-06-09

事件只遇過一次,但親眼看到。

GWS (Google Workspace) Gmail,Chrome 畫面,看到信件已經收到 "收件匣" 信件列表,突然看到某信自動從列表中消失,可能原因 ? 有實際案例 ? 有網址 ?

**********

是的,Google Workspace Gmail 在 Chrome 網頁版中,明明已經看到信件出現在收件匣(Inbox)列表,之後又突然從列表消失,這種情況確實有實際案例,而且不一定是 Gmail 異常,很多時候是標籤(Label)、篩選器(Filter)或同步程式造成的。

https://support.google.com/mail/answer/7015314?hl=en-IN
https://support.google.com/mail/answer/7015314?hl=zh-Hant

常見原因依機率排序如下:

原因現象
自動篩選器(Filter)信件先進 Inbox,數秒後被移到其他標籤
郵件封存(Archive)從 Inbox 消失,但在「所有郵件(All Mail)」還找得到
Outlook / Apple Mail / 手機 App其他裝置同步後把 Inbox 標籤移除
第三方工具CRM、Helpdesk、郵件管理工具自動整理郵件
Conversation View郵件被併入舊討論串,看起來像消失
Google Workspace Routing管理員設定郵件規則重新分類
瀏覽器畫面更新短暫顯示後重新整理消失

**********

最常見:Inbox Label 被移除

很多人以為 Gmail 有「資料夾(Folder)」,其實 Gmail 主要是「標籤(Label)」。

當信件被封存(Archive)時:

  • 郵件沒有刪除
  • 還在「所有郵件(All Mail)」
  • 只是移除 Inbox 標籤

因此在收件匣列表中會突然消失。Google 官方也把這列為最常見原因之一。

Reddit 也有實際案例:

"The mail no longer has the label 'Inbox'"(郵件已不再具有 Inbox 標籤)
https://www.reddit.com/r/GMail/comments/1rtick9/an_email_is_shown_in_all_mails_but_not_shown_in

以及:

Archive has never done anything more than remove the Inbox label.
https://www.reddit.com/r/GMail/comments/zxbxs8/change_the_behavior_of_archive_to_remove_from

**********

如何查證是哪個原因?

如果下次再發生,立即在搜尋框輸入

in:anywhere

**********

如果你是 Google Workspace 管理員,還有一個很有用的工具:

Google Workspace Email Log Search 說明

https://knowledge.workspace.google.com/admin/support/troubleshooting/find-messages-with-email-log-search?utm_source=chatgpt.com&visit_id=639165669009896966-107472141&rd=1&hl=zh-tw

(完)

相關

[研究]Gmail 收信延遲疑問 (昨天沒看到,今天看到信,收信時間卻是昨天)
https://shaurong.blogspot.com/2026/06/gmail.html

[研究]Gmail 信件在眼前從 "收件匣" 信件列表消失
https://shaurong.blogspot.com/2026/06/gmail_01203837394.html


[研究]Gmail 收信延遲疑問 (昨天沒看到,今天看到信,收信時間卻是昨天)

[研究]Gmail 收信延遲疑問 (昨天沒看到,今天看到信,收信時間卻是昨天)

2026-06-09

* 本來以為是自己漏看信件,但發生數次後,有些疑問。

* 自己寄給數人的信,有人沒收到,但數人Chrome畫面顯示已經收到 Email;對方說他遇過比別人晚數小時後收到的狀況。

* 問問 AI 看看是否 Internet 上有其他人也遇過。

GWS (Google Workspace) Gmail 是否可能 A 寄給 同一公司的B 和C,B 下午收到,C卻晚上收到 ? C 在 Chrome 畫面卻看到收信時間是下午,有實際案例 ? 有網址 ?

*****

是的,完全有可能發生,而且我實際看過不少案例。

您的情境:

  • A 寄信給同公司 B、C
  • B 下午 2:00 收到
  • C 晚上 8:00 才看到
  • 但 C 在 Gmail(Chrome 網頁版)看到的郵件時間仍是下午 2:00

這種情況在 Google Workspace 並不罕見。

原因是 Gmail 顯示的時間通常是郵件標頭(Header)中的 Date 或 Google 接收郵件的時間,而不是使用者實際看到郵件的時間。

因此可能出現:

時間事件
14:00A 寄出郵件
14:00:05Google 收到並記錄郵件
14:00:10B 信箱完成投遞
20:00C 信箱才完成投遞(或解除隔離)
C 開啟 Gmail郵件時間仍顯示 14:00

這是因為 Gmail 的郵件列表排序主要依郵件時間戳記,而不是實際投遞完成時間。

See the status of a Gmail message after it’s been delivered
September 20, 2017
https://workspaceupdates.googleblog.com/2017/09/see-status-of-gmail-message-after-its.html

**********

Google Workspace 官方文件:

An email takes over an hour to get to someone's inbox

並建議使用 Email Log Search 追蹤郵件傳輸路徑。

官方網址:

部分收件者未收到我的電子郵件https://knowledge.workspace.google.com/admin/support/troubleshooting/some-recipients-dont-get-my-email?utm_source=chatgpt.com&visit_id=639165658647882313-2483061270&rd=1&hl=zh-tw

Some recipients don't get my email (Google Workspace Admin Help)
https://knowledge.workspace.google.com/admin/support/troubleshooting/some-recipients-dont-get-my-email?utm_source=chatgpt.com&visit_id=639165658647882313-2483061270&rd=1&hl=zh-tw

**********

Google Workspace 內部可能造成 B、C 收件時間不同的原因

即使 B、C 在同一公司網域:

  • 不同 Gmail Filter
    • C 有個人過濾規則
    • 自動分類到標籤
  • Google Workspace Routing
    • Content Compliance
    • DLP 掃描
    • 郵件隔離(Quarantine)
  • Vault / Security 掃描
    • 附件掃毒
    • URL Safe Browsing
  • Google 後端延遲
    • Gmail 曾多次發生投遞延遲事件。

**********

真實案例:郵件晚到但時間顯示較早

Google Workspace 使用者回報:

some messages are arriving hours after sending

the sent date when it finally arrives shows the original time it was sent

(郵件幾小時後才到,但顯示的仍是原本寄出的時間)

Emails not sending? No bounce message?
https://www.reddit.com/r/GMail/comments/1ba6026/emails_not_sending_no_bounce_message

just an update if anyone wants to read this later... some messages are arriving hours after sending... not all have been received almost 24 hours later, but a few are arriving.

it's interesting because the sent date when it finally arrives shows the original time it was sent which is not accurate at all but there is a serious lag of at least 12 hours. not sure if they will all arrive.

更新一下,方便以後有人查看……有些信息在發送數小時後才收到……雖然將近24小時後並非所有信息都已收到,但確實有一些信息已經收到了。

有趣的是,郵件最終到達時顯示的發送日期卻是最初的發送時間,這完全不準確,至少有12個小時的嚴重延遲。不知道它們是否都能到達。

*****

另一案例:

One was delivered within 2 seconds, the other took 117 minutes.

同一系統寄出的兩封信,一封 2 秒到達,一封延遲 117 分鐘。

Emails sent using smtp.google.com take hours to reach the recipient

https://www.reddit.com/r/googleworkspace/comments/1q50dtm/emails_sent_using_smtpgooglecom_take_hours_to

**********

如何證明 C 是晚上才真正收到?

最準確的方法是查看郵件原始標頭(Show Original)。

Gmail:

開啟郵件

右上角「⋮」

顯示原始郵件 (Show Original)

觀察 Header 中多個:

Received:
Received:
Received:

若前後差了數小時,就能證明郵件在某個階段被延遲。Google 官方也建議利用 Header Analysis 或 Email Log Search 來確認延遲發生在哪一段。

https://knowledge.workspace.google.com/admin/support/troubleshooting/some-recipients-dont-get-my-email?hl=zh-tw


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

實際測試,顯示原始郵件 (Show Original) => 好像只會顯示最後一次對方寄 和我收到的日期時間,這封信中多次往返時間沒有 ?

**********

對,您觀察得沒錯。

Gmail 的 「顯示原始郵件 (Show Original)」 並不一定能看到整個討論串(Conversation)裡所有往返信件的傳遞時間。

它顯示的是:

  • 目前這一封郵件(目前這個 Message-ID)
  • 該郵件的 Header
  • 該郵件經過哪些 Mail Server
  • SPF、DKIM、DMARC 驗證結果

而不是整串對話的歷史。

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

如果您是 Google Workspace 管理員,而且想證明「C 晚上才真正收到,但 Gmail 顯示下午時間」,最有力的證據通常不是 Show Original,而是 Email Log Search 的 Delivery Event 時間紀錄。

(敝人不是,無法再測試驗證此說明是否正確)

(完)

相關

[研究]Gmail 收信延遲疑問 (昨天沒看到,今天看到信,收信時間卻是昨天)
https://shaurong.blogspot.com/2026/06/gmail.html

[研究]Gmail 信件在眼前從 "收件匣" 信件列表消失
https://shaurong.blogspot.com/2026/06/gmail_01203837394.html


[研究]Mend (WhiteSource) 建議密碼欄位 HtmlEncode 疑問

[研究]Mend (WhiteSource) 建議密碼欄位 HtmlEncode 疑問

2026-06-09

下圖,Mend (WhiteSource) 建議密碼欄位 HtmlEncode

但依據下面這篇,是不建議的

[研究]Mend (WhiteSource) 喜歡用的 HttpUtility.HtmlEncode 會影響那些字元?https://shaurong.blogspot.com/2026/06/mend-whitesource-httputilityhtmlencode.html

(完)

[研究]Mend (WhiteSource) 喜歡用的 HttpUtility.HtmlEncode 會影響那些字元?

[研究]Mend (WhiteSource) 喜歡用的 HttpUtility.HtmlEncode 會影響那些字元?

2026-06-09

[研究]Mend (WhiteSource) 包含 HTML Tag 字串,照建議用HttpUtility.HtmlEncode改完功能異常https://shaurong.blogspot.com/2026/06/mend-whitesource-html-tag.html

Mend (WhiteSource) 喜歡建議用 HttpUtility.HtmlEncode,也不管實際上該字串是否包含會被轉換掉,導致程式異常。

就算程式前一行已經明確給了包含 HTML Tag 的字串,也照樣推薦。

HttpUtility.HtmlEncode 會影響那些字元?

字元類型 是否通常被 HtmlEncode 改變
繁體中文字
簡體中文字
日文
韓文
全形中文標點
半形冒號 :
半形逗號 ,
<
>
&
"
'

情境 HtmlEncode
Label.Text 顯示使用者輸入 ✓ 建議
Literal.Text 顯示使用者輸入 ✓ 建議
Response.Write 使用者輸入 ✓ 建議
Session 值顯示到畫面 ✓ 建議
SQL 參數 ✗ 無關(用 Parameterized Query)
密碼驗證 ✗ 不建議
Hash 計算 ✗ 不建議
URL 參數 ✗ 改用 HttpUtility.UrlEncode()

(完)


2026年6月8日 星期一

[研究]Mend (WhiteSource) 包含 HTML Tag 字串,照建議用HttpUtility.HtmlEncode改完功能異常

[研究]Mend (WhiteSource) 包含 HTML Tag 字串,照建議用HttpUtility.HtmlEncode改完功能異常

2026-06-08


ASP.NET WebForm,Mend (WhiteSource) 


if (Sample.IndexOf("附表1")>=0) { Item2 += " (<a href=/Manage/Attach1.aspx target=blank>附表1</a>)"; Label_Item2.Text = Item2; }

Mend (whiteSource) 建議把


Label_Item2.Text = Item2;

改為


Label_Item2.Text = HttpUtility.HtmlEncode(Item2);

*****

原本正常輸出


附表內容 (<a href=/Manage/Reply.aspx target=blank>附表1</a>)

照 Mend 改完變成 


附表內容 (&lt;a href=/Manage/Reply.aspx target=blank&gt;附表1&lt;/a&gt;)

功能異常

(完)

[研究]Oracle Database EOS

[研究]Oracle Database EOS

2026-06-08

Oracle 19C EOS 在 April 2027

https://docs.oracle.com/cd/F52330_01/reference_guides/insbridge_hdwr_sfwr_guide/Content/Guides_Sales/Insbridge%20Hardware%20Software%20Specs/End%20of%20Support%20Schedule.htm

**********

Tier 1 Support, Tier 2 Support, Tier 3 Support 的意義?

Oracle 文件中的 Tier 1 / Tier 2 / Tier 3 Support 並不是一般 IT Help Desk 的一線、二線、三線支援,而是對應 Oracle 的產品生命週期支援階段。從表格內容可看出:

文件中的 TierOracle 官方名稱意義
Tier 1 SupportPremier Support完整支援期
Tier 2 SupportExtended Support延長支援期
Tier 3 SupportSustaining Support維持支援期

Tier 1(Premier Support)

Oracle 最完整的支援階段,包含:

  • 24x7 技術支援
  • 新 Bug 修正
  • Security Alert
  • Critical Patch Update (CPU)
  • 新版認證
  • 升級權利
  • My Oracle Support 使用權

這是企業最希望維持的狀態。

**********

Tier 2(Extended Support)

Premier 結束後的延長支援。

仍可獲得:

  • 技術支援
  • 安全更新
  • 重要修補程式
  • 部分 Bug Fix

但:

  • 通常需額外付費
  • 支援內容可能比 Premier 少

Oracle 19c 即屬於此類型:

  • Premier Support:至 2024/04/30
  • Extended Support:至 2027/04/30

因此目前(2026年)Oracle 19c 仍處於 Extended Support 階段。

**********

Tier 3(Sustaining Support)

很多人誤以為是「還有支援」,其實已接近 EOS 狀態。

仍可使用:

  • My Oracle Support
  • 舊 Patch 下載
  • 舊文件
  • SR 開單

但通常不再提供:

  • 新 Security Patch
  • 新 CPU
  • 新 Bug Fix
  • 新版相容性認證

也就是:Oracle 工程師會協助分析,但通常不會為你的版本開發新的修補程式。

**********

建議在 Extended Support 更換為 Long Term Release(如 23ai LTS 或後續版本)。

(完)

[研究]Web Server (IIS + ASP.NET WebForm ) 的 Windows Server 2019, 2022, 2025, 砍掉 Edge 的影響

[研究]Web Server (IIS + ASP.NET WebForm ) 的 Windows Server 2019, 2022, 2025, 砍掉 Edge 的影響

2026-06-08

如果是純粹的 IIS + ASP.NET WebForm Web Server,一般情況下移除或停用 Edge 對網站執行本身通常沒有直接影響,但要看伺服器是否有依賴 Edge 的功能。

不受影響的部分

以下功能通常與 Edge 無關:

  • IIS 網站服務
  • ASP.NET WebForm 執行
  • .NET Framework
  • SQL Server 連線
  • Windows Service
  • 排程工作(Task Scheduler)
  • Web API
  • 使用者從外部瀏覽器存取網站


可能受影響的情況

1. WebView2

近年許多軟體改用 Edge Chromium 核心:

  • Microsoft Office 部分功能
  • Teams
  • Power BI Gateway
  • 第三方管理工具
  • 某些監控軟體

如果伺服器安裝了這些軟體,可能會依賴:

Microsoft Edge WebView2 Runtime

移除 Edge 時有機會一起影響 WebView2。


2. Server Manager 或 Windows 管理工具

Windows Server 2022/2025 某些管理介面會透過 Edge 開啟:

  • Azure 管理頁面
  • Microsoft 文件
  • 部分 HTML 報表

網站不受影響,但管理便利性可能下降。


3. Selenium 自動化測試

若伺服器有:

  • Selenium
  • Playwright
  • Webwright

這類瀏覽器自動化工具可能依賴:

Microsoft Edge

移除後測試程式可能失敗。


4. 報表或 PDF 產生

有些系統利用:

  • Edge Headless
  • Chromium Headless

產生:

  • PDF
  • 截圖
  • 列印報表

這類功能可能失效。

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

Windows Server 2019

比較特殊:

  • Edge 並非原生核心元件
  • 很多環境仍保留 Internet Explorer

實務上移除 Edge 風險較低。

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

Windows Server 2022

  • Edge 已成為預設瀏覽器
  • 部分 Microsoft 元件開始依賴 Chromium

不建議強制移除。

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

Windows Server 2025

  • Edge 與系統整合程度更高
  • Microsoft 不建議移除
  • 未來累積更新(CU)可能重新安裝 Edge

風險最高。

(完)

[研究]Mend(WhiteSource)建議 Session 用 HttpUtility.HtmlEncode,仍說有問題,但無建議

[研究]Mend(WhiteSource)建議 Session 用 HttpUtility.HtmlEncode,仍說有問題,但無建議

2026-06-08

ASP.NET WebForm,Mend (WhiteSource) 建議

Literal1.Text = Literal1.Text + "-" + (string)Session["MyName"];

改成

Literal1.Text = Literal1.Text + "-" + HttpUtility.HtmlEncode((string)Session["MyName"]);

改完後又說

A sensitive sink function was discovered. It causes a High severity Cross-Site Scripting vulnerability.

而建議是

No remediation was suggested by the AI. This may indicate that the finding is a false positive.

原本是 High,照建議修改後,還是 High。

*****

下圖,


下圖,照建議改完後,仍說有問題,但給不出建議。


(完)


[研究]PostgreSQL企業版(Enterprise)和社群版(Community edition)差異?

[研究]PostgreSQL企業版(Enterprise)和社群版(Community edition)差異?

2026-06-08

PostgreSQL 本身沒有官方的 Enterprise Edition(企業版)與 Community Edition(社群版)之分。 PostgreSQL 專案只有一套開源版本。很多人所稱的「PostgreSQL Enterprise」,實際上通常是指第三方廠商(最常見是 EDB (EnterpriseDB))提供的商業版 PostgreSQL。

Migrating Enterprise Postgresql schema to Free Postgresql [closed]
https://stackoverflow.com/questions/29605479/migrating-enterprise-postgresql-schema-to-free-postgresql

PostgreSQL Community 與 EDB Enterprise 的主要差異

項目 PostgreSQL Community EDB Enterprise (EPAS)
授權 開源免費 商業授權
技術支援 社群支援 原廠 SLA 支援
Oracle 相容性 提供 Oracle 相容功能
PL/SQL 相容 支援大量 Oracle PL/SQL
效能調校工具 社群工具自行整合 內建企業級調校功能
監控管理工具 pgAdmin 等開源工具 Enterprise Manager 等商業工具
高可用工具 自行建置 提供整合方案
安全與稽核 基本功能 增強稽核與安全功能
法律賠償保障 (Indemnification)
原廠維護與補丁 社群發布 商業維護與回溯修補

EDB Enterprise 額外提供的重要功能

1. Oracle 相容層(最大賣點)

EDB Postgres Advanced Server (EPAS) 提供:

  • Oracle SQL 語法相容
  • Oracle PL/SQL 相容
  • Oracle Package
  • Oracle Data Dictionary 相容
  • Oracle Migration Tool

因此許多 Oracle 系統可用較少程式修改方式遷移至 PostgreSQL。


2. 企業級管理工具

EDB 套件通常包含:

  • Postgres Enterprise Manager
  • Backup & Recovery 工具
  • Replication Server
  • Failover Manager
  • Migration Toolkit

社群版則需自行安裝:

  • pgAdmin
  • pgBackRest
  • Patroni
  • repmgr
  • Barman

等開源工具。


3. 強化安全與稽核

EDB Enterprise 提供:

  • Password Profile
  • 進階 Audit Log
  • 使用者管理功能
  • 安全性強化設定

較符合金融、保險、政府單位需求。


4. 商業技術支援

Community:

  • 靠社群論壇
  • Mailing List
  • Stack Overflow

Enterprise:

  • 24x7 支援
  • SLA
  • 緊急修補
  • 原廠協助效能分析

這通常是企業願意付費的主要原因。

*****

官方參考資料

PostgreSQL 官方網站 PostgreSQL Official Site
https://www.postgresql.org/

EDB 官方產品比較 EDB Postgres AI Databases - Choosing Your Postgres
https://www.enterprisedb.com/docs/edb-postgres-ai/databases/

EDB Enterprise / Standard 功能比較 EDB Postgres Enterprise vs Standard Editions
https://www.ibm.com/products/postgres-enterprise/pricing

(完)

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

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

2026-06-05

已經照Mend (WhiteSource)建議修改7次了,又來第8次修改建議。


Mend 掉入死迴圈了,一直堅持建議一個錯誤不能用的程式。

(完)

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

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

2026-06-05

已經照Mend (WhiteSource)建議修改6次了,又來第7次修改建議。


(1)提供的程式不能用

前人寫程式,Url 其實是字串變數。

(2) Mend 建議用的 IsLocalUrl() 根本不是 ASP.NET WebForm 提供的,是 ASP.NET MVC 的。

[研究]Mend(WhiteSource) 建議使用不認得的 IsLocalUrl
https://shaurong.blogspot.com/2026/05/mendwhitesource-islocalurl.html


(完)

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

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

2026-06-05

已經照Mend (WhiteSource)建議修改5次了,又來第六次修改建議。

(完)

2026年6月5日 星期五

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

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

2026-06-05


(完)

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

[研究]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/1log4j 2.17.0無漏洞
6/10log4j 2.17.0發現 1 個漏洞
6/20log4j 2.17.0發現 2 個漏洞
7/1log4j 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版,
防止:
Login.aspx
../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)

[研究]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

預設的本地使用者帳號

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


系統管理員

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

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

(完)