[研究]Mend(WhiteSource)建議了不合理的foreach避免SQL Injection
2026-06-12
Mend 建議把
|
改成
|
因為同一個 SqlCommand.Parameters 集合裡面,參數名稱必須唯一,添加的名稱都是相同@id,這不合理,會導致 Exception。
(完)
[研究]Mend(WhiteSource)建議了不合理的foreach避免SQL Injection
2026-06-12
Mend 建議把
|
改成
|
因為同一個 SqlCommand.Parameters 集合裡面,參數名稱必須唯一,添加的名稱都是相同@id,這不合理,會導致 Exception。
(完)
[研究]Mend(WhiteSource)誤判NuGet 安裝 vue 的 .nupkg 有問題,砍掉會怎樣?
2026-06-12
*****
.nupkg 通常只是 NuGet 套件安裝檔(壓縮包),並不是網站執行時實際使用的檔案。
刪掉:
不會影響
因為實際使用的是:
/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安裝)版本隱藏測試
2026-06-12
下圖,預設 Wappalyzer 無法辨識 BootStrap 版本
下圖,看 HTML Source 可以辨識版本(完)
[研究]vue 3.5.22(Libman安裝)版本隱藏測試
2026-06-12
為了安全,有時候會把版本號碼隱藏,有些可能做得到,有些不行。
以 Libman 安裝的 vue 3.5.22 測試。
下圖,
下圖,
下圖,
另外,libman.json 可以在 Visual Studio 中設定不要 Deploy。
(完)[研究]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
|
[研究]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建議把
|
改成
|
結果功能異常。
********************************************************************************
做了些研究,
(1)參考這篇 (此狀況下,非必須改)
[研究]Web.Config 中路徑變數最後要加上 倒斜線嗎 ?
https://shaurong.blogspot.com/2026/06/webconfig.html
路徑結合推薦用 string file = Path.Combine(folder, "test.jpg");
(2)Path.GetFullPath 能正規化路徑,Mend 只對 fileName 做,沒對 fd 做。
程式改成下面
|
結果功能異常。
實際測試正常了ˊ。
(完)
相關
[研究]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
|
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 社群中也多次提到:
****************************************
DAM Server「拒絕連線」 + SQL Server LOG_BACKUP + ELMAH 交易記錄滿,三個現象其實可能是同一條鏈上的問題。
先講結論(重點)
Imperva DAM「拒絕連線」本身不會直接造成 SQL LOG_BACKUP。
但它「可能間接造成 SQL Server 壓力暴增」,進而引發:
Transaction Log 無法截斷 → LOG_BACKUP → ELMAH 發信
(完)
[研究]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 自動處理
|
如果是團隊開發,建議:
<add key="TempFolder" value="D:\WWW\Temp" />
路徑最後不要放 \,然後程式一律使用:
Path.Combine(...)
這樣最不容易出錯,也符合 .NET 的慣用寫法。
(完)
[研究]Mend(WhiteSource)因XSS增加HttpUtility.HtmlEncode成功比例
2026-06-10
Mend(WhiteSource)因Cross-Site Scripting (XSS) 增加所建議的HttpUtility.HtmlEncode程式碼,
掃描隔天看,一堆還是說有弱點,
Mend 亂改把 HTML Tag 包入 HttpUtility.HtmlEncode 的有 9個 (昨天發現後就改正了),Mend 亂改導致結果錯誤佔 13.63%。
而且說有弱點,給不出建議。
(完)
[研究]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" />
來決定哪些檔案屬於專案。
因此:
通常不會進入分析範圍。
*****
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結構
2026-06-10
亂改(2) 直接做了新的 foreach 內容,原來的被往下擠出 foreach
(完)
[研究]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 內容
|
(完)
[研究]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 中太多 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呢?
2026-06-09
Mend (WhiteSource) 對 ASP.NET WebForm 專案卻建議用 MVC 才有的 IsLocalUrl() 進行修改,Mend 不認得專案是 WebForm 或 MVC ? Fortify SAST (SCA) 源碼掃描可以認得 ? Checkmarx 源碼掃描可以認得 ?
*****
是的,這種情況其實很常見。
Mend(前身 WhiteSource)許多安全規則是以 Pattern Matching(模式比對) 或 Framework-Agnostic(框架無關) 的方式運作,因此有時候會出現:
這不代表程式一定有問題,而是 Mend 的 Rule Engine 偵測到「Open Redirect 風險」,然後套用了通用修復建議。
**********
Mend 是否能分辨 WebForm / MVC?
理論上可以部分辨識:
但實務上:修補建議(Remediation Guidance)通常是共用的。
**********
Fortify SAST (SCA) 呢?
Fortify 比較強。
它有:
能分析:
public partial class Login : System.Web.UI.Page
知道是 WebForm。
**********
Checkmarx 呢?
Checkmarx 介於兩者之間。
它的 C# Query Engine 能辨識:
**********
三者比較
| 項目 | 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 信件在眼前從 "收件匣" 信件列表消失
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)時:
因此在收件匣列表中會突然消失。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 說明
(完)
相關
[研究]Gmail 收信延遲疑問 (昨天沒看到,今天看到信,收信時間卻是昨天)
https://shaurong.blogspot.com/2026/06/gmail.html
[研究]Gmail 信件在眼前從 "收件匣" 信件列表消失
https://shaurong.blogspot.com/2026/06/gmail_01203837394.html
[研究]Gmail 收信延遲疑問 (昨天沒看到,今天看到信,收信時間卻是昨天)
2026-06-09
* 本來以為是自己漏看信件,但發生數次後,有些疑問。
* 自己寄給數人的信,有人沒收到,但數人Chrome畫面顯示已經收到 Email;對方說他遇過比別人晚數小時後收到的狀況。
* 問問 AI 看看是否 Internet 上有其他人也遇過。
GWS (Google Workspace) Gmail 是否可能 A 寄給 同一公司的B 和C,B 下午收到,C卻晚上收到 ? C 在 Chrome 畫面卻看到收信時間是下午,有實際案例 ? 有網址 ?
*****
是的,完全有可能發生,而且我實際看過不少案例。
您的情境:
這種情況在 Google Workspace 並不罕見。
原因是 Gmail 顯示的時間通常是郵件標頭(Header)中的 Date 或 Google 接收郵件的時間,而不是使用者實際看到郵件的時間。
因此可能出現:
| 時間 | 事件 |
|---|---|
| 14:00 | A 寄出郵件 |
| 14:00:05 | Google 收到並記錄郵件 |
| 14:00:10 | B 信箱完成投遞 |
| 20:00 | C 信箱才完成投遞(或解除隔離) |
| 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 追蹤郵件傳輸路徑。
官方網址:
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 在同一公司網域:
**********
真實案例:郵件晚到但時間顯示較早
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
**********
如何證明 C 是晚上才真正收到?
最準確的方法是查看郵件原始標頭(Show Original)。
Gmail:
開啟郵件
右上角「⋮」
顯示原始郵件 (Show Original)
觀察 Header 中多個:
Received:
Received:
Received:
若前後差了數小時,就能證明郵件在某個階段被延遲。Google 官方也建議利用 Header Analysis 或 Email Log Search 來確認延遲發生在哪一段。
實際測試,顯示原始郵件 (Show Original) => 好像只會顯示最後一次對方寄 和我收到的日期時間,這封信中多次往返時間沒有 ?
**********
對,您觀察得沒錯。
Gmail 的 「顯示原始郵件 (Show Original)」 並不一定能看到整個討論串(Conversation)裡所有往返信件的傳遞時間。
它顯示的是:
而不是整串對話的歷史。
********************************************************************************
如果您是 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 疑問
2026-06-09
下圖,Mend (WhiteSource) 建議密碼欄位 HtmlEncode
但依據下面這篇,是不建議的
[研究]Mend (WhiteSource) 喜歡用的 HttpUtility.HtmlEncode 會影響那些字元?https://shaurong.blogspot.com/2026/06/mend-whitesource-httputilityhtmlencode.html
(完)
[研究]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() |
(完)
[研究]Mend (WhiteSource) 包含 HTML Tag 字串,照建議用HttpUtility.HtmlEncode改完功能異常
2026-06-08
ASP.NET WebForm,Mend (WhiteSource)
|
Mend (whiteSource) 建議把
|
改為
|
*****
原本正常輸出
|
照 Mend 改完變成
|
功能異常
(完)
[研究]Oracle Database EOS
2026-06-08
Oracle 19C EOS 在 April 2027
**********
Tier 1 Support, Tier 2 Support, Tier 3 Support 的意義?
Oracle 文件中的 Tier 1 / Tier 2 / Tier 3 Support 並不是一般 IT Help Desk 的一線、二線、三線支援,而是對應 Oracle 的產品生命週期支援階段。從表格內容可看出:
| 文件中的 Tier | Oracle 官方名稱 | 意義 |
|---|---|---|
| Tier 1 Support | Premier Support | 完整支援期 |
| Tier 2 Support | Extended Support | 延長支援期 |
| Tier 3 Support | Sustaining Support | 維持支援期 |
Tier 1(Premier Support)
Oracle 最完整的支援階段,包含:
這是企業最希望維持的狀態。
**********
Tier 2(Extended Support)
Premier 結束後的延長支援。
仍可獲得:
但:
Oracle 19c 即屬於此類型:
因此目前(2026年)Oracle 19c 仍處於 Extended Support 階段。
**********
Tier 3(Sustaining Support)
很多人誤以為是「還有支援」,其實已接近 EOS 狀態。
仍可使用:
但通常不再提供:
也就是:Oracle 工程師會協助分析,但通常不會為你的版本開發新的修補程式。
**********
建議在 Extended Support 更換為 Long Term Release(如 23ai LTS 或後續版本)。
(完)
[研究]Web Server (IIS + ASP.NET WebForm ) 的 Windows Server 2019, 2022, 2025, 砍掉 Edge 的影響
2026-06-08
如果是純粹的 IIS + ASP.NET WebForm Web Server,一般情況下移除或停用 Edge 對網站執行本身通常沒有直接影響,但要看伺服器是否有依賴 Edge 的功能。
不受影響的部分
以下功能通常與 Edge 無關:
可能受影響的情況
1. WebView2
近年許多軟體改用 Edge Chromium 核心:
如果伺服器安裝了這些軟體,可能會依賴:
Microsoft Edge WebView2 Runtime
移除 Edge 時有機會一起影響 WebView2。
2. Server Manager 或 Windows 管理工具
Windows Server 2022/2025 某些管理介面會透過 Edge 開啟:
網站不受影響,但管理便利性可能下降。
3. Selenium 自動化測試
若伺服器有:
這類瀏覽器自動化工具可能依賴:
Microsoft Edge
移除後測試程式可能失敗。
4. 報表或 PDF 產生
有些系統利用:
產生:
這類功能可能失效。
****************************************
Windows Server 2019
比較特殊:
實務上移除 Edge 風險較低。
****************************************
Windows Server 2022
不建議強制移除。
****************************************
Windows Server 2025
風險最高。
(完)
[研究]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)差異?
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 系統可用較少程式修改方式遷移至 PostgreSQL。
2. 企業級管理工具
EDB 套件通常包含:
社群版則需自行安裝:
等開源工具。
3. 強化安全與稽核
EDB Enterprise 提供:
較符合金融、保險、政府單位需求。
4. 商業技術支援
Community:
Enterprise:
這通常是企業願意付費的主要原因。
*****
官方參考資料
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次修改建議
2026-06-05
已經照Mend (WhiteSource)建議修改7次了,又來第8次修改建議。
(完)
[研究]Mend (WhiteSource) 第7次修改建議
2026-06-05
已經照Mend (WhiteSource)建議修改6次了,又來第7次修改建議。
[研究]Mend(WhiteSource) 建議使用不認得的 IsLocalUrl
https://shaurong.blogspot.com/2026/05/mendwhitesource-islocalurl.html
(完)
[研究]Mend (WhiteSource) 建議錯誤,改錯程式了
2026-06-05
原來是用迴圈組字串,每一個 T-SQL 字串某些變數是從資料庫撈出,所以每個字串的該變數值不同;
Mend 修改後,
while 迴圈後才把最終資料庫中值丟給變數,造成每個字串的該變數值都相同,執行結果錯誤。
(完)
[研究]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) 第三次建議修改了
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("/"))
(完)
[研究]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),但:
本質上只是從 CDN 提供者(如 cdnjs、unpkg、jsDelivr)查詢可用版本。
**********
LibMan 會處理相依性(Dependency)嗎?
基本上不會。
例如:
{
"library": "bootstrap@5.3.8"
}
|
Bootstrap 可能需要:
|
LibMan 只會下載你指定的檔案:
|
但不會:
這些都是 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) 元件弱點掃描工具結果是否不固定
2026-06-05
OWASP Dependency Track (DT) 元件弱點掃描工具,掃描時會即時自某些平台抓取元件弱點資訊 ? 或定時自某些平台抓取元件弱點資訊 ? 所以相同 原始碼專案,不同時間掃描結果可能不固定?
*****
是的,OWASP Dependency-Track(DT)對同一套原始碼、同一份 BOM(SBOM),在不同時間掃描,結果可能不同,這是正常現象。
Dependency-Track 本身不會在每次掃描時即時到各弱點平台查詢,而是透過背景工作(Background Tasks)定期同步弱點資料庫,之後再將已同步的弱點資料與您的元件進行比對。
DT 主要弱點來源
常見來源包括:
DT 的運作方式
一般流程:
|
因此:
為什麼相同專案結果會變化?
即使原始碼完全沒改,也可能出現:
1. 新 CVE 公布
例如:
|
專案沒變,但弱點資料庫變了。
2. CPE 比對規則修正
NVD 或 DT 的 Matching 規則可能更新。
例如原本:
|
後來:
|
3. CVSS 分數變動
某 CVE 可能被重新評分:
|
掃描結果的風險等級就會改變。
4. GHSA / OSS Index 新增 Advisory
有些弱點先出現在 GHSA:
|
甚至 NVD 還沒收錄。
5. BOM 解析器升級
Dependency-Track 或 BOM Parser 升級後:
結果也可能增加或減少弱點。
結論
對於 Dependency-Track:
| 情況 | 掃描結果是否可能改變 |
|---|---|
| 原始碼相同 | 是 |
| 套件版本相同 | 是 |
| BOM 相同 | 是 |
| DT 弱點資料庫更新 | 會改變 |
| NVD/GHSA 新增 CVE | 會改變 |
| CPE Mapping 修正 | 會改變 |
| DT 升級 | 可能改變 |
因此在實務上:
Dependency-Track 的掃描結果代表「目前已知的弱點狀態」,而不是「建立 SBOM 當時的弱點狀態」。
所以同一個專案今天掃描是 10 個弱點,一個月後重新分析可能變成 15 個,也可能因誤判修正而變成 8 個,這都屬於正常現象。
(完)
[研究]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)
2026-06-04
有人說,為了安全,另外建系統管理員帳號,把預設的administrator帳號刪除吧。
能停用,不等於可以刪除;能刪除,也未必保證系統能正常;不管如何,測試看看。
(1)以 administrator 帳號登入,刪除自己。
結論,作業系統直接拒絕刪除 administrator 帳號。
********************************************************************************
本機帳戶
https://learn.microsoft.com/zh-tw/windows/security/identity-protection/access-control/local-accounts
預設的本地使用者帳號
預設的本地使用者帳號是作業系統安裝時自動建立的內建本地使用者帳號。 你無法移除或刪除預設的本地使用者帳號。
系統管理員
你無法刪除或鎖定預設的管理員帳號。 不過,你可以重新命名或停用它。
********************************************************************************
(完)