平屋慢生活

https://blog.darkthread.net/blog/owasp-top-10-n-cwe-top-25/

https://www.explainthis.io/zh-hant/swe/what-is-xss https://medium.com/starbugs/%E8%BA%AB%E7%82%BA-web-%E5%B7%A5%E7%A8%8B%E5%B8%AB-%E4%BD%A0%E4%B8%80%E5%AE%9A%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84%E5%B9%BE%E5%80%8B-web-%E8%B3%87%E8%A8%8A%E5%AE%89%E5%85%A8%E8%AD%B0%E9%A1%8C-29b8a4af6e13 https://blog.miniasp.com/post/2012/04/17/Build-Website-Comply-with-the-Personal-Information-Law-regulations https://docs.google.com/presentation/d/1-q_HwJ4lr_tuic2v4sa5gyhO469l4_fpv2N2NhehHjc/edit?slide=id.g104563e2 ...

名稱 是什麼？ 用來防什麼？ ValidateAntiForgeryToken ASP.NET MVC 內建的 CSRF 防護機制 防止他站用惡意表單偽造 POST 自訂資料安全 Token（如 SecureToken） 自己產生一組防竄改的驗證碼 防止表單中的敏感參數（如 ID）被修改 ISecureTokenEntity 自定義的介面，代表此 Entity 具有安全驗證需求 提供加密驗證方法來驗證資料 🧱 假設場景你有一個表單要刪除一筆資料： 12345<form method="post" action="/product/delete"> @Html.HiddenFor(m => m.ProductId) @Html.Hidden("SecureToken", Model.SecureToken) <button type="submit">刪除</button></form> 🔐 第一步：產生 ...

商品頁防禦一 靜態化 / CDN防禦二 拆分資料層級防禦三 單 IP / Session 節流（Rate Limit）防禦四 行為觀察註冊登入API Key + Client IDsummary 商品頁的 GET，本來就是「給全世界看的」，不能靠「有沒有權限」來擋，只能靠「你打得像不像正常逛商品的人」來擋 GET /products/12345 不需要登入 不需要 token 不需要 cookie 瀏覽器、爬蟲、搜尋引擎都合法 你不能直接說「你沒資格看」! GET 天然就適合「狂打」，他無副作用、可被 cache、可被大量併發、可被簡單 script / curl / bot net 發送 不可能直接擋 GET，因為擋太嚴造成真實使用者 + SEO 都死光，而擋太鬆會被刷爆 商品頁 GET 一定要「設計成被打也不痛」 商品頁應該要有這些東西 CDN cache HTML / JSON 都可快取 Cache Key 控制好（shopId / productId） 所以機器人打的是 CDN，不是你後端 假如每個商品頁都 GET 商品頁 → 查商品 → 查庫存 ...

傳來的東西都不可信傳來的東西都不可信OpenID Connect（OIDC）商家後台程式碼模擬summary有的人會說 「我是為你好」「你可以相信我」「我一直都是站在你這邊的」 然而，真正重要的是，過去的行為一直在替你背書 就像系統不相信前端傳來的 Supplier ID，人生也不該只相信別人替自己貼的標籤 「我是朋友」→ 那你在我低潮時有沒有出現？ 「我是專業的」→ 有沒有實績、作品、他人驗證？ 「我是家人」→ 那你有沒有尊重我的界線？ 身分，是被驗證出來的，不是宣稱出來的 系統真正可信的登入身份只能來自後端的驗證結果，而不是前端傳來的任何值 使用者登入後，系統已在後端掌握其真實身份，後端（如 Session、Token、Context）必須知道「現在是誰在操作」 例如，Service 層透過 UserService 取得當前登入身份，在業務邏輯層，不直接相信 Controller 或前端傳入的 Supplier ID，而是呼叫 NineYi.Sms.BL.Services.Users.UserService 來取得登入者資訊，因此我們也需要避免前端傳入不必要的身份欄位（如 Su ...

資安小常識 - 為什麼不建議在網址用 QueryString (?a=...) 傳資料？ UberEats凡走過必留下痕跡反射型 XSS（Reflected XSS）localStorage 偷東西Cookie消毒或編碼RazorTokensummary下班時間將至，lazy 在 UberEats 下完訂單後，在「備註欄」寫上 「不要香菜」「門口放就好」「到樓下打電話」 他突然想到，食物到家的時間很可能來不及接應，於是又打上 「我現在不在家，密碼是 5740，管理室說可以直接進，如果我沒接電話就直接放我房門口就好」 後來發現外送平台有紀錄、客服看得到、內部系統會存、有時截圖還會被轉來轉去… Query String 的本質不是「傳資料」，而是把「你要哪個資源、用什麼條件」這件事講清楚，讓這個請求可以被辨識、被重播、被理解，他正是為了讓「請求能被識別與重現」 當伺服器接到一個網址時，必須能知道「使用者要查什麼、做什麼、要哪一份資料」它是對伺服器的指令，不是傳輸內容的容器 在 HTTP 的哲學裡，它屬於 資源定位的一部分（part of URI） URL（包含 Query S ...

搶購後端 API 流量也透過 CloudFront 分流個人化資料限流判斷是否登入分流功能斷路（Feature Circuit Breaker）summary在一次搶購活動中，凌晨 00:00 一到，數十萬使用者同時按下「立即購買」。那一刻，不只是商品在被搶，你的伺服器資源也在被搶。CPU 飆滿、DB Connection Pool 撐爆、API Timeout、Error Rate 升高——這些都是典型的「高併發瞬間爆炸」現象。 如果把系統比喻成一條「城市水管」，平時水流穩定沒事，但一旦所有人同時打開水龍頭，就算是最大水管也會瞬間乾涸。這就是搶購系統      關鍵在於，系統能不能在高壓下「不垮」 「可控」與「分流」，我們希望把瞬間湧入的流量像導水渠一樣分散出去，讓「靜態內容走 CDN」、「個人化內容走限流」、「非關鍵功能可暫時關閉」。每個機制看似只是多加一層，但其實是為了在流量暴潮時，給系統一個喘息的空間 使用者打 API → 不是直接進 WebAPI 主機 → 而是先進 CloudFront，再由 CloudFront ...

🔹 DbContext Pool直接執行 SQLTable-Valued Function (TVF)查詢快取和參數化foreach + SaveChanges() 很慢Summary建立一個 DbContext → 用完 → Dispose 掉，一般效能影響不大。但是如果你在一個高併發服務（例如 Web API，每個 Request 都要建一個 DbContext），那麼 每次都要 new 一個 DbContext EF Core 需要做初始化動作 CPU 與 GC 負擔增加 👉 在大量 Request 下就會有「明顯效能影響」。 🔹 DbContext Pooling (快取池)EF Core 提供 DbContext Pooling 功能，可以「重複利用」DbContext 實例，而不是每次都重新 new，當你 Dispose() 一個 DbContext 時，它並不會真的銷毀，而是放回 Pool (池子)，下次需要時，直接拿出來重用 → 減少建立成本，AddDbContextPool() 確實會 重複使用同一個 DbContext 實例，但 EF Core 在把它丟 ...

AsNoTracking()關於使用 DbContext Update 效能最好笛卡兒爆炸非同步IQueryable / IEnumerable / IListSummary🔹 EF Core 為什麼需要 Tracking？在預設情況下，EF Core 查詢出來的物件會被放進 Change Tracker，它會記錄 哪些屬性被讀進來 哪些屬性值被修改 哪些 Entity 跟其他 Entity 有關聯 這樣 EF Core 才能在 SaveChanges() 的時候，自動知道要 Update/Insert/Delete 哪些資料。 🔹 Tracking 帶來的效能負擔Tracking 雖方便，但會多做很多事情 建立快照 (Snapshot)：每個 Entity 要存一份原始值，方便比對 變更偵測 (Change Detection)：每次存取或更新，EF 都要比對目前值與快照值 關聯維護 (Relationship Fixup)：要維護 Navigation Properties (例如 Order → Customer) 如果只是單純查詢 (Read-O ...