kyosora 筆記

安全性掃描丟回來一張紅單那次例行安全性掃描跑完，報告裡躺著一條 CSRF（Cross-Site Request Forgery）漏洞。專案是前後端分離：後端 .NET Core Web API，前端 Vue.js 跑在另一個來源（origin），用 Cookie 帶身分驗證。這種架構最容易踩到 CSRF，因為瀏覽器只要看到對應網域，就會自動把 Cookie 附上去，不管請求是誰發起的。 補這個洞花的時間比我預期久，主要卡在兩個地方：一是 ASP.NET Core 的 Antiforgery API 有不少網路文章寫錯，照抄根本編不過；二是 SameSite 設定跟前後端分離的架構互相打架，調了好幾次才搞懂。這篇把走過的彎路記下來，程式碼都實際跑過。 CSRF 到底在攻擊什麼CSRF 利用的是「瀏覽器會自動帶 Cookie」這件事。攻擊不需要偷到你的帳密，它借用的是你「已經登入」的狀態。 典型流程是這樣： 使用者登入了網路銀行，瀏覽器存了驗證 Cookie 同個瀏覽器分頁打開了一個惡意網站 惡意網站偷偷送一個 POST 到網路銀行的轉帳端點 瀏覽器看到目標是網路銀行，就把驗證 C...

最近發現圖片處理真的有夠麻煩 (╯°□°）╯︵ ┻━┻特別是在使用 hexo-asset-image 和 hexo-image-link 這兩個套件時，竟然發現它們在最新版本都有 BUG！？來分享一下我的經驗，希望能幫大家省下一些除錯時間 (｡･ω･｡) 為什麼要用本地圖片？在開始之前，先來聊聊為什麼要選擇在本地存放圖片，而不是使用圖床： 第三方圖床說不定哪天就掛掉，本地存放穩定多了 文章和圖片放同一個資料夾，打包備份一次搞定 離線也能看，不用擔心網路連線 圖片跟文章放在同名資料夾，管理起來清楚很多 目前遇到的問題hexo-asset-image 的狀況最新版本在處理圖片路徑時會出現以下問題： 圖片路徑重複出現 預覽時正常，但發布後圖片掛掉 有時會莫名其妙多出資料夾層級 例如原始路徑： 1/2024/03/07/文章名稱/圖片.jpg 結果變成： 1/2024/03/07/文章名稱/03/07/文章名稱/圖片.jpg 或是域名是 xxx.io 的情況下，圖片路徑會從原本的 /xxx.jpg 變成 /.io/xxx.jpg。 hexo-image-link 的狀況這個套...

CSP 擋 XSS，靠的是禁止執行 inline script先把一件事講清楚，後面整篇都建立在這上面：Content Security Policy 能擋跨站腳本（XSS），核心機制就是禁止頁面執行行內（inline）的 script。 攻擊者注入 XSS 時，塞進 DOM 的往往是 <script>alert(document.cookie)</script> 這種直接寫在 HTML 裡的程式碼，或是 onclick="..." 這類行內事件處理器。瀏覽器一旦套上嚴格的 script-src，這些東西就跑不起來——這才是 CSP 的價值所在。 所以當你在 script-src 加上 'unsafe-inline'，等於告訴瀏覽器「行內 script 全部放行」。攻擊者注入的那段也一起放行了。這時候 CSP 對 XSS 的防護等於拆掉，剩下的 default-src 'self'、白名單域名都救不回來。 配置 CSP 的目標因此很單純：讓網站不靠 'unsafe-inline' 也能正常...

在 IIS 環境下使用 C# 操作 LibreOffice 進行檔案轉換Web 應用要把使用者上傳的 Excel 轉成 ODS、或把報表轉成 PDF，最省事的做法之一是裝一套 LibreOffice，從後端用 soffice.exe --headless --convert-to 去跑。本機開發測試時一切正常，一部署到 IIS 就翻車：程式沒回應、找不到輸出檔、或是直接權限不足。 最容易踩進去的坑不是資料夾權限，而是「身分模擬到底有沒有作用在那支 soffice.exe 上」。網路上很多範例會教你 LogonUser 取得權杖、ImpersonateLoggedOnUser 模擬使用者，然後 Process.Start() 啟動 soffice——這套流程在 ASP.NET 裡其實達不到目的。下面先把為什麼會這樣講清楚，再給出能真正生效的寫法。 環境與會遇到的問題需要的東西很單純： Windows Server 加 IIS LibreOffice（本文以預設安裝路徑 C:\Program Files\LibreOffice 為例） .NET Framework 的 Web 專案...

SQL Server 空間查詢操作指南前言在處理地理資訊系統(GIS)時，SQL Server 提供了一系列強大的空間查詢工具。本文將詳細介紹這些工具的使用方法，幫助您更有效地處理空間資料。 一、基本空間關係判斷1. 包含關係123456789-- A.STContains(B)：判斷 A 是否包含 B-- 最常用於判斷點位是否在某個範圍內SELECT * FROM Points WHERE @polygon.STContains(point_geometry) = 1-- A.STWithin(B)：判斷 A 是否在 B 內-- 與 STContains 相反，從點位角度判斷SELECT * FROM Points WHERE point_geometry.STWithin(@polygon) = 1 2. 相交關係12345678-- A.STIntersects(B)：判斷 A 和 B 是否相交-- 適合判斷兩個範圍是否有重疊SELECT * FROM ZonesWHERE zone1_geometry.STIntersects(zone2_geometry) = 1--...

前言身為後端工程師，你是否遇過這樣的情況： 系統突然變得超級慢 網頁一直轉圈圈 收到「已超過連線逾時的設定」錯誤訊息 如果有，很可能就是連線池爆掉了。以下分享一個真實案例，從診斷、緊急處理到根治。 問題診斷當你遇到以下錯誤訊息時，很可能是連線池出問題了： 1System.InvalidOperationException: '已超過連線逾時的設定。在取得集區連線之前超過逾時等待的時間，可能的原因為所有的共用連線已在使用中，並已達共用集區大小的最大值。' 快速診斷方法首先，用以下 SQL 查看目前的連線狀況。sys.sysprocesses 是 SQL Server 2000 相容性視圖，SQL Server 2005 起已標記 deprecated，這裡改用官方建議的 DMV： 123456789101112-- 各資料庫連線數摘要（依登入帳號、狀態分組）SELECT DB_NAME(s.database_id) AS DatabaseName, COUNT(*) AS NumberOfConnections...

今天遇到長官要求提供所需的資料訊息，因為要求的資料欄位是由多個資料表組合而成，要一個一個去查看原始資料表相當費時。本文介紹如何用 SQL 直接查出檢視表的欄位資訊。 各資料庫系統的查詢方式Microsoft SQL Server1234567891011121314SELECT c.name AS ColumnName, t.name AS DataType, c.max_length AS MaxLength, c.precision AS NumericPrecision, c.scale AS NumericScale, c.is_nullable AS IsNullable, ISNULL(dc.definition, '') AS DefaultValueFROM sys.views vINNER JOIN sys.columns c ON v.object_id = c.object_idINNER JOIN sys.types t ON c.user_type_id = t.user_type_idLE...

SQL Server 的備份檔，這個月又比上個月大了好幾 GB。打開資料庫一看，資料表筆數沒什麼變，那這些空間是哪來的？ 很多人第一反應是「資料庫膨脹了」，然後跑去 DBCC SHRINKDATABASE 想把它壓回來。先停手——SHRINK 是 SQL Server 裡最容易幫倒忙的指令之一，後面會講為什麼。先搞懂備份檔為什麼會長大。 完整備份複製的是資料庫裡「已配置的資料頁」加上一小段交易記錄，不是 mdf 檔的實體大小。一個 100 GB 的 mdf，裡面只有 40 GB 的頁真有資料，備份檔大約就是 40 GB 出頭。所以備份檔變大，意思是已配置的頁變多了——或者，根本不是資料庫的問題，是備份檔本身在累積。順這條線，由最常見往下查。 真因一：你每天往同一個檔案疊備份（最常見）頭號元兇，也最容易被忽略。BACKUP DATABASE 不指定 WITH INIT 時，預設是 NOINIT——把這次備份附加到既有檔案，不是覆蓋。 如果排程固定備份到 D:\Backup\MyDB.bak、每天跑又沒寫 INIT，這個檔案裡其實疊了一份又一份完整備份，當然每天長大。 要確認是不是這...

零信任的核心是一句話：「永不信任，始終驗證」。聽起來像口號，落到 .NET Core Web API 上，它其實是一串很具體的工程動作——每個請求都要驗 JWT、每個端點都要授權、敏感資料落地前要加密、所有存取都要留稽核紀錄。 網路上談零信任的文章很多，但大多停在「驗證 token」這一步，把怎麼簽發 token、設定值放哪、middleware 怎麼掛這些「跑起來真正需要的東西」省略掉了。照著抄常常編譯失敗，或執行期吃一個 NullReferenceException。 這篇要做的，是一個從 dotnet new 開始、能完整跑起來的零信任 Web API。每段程式碼都接得上前一段，最後給你完整的 Program.cs 和 appsettings.json。 五個原則，對應五件事零信任這套架構，我把它拆成五個原則，每一個都對應後面一段實作： 永遠驗證 — 每個請求都驗身分（JWT 簽發與驗證） 最小權限 — 只給必要的存取權（授權政策） 假設破壞 — 當作網路已經被打進來（限流、安全標頭） 全程加密 — 通訊與落地資料都加密（HTTPS、AES） 持續監控 — 記錄並分析所有...

近幾年的網頁開發生態裡，HTMX 這類強調後端渲染的框架悄悄累積了不少關注度。它某種程度上是對「前後端分離才是正道」的反動，值得拆開來看看背後的邏輯。 前後端分離帶來的代價前後端分離確實有其優勢：前端專注使用者體驗、後端專注商業邏輯、API 可以服務多種客戶端、水平擴展也比較直觀。 但實際做下來，代價也不小： 要同時維護兩個獨立的程式碼庫 狀態管理的複雜度往往遠超業務本身的複雜度 新人進入門檻明顯拉高 建置與部署流程多了好幾層 效能調校要在前後端各自處理一遍 對許多規模不大的專案來說，這些成本其實不太划算。 HTMX 的做法HTMX 的核心概念很直接：把原本要用 JavaScript 才能做的互動，直接寫成 HTML 屬性。 引入方式最快的方式是走 CDN，加一行進 <head> 就行： 1<script src="https://unpkg.com/htmx.org@2.0.3"></script> 正式環境建議改用 npm 安裝或自行托管，避免依賴第三方 CDN；若仍走 CDN，可從 htmx.org 官方文件 取...