Yoru Karu Studio
程式設計學習筆記 | 生活心得程式設計學習筆記 | 生活心得
03-1. XSS 基礎：什麼是跨站腳本攻擊？ ⏱️ 閱讀時間： 12 分鐘 🎯 難度： ⭐⭐ (中等) ⚠️ 警告： 本文內容僅供學習與防禦用途，禁止用於非法攻擊
🎯 本篇重點 理解 XSS（Cross-Site Scripting）的基本原理、危害程度、三種類型（Reflected、Stored、DOM-based），以及真實案例。
🤔 什麼是 XSS？ XSS（Cross-Site Scripting，跨站腳本攻擊） = 在網頁中注入惡意 JavaScript，當其他用戶瀏覽時執行
一句話解釋： XSS 就像是在公共佈告欄上貼一張「有毒」的海報，任何看到海報的人都會中毒。
為什麼叫 XSS 不叫 CSS？ 原本應該叫 CSS (Cross-Site Scripting) 但 CSS 已經被 Cascading Style Sheets（層疊樣式表）使用 所以改成 XSS（Cross 的 X）技術定義 正常顯示用戶輸入： 用戶輸入：Hello World 網頁顯示：<div>Hello World</div> XSS 攻擊： 用戶輸入：<script>alert('XSS')</script> 網頁顯示：<div><script>alert('XSS')</script></div> ↑ 這段 JavaScript 會被執行！ 結果： 其他用戶瀏覽這個頁面時，會看到彈出視窗 （實際攻擊會竊取 Cookie、重定向等） 🎨 生活中的比喻 情境：公共佈告欄 正常使用： 你：在佈告欄貼「徵室友」海報 其他人：看到海報，聯絡你 XSS 攻擊： 駭客：貼「掃描此 QR Code 領 $1000」海報 QR Code 連到惡意網站 其他人：掃描 QR Code → 手機被植入病毒 關鍵問題： 佈告欄管理員沒有檢查海報內容 讓惡意海報和正常海報混在一起 無法分辨哪些是危險的技術對應 佈告欄 = 網站頁面 海報 = 用戶輸入（留言、個人資料） 看海報 = 瀏覽頁面 海報內容 = HTML/JavaScript 代碼 管理員沒檢查 = 網站沒有輸出編碼 XSS = 在「公共空間」注入惡意內容 讓所有訪客受害 💥 XSS 的危害 危害程度：🔥 高（滿分 5 顆星的 4 顆） 可能後果： 1.
RAG 不只一種：選擇適合的架構 當你開始建立 RAG 系統時，很快會發現「檢索 → 生成」這個簡單流程無法應對所有場景：
❓ 問題 1：第一次檢索的資訊不夠完整怎麼辦？ ❓ 問題 2：複雜問題需要分步驟解決怎麼做？ ❓ 問題 3：如何讓系統自己決定要不要檢索？
根據 Gao+ (2023) 的研究，RAG 系統可以分為三大類型，每種都針對不同的問題場景設計。
本文將深入解析：
Iterative RAG：提供更多上下文資訊 Recursive RAG：逐步拆解複雜問題 Adaptive RAG：靈活控制檢索與生成 🔄 Type 1: Iterative RAG（迭代式 RAG） 核心思想 「如果一次檢索不夠，就多檢索幾次」
基礎 RAG 的問題： Query → Retrieve → Generate → Response ↑ 只檢索一次，資訊可能不足 Iterative RAG 的解決方案： Query → Retrieve → Generate → Judge ↓ ↓ Response ← 迭代 N 次工作流程 步驟 1：Query（問題） 「Django 的部署最佳實踐是什麼？」 步驟 2：Retrieve（檢索） 找到：「Django 需要配置 WSGI 伺服器.
02-3. SQL Injection 防禦：Prepared Statements 與最佳實踐 ⏱️ 閱讀時間： 12 分鐘 🎯 難度： ⭐⭐ (中等) ⚠️ 重要： 本篇是 SQL Injection 系列最重要的一篇！
🎯 本篇重點 學習如何完全防禦 SQL Injection：Prepared Statements 原理、Django ORM 最佳實踐、輸入驗證、最小權限原則，以及完整的安全檢查清單。
🛡️ 防禦的核心原則 黃金法則 永遠不要將用戶輸入直接拼接到 SQL 查詢中！為什麼字串拼接危險？ # ❌ 危險：字串拼接 username = "admin' OR '1'='1" query = f"SELECT * FROM users WHERE username = '{username}'" # 執行：SELECT * FROM users WHERE username = 'admin' OR '1'='1' # ↑ # 輸入改變了 SQL 結構 # ✅ 安全：參數化查詢 username = "admin' OR '1'='1" query = "SELECT * FROM users WHERE username = %s" cursor.
為什麼需要 Multi-step RAG？ 想像你問：「Django 的創始人還創建了哪些其他框架？」
基礎 RAG 的困境：
步驟 1：檢索「Django 創始人」 找到：「Django 由 Adrian Holovaty 和 Simon Willison 創建」 步驟 2：生成答案 LLM：「我不知道 Adrian Holovaty 創建了哪些其他框架」 ❌ 失敗：需要再次檢索才能回答Multi-step RAG 的解決方案：
步驟 1：檢索「Django 創始人」 找到：Adrian Holovaty 步驟 2：再次檢索「Adrian Holovaty 創建的框架」 找到：Django、Soundslice 步驟 3：生成答案 LLM：「Adrian Holovaty 創建了 Django 和 Soundslice」 ✅ 成功：透過多次檢索完成推理本文將深入探討如何實作這種需要多步驟推理的 RAG 系統。
🎯 什麼是 M-hop 問題？ M-hop（多跳）問題定義 M-hop 問題：需要透過 M 次「跳躍」（檢索）才能找到答案的問題。
1-hop 問題（簡單） 問題：「Django 是什麼？」 檢索 1 次： 「Django 是 Python 網頁框架」 → 直接找到答案 ✅2-hop 問題（中等） 問題：「Django 的創始人的出生地在哪裡？」 檢索 1：「Django 創始人是誰？」 答案 1：Adrian Holovaty 檢索 2：「Adrian Holovaty 的出生地？」 答案 2：美國伊利諾州 最終答案：美國伊利諾州 ✅3-hop 問題（困難） 問題：「Django 的創始人出生的州的首府是哪裡？」 檢索 1：「Django 創始人」 → Adrian Holovaty 檢索 2：「Adrian Holovaty 出生地」 → 美國伊利諾州 檢索 3：「伊利諾州的首府」 → Springfield 最終答案：Springfield ✅為什麼基礎 RAG 無法處理？ # 基礎 RAG 的流程 def basic_rag(query): # 1.
02-2. SQL Injection 攻擊技巧：Union、Blind、Time-based ⏱️ 閱讀時間： 18 分鐘 🎯 難度： ⭐⭐⭐ (中高) ⚠️ 警告： 本文內容僅供學習與防禦用途，禁止用於非法攻擊
🎯 本篇重點 深入學習 4 種進階 SQL Injection 攻擊技巧：Union-based、Boolean-based Blind、Time-based Blind、Error-based，理解如何在不同限制下竊取資料。
📊 SQL Injection 攻擊分類 依回顯方式分類 1. In-band SQL Injection（帶內注入） ├─ Union-based（最常見） ├─ Error-based └─ 攻擊者可以直接看到查詢結果 2. Blind SQL Injection（盲注） ├─ Boolean-based（邏輯盲注） ├─ Time-based（時間盲注） └─ 攻擊者看不到查詢結果，需要推斷 3. Out-of-band SQL Injection（帶外注入） └─ 使用不同管道（如 DNS、HTTP）傳輸資料 └─ 較少見，需要特定資料庫功能難度對比 類型 難度 速度 適用場景 Union-based ⭐⭐ 快 查詢結果顯示在頁面上 Error-based ⭐⭐ 快 錯誤訊息顯示在頁面上 Boolean-based Blind ⭐⭐⭐ 慢 頁面有明顯差異（有無資料） Time-based Blind ⭐⭐⭐⭐ 很慢 頁面無差異，只能用時間判斷 1️⃣ Union-based SQL Injection 原理 使用 UNION 語句合併兩個查詢結果，在頁面上顯示額外資料
為什麼 Reranking 是 RAG 系統的關鍵？ 想像你在圖書館找書，館員快速幫你找出 50 本相關的書，但順序是隨機的。你需要的那本可能排在第 37 位。
Reranking（重新排序） 就像一位細心的圖書館員，仔細檢查這 50 本書，把最相關的放在最前面。
本文將深入探討：
Pointwise vs Pairwise：兩種 Reranking 方法的對比 LLM Zero-shot Reranking：無需訓練的強大方案 如何用 Reranking 改進 Retriever 🎯 Reranking 在 RAG 中的角色 Two-Stage Retrieval（兩階段檢索） 階段 1：Fast Retrieval（粗排） 10,000 個文檔 → 向量搜尋 → Top 50 ⏱️ 速度：50ms 🎯 目標：快速縮小範圍 階段 2：Reranking（精排） Top 50 → 深度評分 → Top 5 ⏱️ 速度：200ms 🎯 目標：精確排序 結果： ✅ 總時間 250ms（可接受） ✅ 準確率大幅提升為什麼不直接用更好的模型檢索？ # 問題：計算成本 # 方案 A：用強大模型直接檢索 10,000 個文檔 時間：10,000 × 20ms = 200 秒（太慢！） 成本：極高 # 方案 B：兩階段 階段 1：用快速模型檢索 → 50ms 階段 2：用強大模型 Rerank Top 50 → 200ms 總時間：250ms（可接受！） 成本：合理 結論：Reranking 是效率與效果的最佳平衡📊 Reranking 的兩大方法 1.