Safety on 技術、遊戲、生活通俗易懂的解釋

OWASP ZAP in 2026: 進階 Scanning and CI/CD Integration

Tue, 09 Jun 2026 00:00:00 +0900

Beyond Basic Scanning

OWASP ZAP has evolved significantly since its early days. In 2026, it is no longer just a point-and-click proxy scanner — it is a full-featured security automation platform with a powerful API, a scriptable automation framework, and deep CI/CD integration. If you need the basics first, read our OWASP ZAP installation and setup guide. This article covers advanced workflows for teams running security tests at scale.

API Scanning with ZAP

Modern applications rely heavily on REST and GraphQL APIs. ZAP’s OpenAPI and GraphQL 支援 allows you to scan APIs without a browser.

為 Hugo 部落格設計現代內容安全策略

Fri, 05 Jun 2026 00:00:00 +0900

為什麼 CSP 對於靜態網站很重要

使用 Hugo 建立的靜態網站本質上比動態應用程式更安全，但它們仍然執行用於分析、廣告和嵌入的第三方腳本。 內容安全策略 (CSP) 透過控制可以載入的資源來保護您的訪客免受 XSS、資料注入和惡意腳本執行的侵害。

透過 Cloudflare Pages 設定 CSP

Cloudflare Pages 支援自訂 _headers 檔案來控制 HTTP 回應標頭：

# static/_headers
/*
 Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'

對於 Hugo，將 _headers 檔案放在 static/ 目錄中，以便將其複製到輸出：

static/
├── _headers
├── css/
└── js/

為 Hugo 建構現實的 CSP

使用 Google AdSense、Google Analytics 和嵌入式 YouTube 影片的部落格需要更寬鬆的政策。這是一個生產就緒的 CSP：

# static/_headers
/*
 Content-Security-Policy:
 default-src 'self';
 script-src 'self'
 'strict-dynamic'
 'sha256-...' (inline script hash)
 https://www.googletagmanager.com
 https://pagead2.googlesyndication.com
 https://www.youtube.com;
 style-src 'self'
 'sha256-...' (inline style hash)
 https://fonts.googleapis.com;
 img-src 'self'
 https://*.googleapis.com
 https://*.googlesyndication.com
 https://www.google.com
 https://*.doubleclick.net
 https://*.youtube.com
 data:;
 font-src 'self'
 https://fonts.gstatic.com;
 frame-src 'self'
 https://www.youtube.com
 https://www.google.com;
 connect-src 'self'
 https://*.google-analytics.com;
 report-uri /csp-report;

使用隨機數與哈希值

對於內嵌腳本（在 Hugo 主題中常見），您有兩個選項：

使用 SSH 金鑰代替 GPG 金鑰進行 Git 提交簽名

Mon, 25 May 2026 00:00:00 +0900

長期以來，GPG（GNU Privacy Guard）金鑰是簽署 Git 提交以證明身份並防止篡改的行業標準。然而，設定 GPG 涉及產生密鑰環、管理過期日期和調試後台代理，這給開發人員帶來了很大的麻煩。

為了消除這種複雜性，Git 2.34 版本引入了使用現有 SSH 金鑰直接簽署提交的功能，從而繞過了 GPG 金鑰的需要。

在本指南中，我們將探索如何設定 Git 以使用 SSH 金鑰來簽署提交、在本機驗證金鑰以及啟用跨開發團隊的信任關係。

1. 為什麼從 GPG 切換到 SSH 金鑰？

無金鑰冗餘：您可以重複使用已用於透過 GitHub 進行驗證的相同 SSH 金鑰（例如 id_ed25519），讓您無需產生和維護單獨的 GPG 金鑰對。
更簡單的設定：只需要幾個終端命令即可運作。
更乾淨的備份：標準 SSH 金鑰重量輕，易於遷移，並且受到現代終端 shell 的原生支援。

2. 設定 Git 使用 SSH 金鑰簽名

第 1 步：將加密格式設定為 SSH

告訴 Git 使用 SSH 而不是 GPG 進行提交簽名：

git config --global gpg.format ssh

第 2 步：關聯您的 SSH 公鑰

將 Git 指向您的 SSH 公鑰檔案（通常位於 ~/.ssh 目錄中的 id_ed25519.pub 或 id_rsa.pub）：

Testing CSP 規矩 Safely with Content-Security-Policy-Report-Only

Fri, 15 May 2026 00:00:00 +0900

Deploying a Content Security Policy is one of the strongest defenses against XSS attacks. But a single misconfigured directive can silently break inline scripts, block CDN resources, or disable analytics. If you apply CSP directly via the Content-Security-Policy header and a critical script gets blocked, your production site breaks—often without an obvious error console notification.

This is where Report-Only mode saves the day.

Report-Only vs Enforced Mode

CSP supports two headers:

網路安全中 JWT 令牌與有狀態會話的比較

Fri, 20 Mar 2026 00:00:00 +0900

介紹

身份驗證是每個 Web 應用程式的支柱。出現了兩種主要模式：無狀態 JWT（JSON Web 令牌） 身份驗證和 基於狀態會話 身份驗證。兩者都解決相同的問題——在後續請求中驗證用戶是誰——但它們在儲存、撤銷和安全屬性方面有根本的不同。本文提供了詳細的比較，以幫助您選擇適合您的應用程式的方法。

智威湯遜結構

JWT 是一個獨立的令牌，由三個以點分隔的 base64url 編碼段組成：

header.payload.signature

// Header
{
 "alg": "HS256",
 "typ": "JWT"
}
// Payload
{
 "sub": "user123",
 "iat": 1712345678,
 "exp": 1712349278,
 "role": "admin"
}
// Signature (HMAC-SHA256 of header + payload)

細分	內容
標題	演算法（`HS256`、`RS256`）與令牌類型
有效負載	宣告 — `sub`（主題）、`iat`（發佈於）、`exp`（過期）、自訂資料
簽名	驗證令牌未被竄改

由於有效負載僅採用 Base64 編碼（未加密），因此敏感資料絕不能放置在有效負載中，除非使用 JWE（JSON Web 加密）。

基於會話的身份驗證

在基於會話的身份驗證中，伺服器儲存會話資料（通常在記憶體、Redis 或資料庫中）。客戶端僅在 cookie 中保存會話 ID（隨機的不透明字串）：

sequenceDiagram
 Client->>Server: POST /login (credentials)
 Server->>Server: Create session (store user data)
 Server->>Client: Set-Cookie: session_id=random_hash
 Client->>Server: GET /protected (Cookie)
 Server->>Server: Look up session in store
 Server->>Client: 200 OK (response)

頭對頭比較

方面	智威湯遜	會議
儲存位置	客戶端持有所有資料	伺服器保存會話資料
伺服器狀態	無狀態 — 無需資料庫查找	有狀態 — 需要會話儲存查詢
可擴充性	非常好 - 沒有共用會話儲存	多實例需要集中式Redis/DB
撤銷	困難 — 有效期限至 `exp`	立即 — 從儲存中刪除會話
代幣大小	更大（數百位元組）	小（會話 ID ~32 位元組）
XSS 漏洞	JS (localStorage) 可存取的令牌	JS 無法存取 httpOnly cookie
CSRF 保護	需要人工處理	SameSite cookie + CSRF 令牌

JWT 的撤銷挑戰

JWT 最顯著的弱點是撤銷。一旦發出，JWT 將保持有效，直到其 exp 聲明為止。如果使用者登出、更改密碼或被禁止，則在沒有伺服器端狀態的情況下令牌無法失效，這違反了無狀態前提。

域安全性：設定 SPF、DKIM 和 DMARC 設定

Sun, 15 Feb 2026 00:00:00 +0900

介紹

電子郵件驗證對於防止網域欺騙、網路釣魚和垃圾郵件資料夾拒絕至關重要。三個基於 DNS 的標準 — SPF、DKIM 和 DMARC — 共同驗證聲稱來自您的網域的電子郵件是否合法。如果沒有這些記錄，攻擊者就可以代表您發送偽造的電子郵件，而合法電子郵件可能會進入收件者的垃圾郵件資料夾。本指南解釋了每個標準並展示如何在 Cloudflare 或您的 DNS 提供者上配置它們。

SPF：寄件者策略框架

SPF 發布授權為您的網域發送電子郵件的 IP 位址清單。收件者郵件伺服器根據 SPF 記錄檢查 Return-Path 網域。

SPF 記錄格式

SPF 記錄是 DNS TXT 記錄：

example.com TXT "v=spf1 include:_spf.google.com include:spf.mailgun.org ~all"

機制	意義
佔位符_0	SPF 版本標識符
佔位符_0	將授權委託給另一個域
`ip4:`/`ip6:`	授權特定 IP 範圍
佔位符_0	授權網域的A記錄
佔位符_0	授權網域的 MX 伺服器
佔位符_0	不符合寄件者的預設操作

預選賽

預選賽	行動
佔位符_0	通過（預設）
佔位符_0	SoftFail（已標記但已接受）
佔位符_0	失敗（應該被拒絕）
佔位符_0	中立（無斷言）

在初始設定期間使用 ~all，然後在驗證後遷移到 -all。

使用HSTS策略安全地實施HTTPS連接

Fri, 16 Jan 2026 00:00:00 +0900

第一個請求問題

HTTPS 在建立連線後對流量進行加密，但對 HTTP URL 的初始請求仍以明文形式傳送。同網路上的攻擊者可以攔截第一個請求，執行 SSL 分割攻擊，將使用者在整個會話中降級為 HTTP。

HTTP 嚴格傳輸安全性 (HSTS) 會關閉此視窗。一旦瀏覽器收到 HSTS 標頭，它就會自動將所有未來的 HTTP 請求升級為 HTTPS，並在憑證無效時拒絕連線。

HSTS 的工作原理

伺服器在 HTTPS 回應中傳送 Strict-Transport-Security 標頭：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

指令	描述
佔位符_0	瀏覽器應記得只使用 HTTPS 多久
佔位符_0	將政策套用至所有子域
佔位符_0	瀏覽器預裝清單包含訊號

處理後，瀏覽器： 1.將網域的所有http://連結改寫為https:// 2.如果TLS握手失敗或無效，則拒絕連接 3. 在 max-age 的持續時段緩存策略

在伺服器上設定 HSTS

NGINX

server {
 listen 443 ssl;
 ssl_certificate /etc/ssl/certs/example.pem;
 ssl_certificate_key /etc/ssl/private/example.key;

 add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

即使在錯誤頁面上染色體傳送標頭，「始終」參數也能確保。

###阿帕契

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

###雲耀

Cloudflare 穿透儀表板實現 HSTS：SSL/TLS > 邊緣權限 > HTTP 嚴格傳輸安全性。您可以一鍵切換預先載入和 includeSubDomains。 Cloudflare 也提供 「No Sniff」 模式，可防止邊緣的降級攻擊。

CORS的工作原理以及修復訪問阻止錯誤

Mon, 15 Dec 2025 00:00:00 +0900

介紹

CORS（來源資源共享）是一種瀏覽器安全，用於控制來自一個來源的網頁機制如何請求來自不同來源的資源。當https://app.example.com處的前端嘗試從https://api.example.org取得資料時，瀏覽器預設強制執行同源策略。 CORS提供了一種突破HTTP標頭來放寬此策略的受控方法。本文介紹了完整的CORS流程、預檢請求以及如何修復常見的跨存取阻止錯誤。

同源政策

起源由方案、主機和連接埠的組合定義：

網址	產地
佔位符_0	佔位符_1
佔位符_0	同源
佔位符_0	不同產地（不同方案）
佔位符_0	不同來源（不同主機）
佔位符_0	不同產地（不同口岸）

預設情況下，同源策略將阻止讀取跨來源回應。這可以防止惡意網站竊取其他來源的資料。

簡單請求與預檢請求

CORS區分簡單請求和觸發預檢的請求。

如果滿足所有這些條件，請求就是簡單：

方法：GET、HEAD 或 POST
內容類型：application/x-www-form-urlencoded、multipart/form-data 或 text/plain
沒有自訂標頭

對於簡單請求，瀏覽器直接發送請求並檢查回應中的 CORS 標頭。

所有其他請求都會觸發觸發預檢 — 實際上在發送的OPTIONS請求之前：

OPTIONS /api/data HTTP/1.1
Host: api.example.org
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

伺服器器必須使用適當的 CORS 標頭進行回應，瀏覽器才能繼續。

核心 CORS 回應標頭

伺服器利用這些回應的標頭控制 CORS 行為：

標題	目的
佔位允許符_0	指定哪些來源
佔位允許符_0	上線的 HTTP 方法
佔位允許符_0	上市的自訂請求標頭
佔位允許符_0	是否權限（cookie）
佔位符_0	預檢結果可以緩存多久
佔位符_0	回應的標頭是可存取的

預檢的 CORS 回應範例：

審核 NPM 依賴關係：Snyk 和自動化修補程式管理

Sat, 15 Nov 2025 00:00:00 +0900

供應鏈問題

現代 JavaScript 應用程式提供了數以萬計的傳遞依賴項。每一個都是潛在的攻擊媒介。 event-stream 事件（2018 年）將惡意程式包注入到流行的依賴項中，這表示漏洞可能來自樹中的任何位置。在這種規模下，僅依靠人工審核是不可能的。

自動化工具是唯一實用的防禦措施。

新專案管理審計

內建 npm audit 指令將您的依賴關係樹與已知漏洞的精選資料庫進行比較。

npm audit

輸出按嚴重性（嚴重、高、中、低）分組，包括易受攻擊的路徑、修補版本和 CVE 參考。

┌───────────────┬────────────────────────────────────┐
│ critical │ Prototype Pollution in lodash │
├───────────────┼────────────────────────────────────┤
│ package │ lodash │
│ patched in │ >=4.17.21 │
│ dependency │ root → express → ... → lodash │
└───────────────┴────────────────────────────────────┘

npm audit fix # auto-update to safe versions
npm audit fix --force # allow breaking changes

在應用之前使用 --dry-run 預覽變更。

限制

npm audit 僅涵蓋 npm 註冊表諮詢資料庫。它不會掃描所有 CVE 條目，只會掃描 npm 報告和接受的條目。
對於那些從未在您的上下文中執行易受攻擊的程式碼路徑的框架，誤報很常見。
該命令需要透過網路存取註冊表。離線審計需要本地諮詢鏡像。

Snyk：更深層的選擇

Snyk 不僅掃描 npm，還掃描 package-lock.json、yarn.lock、pnpm-lock.yaml、Docker 映像和 IaC 範本。它提供了更豐富的 CLI 和 GitHub/GitLab 整合。

使用 GPG 或 SSH 和驗證徽章簽署 Git 提交

Thu, 25 Sep 2025 00:00:00 +0900

在 GitHub 上查看提交日誌時，您可能會注意到某些提交旁邊有一個綠色的「已驗證」徽章。此標籤表示提交已加密簽名並確認來自合法的、經過驗證的使用者。

預設情況下，Git 允許開發人員使用 git config user.email 等簡單命令來配置他們選擇的任何名稱和電子郵件地址。這意味著冒充是微不足道的。為了確保身份驗證並防止未經授權的貢獻，強烈建議提交簽名。

在本指南中，我們將探索如何使用 GPG 或 SSH 金鑰設定 Git 提交簽名，以在 GitHub 上獲得您自己的「已驗證」徽章。

1.什麼是提交簽名？

當您執行 git commit 命令時，提交簽章使用公鑰加密技術將數位簽章附加到提交資料。

這保證了兩個關鍵的安全概念：

不可否認性：驗證提交確實是由金鑰所有者創作的。
資料完整性：確保自套用簽署以來提交元資料和檔案變更未被修改或篡改。

雖然 GPG (GNU Privacy Guard) 金鑰歷來是唯一的選擇，但 Git 現在原生支援使用 SSH 金鑰 進行提交簽名，這使得已經使用 SSH 金鑰推送程式碼的開發人員的設定變得更加簡單。在本指南中，我們將重點放在 SSH 金鑰簽署。

2. 設定 SSH 金鑰提交簽名

第 1 步：找到或產生 SSH 金鑰

決定 SSH 公鑰的路徑（通常為 ~/.ssh/id_ed25519.pub）。如果您沒有，請使用以下命令產生它：

ssh-keygen -t ed25519 -C "your_email@example.com"

步驟 2：設定 Git 使用 SSH 進行簽名

執行以下命令告訴 Git 使用您的 SSH 金鑰對提交進行簽名：

# Instruct Git to use SSH as the cryptographic format
git config --global gpg.format ssh

# Point Git to your SSH public key file
git config --global user.signingkey ~/.ssh/id_ed25519.pub

步驟 3：啟用全域自動簽名

為了避免在每次提交時手動輸入 -S ，請將 Git 配置為自動簽署所有提交：

緩解 CSRF：SameSite Cookie 屬性和 CSRF 令牌

Mon, 25 Aug 2025 00:00:00 +0900

介紹

Cookie 是管理使用者驗證狀態的便利機制。當會話 ID 儲存在 cookie 中時，瀏覽器會自動將其附加到針對該網域的傳出 HTTP 請求。

但是，此自動附件功能會被 跨站點請求偽造 (CSRF) 攻擊所利用。

儘管現代瀏覽器預設採用更安全的 cookie 行為（例如自動套用 SameSite=Lax），但開發人員必須了解 CSRF 防禦模式以防止嚴重的驗證漏洞。本文回顧 SameSite cookie 屬性和 CSRF 令牌驗證模式。

1. CSRF 攻擊如何運作

當惡意網站提示受害者的瀏覽器在使用者目前經過驗證的受信任應用程式上執行不需要的操作時，就會發生 CSRF 攻擊。

使用者登入銀行應用程式 (bank.com)，伺服器將會話識別碼儲存在本機 cookie 中。
經過身份驗證後，使用者造訪惡意網站 (evil.com)。
惡意網站執行一個腳本，將轉帳請求 (POST /transfer) 傳送到銀行應用程式 (bank.com)。
由於請求的目標是 bank.com，瀏覽器會自動包含經過驗證的會話 cookie。
銀行伺服器將請求作為合法的、經過身份驗證的會話處理，並執行交易。

防止 CSRF 最有效的方法是將 SameSite 屬性套用至會話 cookie。此設定告訴瀏覽器是否應將 cookie 包含在源自第三方（跨網站）網域的請求中。

三種配置選項

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Lax

設定	行為
SameSite=嚴格	阻止瀏覽器在跨網站請求中傳送 cookie。即使用戶從外部搜尋引擎點擊直接連結到您的網站，他們也需要再次登錄，因為 cookie 已保留。
SameSite=寬鬆	在跨網站請求上保留 cookie，但在使用者透過點擊連結（GET 請求）導航到您的網站時允許 cookie。這是 Web 應用程式的行業預設設定。
SameSite=無	將 cookie 附加到所有跨站點請求，包括嵌入式 iframe 呼叫。設定 `SameSite=None` 需要 `Secure` 標誌（限制傳輸到 HTTPS 連線）。

SameSite=Lax 的重要限制

雖然大多數現代瀏覽器預設使用 SameSite=Lax，但僅依賴它會留下潛在的安全漏洞：

Why and 如何 Adopt 'strict-dynamic' in CSP

Sun, 15 Jun 2025 00:00:00 +0900

Introduction

Implementing a Content Security Policy (CSP) is a highly effective way to mitigate Cross-Site Scripting (XSS) risks. However, configuring and maintaining the policy can become a major headache.

For websites utilizing third-party SDKs (such as Google Tag Manager, analytics beacons, 支付 widgets, or social sharing buttons), these scripts often dynamically load (inject) additional scripts from nested domains. This forces developers to maintain a long, fragile whitelist of external domains in the script-src directive.

Web開發中XSS的防禦原則

Tue, 25 Feb 2025 00:00:00 +0900

介紹

在網路安全中，跨站腳本 (XSS) 是最古老、最持久的漏洞之一。

如果惡意腳本在受害者的瀏覽器上執行，它們可能會破壞整個會話、竊取會話令牌 (cookie)、劫持帳戶或動態變更頁面內容以取得敏感憑證。

本文回顧了消除現代 Web 應用程式中 XSS 漏洞所需的基本防禦原則。我們將探索上下文轉義、清理、安全 DOM 操作和防禦深度機制。

1.XSS的三種分類

根據惡意負載的傳輸方式，XSS 漏洞大致分為三類：

反射的XSS： 當惡意負載嵌入到連結或表單提交時會發生。當使用者點擊連結時，伺服器會將不受信任的輸入「反射」迴響應 HTML，而無需進行適當的轉義。
儲存（持久）XSS： 最危險的形式。有效負載儲存在伺服器的資料庫中（例如，論壇貼文、使用者簡介）並傳遞給任何存取該頁面的後續使用者。
基於 DOM 的 XSS： 與反射或儲存 XSS 不同，這完全發生在客戶端 JavaScript 中。此腳本處理不受信任的來源資料（例如 location.hash 或查詢參數）並使用不安全的 API 將其直接寫入 DOM。

2. 原則 1：上下文感知 HTML 轉義

XSS 的根本解決方法是在渲染不受信任的動態資料之前對其進行轉義。轉義將 HTML 語法中具有特殊意義的字元文字轉換為各自的惰性 HTML 實體（字元引用）。

基本字元映射表

& -> &
< -> <
> -> >
" -> "
' -> ' （或 '）

警告：上下文很重要

轉義規則會根據資料放置的「位置」而變化。

放置在元素標記內的文字需要標準實體轉義。
放置在元素屬性內的文字（例如 <input value="DYNAMIC_DATA">）需要嚴格的引號轉義。
單獨使用 HTML 轉義無法保護 <script> 區塊、CSS 版面配置或 URL 屬性 (href) 內呈現的資料。它們分別需要 JavaScript 轉義、CSS 轉義或 URL 編碼。

3. 原則 2：安全 DOM API（防止基於 DOM 的 XSS）

使用 JavaScript 動態更新頁面內容時，選擇錯誤的 API 可能會造成安全漏洞。

子資源完整性：保護您的 CDN 依賴項

Fri, 20 Dec 2024 00:00:00 +0900

子資源完整性 (SRI) 是一項安全功能，可讓瀏覽器驗證從 CDN 或第三方來源取得的資源是否未被竄改。在供應鏈攻擊的時代——英國航空 Magecart 漏洞、Polyfill.io 洩漏以及眾多 CDN 事件——SRI 提供加密保證，確保您的頁面加載的資源正是您想要的。

社會責任投資如何運作

當您將 integrity 屬性新增至 <script> 或 <link rel="stylesheet"> 標記時，瀏覽器會計算所取得資源的雜湊值並與屬性值進行比較。如果它們不匹配，瀏覽器將拒絕執行或套用該資源。

<script
 src="https://cdn.example.com/library.js"
 integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
 crossorigin="anonymous"
></script>

當資源的多個版本可接受時，多個雜湊（逗號分隔）允許優雅的回退：

<script
 src="https://cdn.example.com/app.js"
 integrity="sha384-ABC... sha512-XYZ..."
 crossorigin="anonymous"
></script>

跨來源資源上的 SRI 需要 crossorigin="anonymous" 屬性。如果沒有正確的 CORS 標頭，瀏覽器會以不透明模式載入資源，並且無法驗證其完整性 - 此資源會被靜默忽略，不會出現任何錯誤。

產生 SRI 哈希值

您可以使用 OpenSSL、線上工具或建置時外掛程式產生 SRI 雜湊值：

# OpenSSL command
openssl dgst -sha384 -binary file.js | openssl base64 -A

為了實現自動化，請將 SRI 生成整合到您的建置管道中。建置工具支援已成熟：

工具	插件/配置
網頁包	佔位符_0
維特	`vite-plugin-sri` 或透過 `experimental.renderBuiltUrl` 內建
Next.js	`next.config.js` 中的 `experimental.sri`
天文	資產組件上內建 `integrity` 屬性

// Next.js SRI configuration
// next.config.js
module.exports = {
 experimental: {
 sri: {
 hash: "sha384",
 },
 },
};

確保在縮小和生成來源映射後計算哈希值 - 哈希值必須與最終提供的內容匹配，而不是與開發來源匹配。

Secure Cookie Configuration: A Complete Web Developer 指南

Mon, 09 Dec 2024 00:00:00 +0900

Cookies remain one of the most frequently misconfigured security controls on the web. A single missing attribute can expose your application to session hijacking, CSRF, or cross-site information leakage. Modern browsers have pushed stricter defaults, but understanding each attribute and combining them correctly is essential for defense-in-depth.

The core security attributes are Secure, HttpOnly, SameSite, and the __Host- / __Secure- prefixes. Each serves a distinct purpose, and they work best when combined.

SQL Injection 預防: Modern Database Security 指南

Tue, 01 Oct 2024 00:00:00 +0900

SQL injection remains in the OWASP Top 10 despite decades of awareness. The 2023-2024 period saw high-profile breaches in healthcare, e-commerce, and government sectors involving SQLi. While the classic ' OR 1=1 -- attack is well-known, modern variants include second-order injection, blind SQLi (time-based and boolean-based), and out-of-band exfiltration. Prevention is well-understood but poorly executed due to legacy code, ORM misuse, and insufficient testing automation.

Parameterized Queries and Prepared Statements

Prepared statements are the gold standard for SQL injection prevention. They separate SQL logic from data at the database engine level, making it impossible for user input to alter query structure.

貨櫃安全掃描：保護您的供應鏈

Tue, 16 Jul 2024 00:00:00 +0900

容器安全不再是可選的。隨著供應鏈攻擊的增加，保護容器映像從建置到運行的整個過程是任何運行容器化工作負載的組織的基本要求。僅運行時安全是不夠的；供應鏈安全必須從形象建構階段開始。

貨櫃供應鏈威脅格局

容器供應鏈中的攻擊媒介包括受損的基礎映像、易受攻擊的依賴項、洩漏的機密和惡意軟體包。 Codecov 洩漏憑證外洩、依賴性混淆攻擊以及公共影像中發現的加密貨幣挖礦程式等現實世界事件凸顯了這些威脅的嚴重性。共享責任模型意味著，雖然 Docker 等平台提供了基礎基礎設施，但建置映像的安全性是您的責任。

鏡像漏洞掃描工具

有多種工具可用於掃描容器映像。 Aqua Security 的 Trivy 是開源的、快速且全面的，可以跨越 npm、pip、gem 和 Go 掃描作業系統套件和特定於語言的依賴項。 Snyk 提供一款商業掃描儀，具有開發人員友好的 CLI、PR 檢查和自動修復建議。 Anchore 的 Grype 與 Syft 整合以產生 SBOM，而 Docker Scout 則直接內建於 Docker Desktop 和 Docker Hub 中。

工具	類型	關鍵實力
瑣碎	開源	覆蓋速度與廣度
斯尼克	商業	修復建議和 PR 整合
格里普	開源	SBOM 與 Syft 整合
Docker 偵察兵	內建	無縫 Docker 桌面整合

Dockerfile 安全最佳實踐

最小基礎鏡像是安全容器的基礎。與完整作業系統映像相比，偏好 Alpine、distroless 或 scrap。多階段建置將建置依賴項與執行時間工件分開，讓您產生僅包含執行應用程式所需內容的最終映像。

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM alpine:3.20
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --from=builder /app/app /app/app
USER appuser
ENTRYPOINT ["/app/app"]

避免使用最新的標籤；固定到特定的摘要以進行可重現的建置。以非 root 使用者身分執行容器，刪除不必要的 Linux 功能，並將根檔案系統掛載為唯讀，並使用可寫入目錄的 tmpfs。

使用 Vaultwarden 和 Bitwarden SSH 代理程式管理 SSH 金鑰

Thu, 20 Jun 2024 00:00:00 +0000

為什麼將 SSH 金鑰儲存在密碼管理器中

SSH 金鑰是對遠端伺服器、Git 供應商和內部基礎架構進行身份驗證的黃金標準。然而，大多數開發人員將它們儲存為普通檔案在 ~/.ssh/ 下 - 不受保護、未同步且未經審核。將 SSH 金鑰移至 Vaultwarden（或 Bitwarden）解決了三個基本問題：

集中管理：所有金鑰都位於一個保管庫中，而不是分散在各個電腦上。
跨裝置同步：新增一次金鑰；它會自動出現在每個裝置上。
審計追蹤：伺服器會記錄每個按鍵存取和用戶端操作。

Bitwarden SSH 代理程式彌合了鎖定的保管庫和透明地使用 SSH 金鑰的日常需求之間的差距。

Bitwarden SSH 代理程式概述

Bitwarden SSH 代理程式是一個輕量級守護程序，它透過標準 SSH_AUTH_SOCK 介面公開儲存在保管庫中的 SSH 金鑰。當 ssh 或 git 需要金鑰時，它會與代理程式通信，代理請求 Bitwarden CLI (bw) 從保管庫中取得對應的私鑰。金鑰材料永遠不會接觸磁碟 - 它位於加密的保管庫中，僅在需要時在記憶體中解密。

此方法適用於任何 OpenSSH 相容客戶端：ssh、scp、rsync、git、mosh 以及使用 SSH 代理協定的 GUI 工具。

先決條件

要求	筆記
Vaultwarden 伺服器（自架）或 Bitwarden 雲端	CLI 登入需要 API 端點
Bitwarden CLI (`bw`)	官方命令列客戶端
OpenSSH 用戶端	隨 Linux、macOS 和 Windows 10+ 一起提供
`SSH_AUTH_SOCK` 支援	各大平台皆可

安裝 Bitwarden CLI

Linux / macOS

# Download the CLI
curl -Lo bw.zip "https://vault.bitwarden.com/download/?app=cli&platform=linux"
unzip bw.zip
sudo install bw /usr/local/bin/
rm bw.zip bw

Windows（PowerShell）

# Using winget
winget install Bitwarden.CLI

# Or download manually
Invoke-WebRequest -Uri "https://vault.bitwarden.com/download/?app=cli&platform=windows" -OutFile bw.zip
Expand-Archive -Path bw.zip -DestinationPath C:\tools\bw
$env:Path += ";C:\tools\bw"

驗證安裝：

API 速率限制策略：保護您的服務

Tue, 07 May 2024 00:00:00 +0900

速率限制是任何生產 API 的關鍵組成部分。它可以保護後端服務免遭濫用，確保公平的資源分配，保持負載下的效能，並減輕拒絕服務攻擊。本文研究了主要的速率限制演算法、它們的權衡以及設計穩健系統的最佳實踐。

令牌桶演算法

令牌桶是應用最廣泛的限速演算法之一。一個桶保存著以穩定速率重新填充的令牌，每個請求消耗一個令牌。如果桶子是空的，則請求被拒絕。這種方法允許突發達到桶容量，同時隨著時間的推移平滑流量。

class TokenBucket {
 constructor(capacity, refillRate) {
 this.capacity = capacity;
 this.tokens = capacity;
 this.refillRate = refillRate;
 this.lastRefill = Date.now();
 }
 tryConsume() {
 this._refill();
 if (this.tokens > 0) { this.tokens--; return true; }
 return false;
 }
 _refill() {
 const now = Date.now();
 const elapsed = (now - this.lastRefill) / 1000;
 this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillRate);
 this.lastRefill = now;
 }
}

此實作簡單、記憶體效率高，每個客戶端只有一個計數器，非常適合需要突發容忍的通用速率限制。

漏桶演算法

漏桶強制執行嚴格的流出率。請求進入隊列並以固定速率處理，完全防止突發。這使其成為保護無法處理突發流量峰值的下游系統的理想選擇。代價是由於佇列和無法處理任何類型的突發而導致更高的記憶體使用量。

滑動視窗演算法

滑動視窗方法比固定視窗計數器提供更準確的速率限制。滑動視窗日誌儲存目前視窗內所有請求的時間戳記。對於每個請求，視窗外的條目都會被刪除，並檢查剩餘的計數。這種方法是基於視窗的方法中最準確的，但會佔用大量內存，因此適合低流量場景或精度至關重要的情況。

滑動視窗計數器透過使用加權公式將先前的視窗計數與當前視窗部分計數相結合，提供了更實用的平衡：

weightedCount = previousWindowCount * overlapRatio + currentWindowCount

此方法每個客戶端僅使用兩個計數器，為大多數用例提供良好的準確性，並且是 Stripe 和 GitHub 使用的行業標準。

基於Redis的實現

Redis 是分散式速率限制最常見的後備儲存。其原子操作（例如 INCR 和 EXPIRE）提供了線程安全性，內建 TTL 可以實現自動計數器清理，Lua 腳本支援複雜的演算法實現。

const { SlidingWindowRateLimiter } = require("redis-rate-limiter");
const limiter = new SlidingWindowRateLimiter({
 client: redisClient,
 window: 60,
 limit: 100,
});

Redis 也為水平擴展和亞毫秒級操作延遲提供叢集支援。對於生產部署，用於原子速率限制、處理 Redis 故障轉移和效能調整的 Lua 腳本模式是重要的考慮因素。

WebAuthn and Passkeys: Passwordless 道地ation in 2024

Tue, 02 Apr 2024 00:00:00 +0900

Passwords have been the primary authentication mechanism for decades, but they come with well-documented security and usability problems. WebAuthn (Web Authentication) and the emerging passkey 生態系 promise to replace passwords with cryptographically secure, phishing-resistant authentication. As of 2024, passkey 支援 has reached critical mass across all major platforms, making this the ideal time to implement passwordless authentication.

Understanding WebAuthn

WebAuthn is a W3C standard that enables public-key cryptography-based authentication on the web. The core flow involves two operations: registration and authentication. During registration, the server sends a cryptographic challenge to the client, the authenticator creates a new key pair, and the public key is stored on the server. During authentication, the server sends a challenge, the authenticator signs it with the private key, and the server verifies the signature against the stored public key.

Vaultwarden: Self-Hosted Password Manager Installation 指南

Fri, 15 Mar 2024 00:00:00 +0000

What is Vaultwarden?

Vaultwarden is an open-source, self-hosted implementation of the Bitwarden server API, written in Rust. It is designed to be lightweight and resource-efficient compared to the official Bitwarden server, which requires a Microsoft SQL Server database and substantial system resources. Vaultwarden supports all official Bitwarden clients — desktop, browser extensions, mobile apps, and CLI — without any modification.

By self-hosting Vaultwarden, you retain full control over your password data. No third-party service ever touches your encrypted vault. The project is mature, actively maintained, and suitable for both single-user deployments and small teams.

OAuth 2.0 and OpenID Connect: Modern 道地ation 指南

Mon, 29 Jan 2024 00:00:00 +0900

OAuth 2.0 and OpenID Connect form the backbone of modern web authentication and authorization. Despite their ubiquity, these protocols are frequently misunderstood and misconfigured, leading to preventable security vulnerabilities. This guide covers the core concepts, implementation patterns, and security best practices you need to integrate authentication securely in your applications.

OAuth 2.0 Fundamentals

OAuth 2.0 is an authorization framework, not an authentication protocol. This distinction is critical: OAuth defines how a client application can obtain delegated access to protected resources, but it does not specify how to verify the user’s identity. That is where OpenID Connect comes in.