🙋舉例

不安全的驗證碼程式寫法：
這段程式碼(以php為例)是一個驗證碼並顯示在登入頁面上，但驗證碼在多次登入嘗試中保持不變，並且在成功或失敗後不會失效。 

<?php
session_start();

// 檢查是否已生成驗證碼，若無則生成
if (!isset($_SESSION['captcha'])) {
    $_SESSION['captcha'] = rand(1000, 9999); // 生成四位數的驗證碼
}

// 處理登入請求
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $username = $_POST['username'];
    $password = $_POST['password'];
    $userCaptcha = $_POST['captcha'];  

    // 驗證帳號、密碼和驗證碼
    if ($userCaptcha == $_SESSION['captcha']) {
        // 假設帳號和密碼正確
        echo "登入成功！";
    } else {
        echo "驗證碼錯誤，請重試！";
    }
}
?>

⚠️驗證碼可重複使用：以上的範例驗證碼保會存在 $_SESSION['captcha'] 中，且無論登入成功或失敗，都不會更新。攻擊者可以反覆使用相同的驗證碼，嘗試不同的帳號和密碼組合來進行暴力破解。 

安全程式寫法：

建議在「處理登入請求」程式碼中最後加上

// 無論成功與否，重置驗證碼
$_SESSION['captcha'] = rand(1000, 9999); // 更新為新的驗證碼 

🙋舉例
不安全程式寫法舉例：

my $username=param('username');

my $password=param('password');

if (IsValidUsername($username) == 1){

if (IsValidPassword($username, $password) == 1){

  print "Login Successful";

}else{

  print "Login Failed - incorrect password";

}

}else{

print "Login Failed - unknown username";

}

安全訊息統一回覆：
"Login Failed - incorrect username or password"

🙋舉例

👉資安這條路 15 - [Seesion] Session 劫持、 Session 固定

👉資安JAVA(一)：Session固定攻擊

🙋舉例

一家醫療系統網站，設有一般用戶和管理員兩種權限。
一般使用者可以查看自己的醫療紀錄，無法查看其他人的資料；管理員則擁有更高的權限，可以管理所有病患的醫療紀錄。 

某天，一般用戶 "Alice" 登入網站並查看她的醫療紀錄。她注意到自己的醫療紀錄 URL 是：
https://medicalsystem.com/record?patientID=123
Alice試想能否修改 patientID 參數來查看其他病患的資料。 

於是她將網址中的 patientID=123 更改為 patientID=456，竟然成功查看了另一名病患的紀錄。

🙋舉例

https://companysite.com/admin

https://companysite.com/login 

https://companysite.com/administrator 

⚠️儘管發現後台頁面仍然需要登入，但攻擊者現在知道了後台管理頁面的確切位置，就可以接續找可以被利用的漏洞，例如：帳號列舉、暴力破解等惡意攻擊。 

🙋舉例

👉資安漏洞修補 – IIS 目錄列舉(NTFS8.3格式)

👉微軟 IIS 目錄列舉 (資安風險)

🙋舉例

• (1) 用戶登入狀態查詢
  URL：https://www.example.com/profile?user_id=12345
  說明：當使用者點擊個人資料頁面，GET 方法會傳送用戶的 ID(如 user_id=12345)來顯示對應的個人資料。
  不適合使用 GET 的原因： 將 user_id 等敏感資料放在 URL 中容易被截取或洩漏。URL 通常會被記錄在瀏覽器歷史紀錄、伺服器日誌和第三方分析工具中，這會增加資料外洩的風險。

• (2) 訂票系統查詢
  URL：https://www.example.com/tickets?from=NYC&to=LAX&date=2024-10-31
  說明：在訂票系統中，GET 方法可用來查詢航班資訊，傳送出發地、目的地和日期等參數。
  不適合使用 GET 的原因：
  如果查詢涉及更多個人化資料，如：身份證號碼、信用卡資訊或其他敏感個人資料，則 GET 傳送方式會將這些資訊暴露在 URL 中，存在安全風險。
  **若只涉及一般查詢(如：日期、城市名稱)，GET 是可接受的。但當查詢涉及個人身份識別資訊時，應使用 POST 並進行適當的加密。

防禦注意事項：👉可參考這篇

✨google官方說明：如何編寫及提交 robots.txt 檔案

修補建議

• 移除或限制存取設定檔，系統部署到正式環境時，移除不必要的開發檔案或備份檔案，並確保這些檔案不會被公開存取而洩系統漏訊。

🙋舉例

一個電子商務網站的購物車系統出現錯誤。當使用者將商品加入購物車時，由於伺服器端出現問題，頁面顯示了以下錯誤訊息：

Error: SQL Syntax Error in /add_to_cart.php at line 45
SELECT * FROM Products WHERE productID = 'xyz';
Database: MySQL 5.6, Server: Apache 2.4.3, File Path: /var/www/html/shop/add_to_cart.php

⚠️以上例子錯誤訊息過於詳細，不僅揭示了資料庫類型（MySQL 5.6）和伺服器資訊（Apache 2.4.3），還包含了 SQL 查詢結構和文件路徑。
攻擊者可以利用這些資訊發現網站使用的資料庫類型、伺服器配置，甚至針對 SQL 查詢結構進行 SQL 注入攻擊。

🙋舉例

👉資安這條路 15 - [Seesion] Session 劫持、 Session 固定

👉資安JAVA(一)：Session固定攻擊

修補建議

• 對應用程式處理、儲存、傳輸的資料進行分類，根據個資法、法令法規、或商業需求辨識哪些為敏感性資料。

• 非必要不儲存敏感性資料，盡快刪除或使用符合PCI DSS的資料記號化(tokenization)。 

PCI DSS：代表「支付卡產業資料安全標準」(PCI DSS)。PCI DSS 框架為企業提供強大的流程，以保護持卡人交易資料和卡片認證資訊的安全性。它旨在保護持卡人資料和認證資料，要求幫助防止、偵測和對安全事件做出反應。

(資料來源：什麼是 PCI DSS 合規性？| PCI DSS 定義)

🙋舉例

舉一個簡單的登入系統(以php為例)，程式直接將使用者輸入的帳號和密碼放入 SQL 查詢語句中： 

<?php
// 使用者登入輸入
$username = $_POST['username'];
$password = $_POST['password'];

// 不安全的 SQL 查詢
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

// 檢查登入結果
if (mysqli_num_rows($result) > 0) {
    echo "登入成功";
} else {
    echo "登入失敗";
}
?>

攻擊者可以在 username 欄位輸入以下內容： 

' OR '1'='1

使查詢語法會變成： 

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

⚠️這個語句繞過了帳號和密碼檢查，因為OR '1'='1' 永遠為真，攻擊者就能成功登入系統，無需輸入正確帳號和密碼，即可成功登入。 ⚠️

🙋舉例

舉一個簡單的留言板系統(以php為例)，使用者可以提交留言，但系統未對輸入內容進行過濾或編碼，直接將內容顯示在頁面上： 

<?php
// 使用者輸入的留言
$message = $_POST['message'];

// 不安全地顯示留言
echo "<p>留言內容: $message</p>";
?>

攻擊者可以在 message 欄位中直接輸入以下內容： 

<script>alert('您的帳戶可能被攻擊了！');</script>

留言內容在頁面顯示為： 

<p>留言內容: <script>alert('您的帳戶可能被攻擊了！');</script></p>

⚠️當其他用戶訪問這頁面時，瀏覽器會執行這段 JavaScript，並彈出一個警告視窗顯示訊息「您的帳戶可能被攻擊了！」。這證明了 XSS 的存在，攻擊者可以利用這個漏洞進行更危險的操作，例如：竊取 cookie 或重定向使用者到惡意網站。 

⚠️更新套件/第三方元件時應注意：

1. 檢查系統其他元件的相容性

2. 備份與版本控制，避免直接在正式環境更新

3. 確認更新來源可信

如何正確的取得使用者 IP？👉點我參考

修補建議

• 通知帳號擁有者：
  每次重設行為都寄送通知信(不論是否成功)

• Token 設計安全與使用者帳號綁定：

  • 使用難以預測的亂數(如 UUID + HMAC)

  • 設定時效(如15 分鐘內有效)

  • Token 只能對應該帳號，並且僅能使用一次

• 限制 reset 次數與速率：
  防止惡意大量觸發 

• 強制使用者重新登入或雙重驗證後重設