文章

從開發到部署：確保Web應用程式的全面安全

發布於
作者 Ruiwen
44 分鐘閱讀

1. 引言

隨著互聯網技術的迅速發展，Web應用程式已成為現代社會中不可或缺的一部分，涵蓋了從電子商務、社交媒體到企業內部管理等各種功能。然而，這些應用程式也成為了網絡攻擊者的主要目標。根據統計，全球每年因網絡攻擊所造成的損失數以億計，這不僅威脅到企業的正常運營，還可能造成個人隱私的洩露和財產的損失。因此，確保Web應用程式的安全已經成為每一位開發者和管理者的首要任務。

介紹Web應用程式安全的重要性

Web應用程式的安全性不僅關乎到企業的商譽和用戶的信任，更涉及到法律和合規性的要求。無論是SQL注入、跨站腳本攻擊（XSS）、還是其他各種形式的網絡攻擊，都可能導致數據洩露、服務中斷甚至是財務損失。

為了應對這些挑戰，開發者必須在應用程式的開發、部署和運行過程中採取一系列的安全措施，從而防止潛在的安全威脅。

簡述文章的目標和涵蓋範圍

本文提供一套全面的Web應用程式安全指南，涵蓋從開發到部署的各個階段。我們將深入探討在開發過程中需要考慮的安全編碼實踐、如何防止常見的攻擊如XSS和SQL注入，以及如何設計安全的認證和授權機制。此外，我們還將介紹靜態和動態應用程式安全測試（SAST和DAST），以及如何使用漏洞掃描工具來確保應用程式的安全。特別的是，我們會深入探討OWASP Top 10，這是目前最為權威的Web應用程式安全風險指南，並提供具體的防護措施。最後，我們將探討部署階段的安全策略、維護階段的安全管理以及應對安全事件的有效方法。

透過這一系列的學習，希望讀者能夠建立起全面的Web應用程式安全意識，並具備實踐中的安全技能，以確保所開發和運營的應用程式免受各種網絡威脅的侵害。

2. 開發階段的安全考量

在開發階段的安全考量中，應始終將安全性作為設計和編碼的核心原則，從一開始就內嵌在系統中。開發人員應實施和遵循安全編碼標準與最佳實踐，如正確處理用戶輸入、進行數據加密和驗證。通過持續的安全測試和程式碼審查，及早發現並修補潛在的漏洞，確保軟體在運行時的安全性。

a. 安全編碼實踐

  • 安全意識：時刻考慮並防範潛在的安全威脅，確保每一行程式碼都遵循安全原則。
  • 建議做到不信任任何輸入的資訊：通常服務或應用程式在沒有進一步驗證的情況下，不應該接受任何輸入，這避免了使用可能過時、格式錯誤或惡意資料的風險。
    為了防止此項漏洞，開發人員應符合以下原則：
    1. 永遠不要信任使用者輸入
    2. 提供使用者輸入時應限制使用者的選項
    3. 在執行送出請求前於用戶端進行初步驗證
    4. 在伺服器端接收使用者輸入表單時，使用「完全匹配、白名單、黑名單」進行驗證
    5. 拒絕無效輸入、或是清除及轉譯成有效輸入
    6. 應驗證來自所有類型來源的輸入，包括使用者、檔案、資料庫、網路、外部服務等

  • 數據轉義不足：資料轉義旨在將某些字元轉譯成保留其含義的表達方式，且確保應用程式上下文將其解析為純文字資料而非指令。例如：

    字元(char)輸出(output)
    &&
    <&lt;
    >&gt;
    ”&quot;
    ’&#x27;
    /&#x2F;

    為了防止此項漏洞，開發人員應符合以下原則

    1. 對所有來自外部來源的資料進行編碼和轉義
    2. 確定哪些解譯器將使用資料，以及哪些字元應該編碼
    3. 不論是輸入還是輸出都應正確轉義
  • 防範 SQL 注入：使用預備語句、參數化查詢和 ORM 工具來確保所有 SQL 查詢的安全。
    改善措施：
    1. 使用預備語句（Prepared Statements）：預備語句（也稱為參數化查詢）可以確保 SQL 查詢中的每個參數都被正確地解釋為數據，而不是 SQL 語句的一部分。
    2. 使用 ORM（對象關係映射）工具：ORM 工具可以自動生成 SQL 查詢，並提供參數化查詢功能，從而減少手工編寫 SQL 語句的機會，降低 SQL 注入風險。
    3. 輸入驗證和清理：確保應用程序中的所有用戶輸入都經過嚴格的驗證和清理，以過濾掉潛在的惡意代碼。
    4. 最小權限原則：為數據庫用戶分配最小必要的權限，限制應用程序能夠執行的操作範圍，即使攻擊者成功進行 SQL 注入，他們的操作也會受到限制。
    5. 定期安全測試：進行定期的安全測試和代碼審計，識別和修復潛在的安全漏洞。
  • 跨站腳本攻擊 (XSS) 的防護：對所有用戶輸入進行嚴格的輸入驗證和輸出編碼，防止惡意腳本注入。
    1
2
3
4
5
6
7
8

      ...    
  app.UseAuthorization();
  // CSP 中間
  app.Use(async (context, next) =>
  {
      context.Response.Headers.Add("Content-Security-Policy", "default-src 'self'; script-src 'self' https://trustedscripts.example.com; object-src 'none'; style-src 'self' https://trustedstyles.example.com; img-src 'self' data:;");
      await next();
  });
    CSP規則說明
    default-src 'self'僅允許從相同來源加載所有資源。
    script-src僅允許從指定來源加載腳本。
    object-src僅允許從指定來源加載插件內容（如 Flash）。
    style-src僅允許從指定來源加載樣式表。
    img-src僅允許從指定來源加載圖像。
    connect-src僅允許從指定來源加載資源（如 AJAX 請求）。
    font-src僅允許從指定來源加載字體。
    media-src僅允許從指定來源加載音頻和視頻。
    frame-src僅允許從指定來源加載框架內容。
    sandbox启用指定的安全功能，例如 ‘allow-forms’, ‘allow-scripts’。
    report-uri指定報告 URI，瀏覽器將 CSP 違反報告發送到此 URI。
    block-all-mixed-content阻止加載所有混合內容（HTTP 和 HTTPS 混合）。
    upgrade-insecure-requests自動將所有 HTTP 請求升級為 HTTPS。
  • 跨站請求偽造 (CSRF) 的防護：使用 CSRF 令牌來驗證每個請求的合法性，防止未經授權的操作。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// HomeController
using Microsoft.AspNetCore.Mvc;

public class HomeController : Controller
{
    [HttpPost]
    [ValidateAntiForgeryToken]
    public IActionResult SomeAction(SomeModel model)
    {
        if (ModelState.IsValid)
        {
            // 處理表單提交
        }
        return View(model);
    }
}

// Startup
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddAntiforgery(options => 
    {
        // 在某些情況下，你可能希望使用自定義標頭來傳遞 CSRF 令牌。在這種情況下，需要在 Startup.cs 中設置自定義標頭名稱，並在 JavaScript 中包含該標頭：
        options.HeaderName = "X-CSRF-TOKEN";
    });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// Index.html
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>
<script>
    $(document).ready(function () {
        var token = $('input[name="__RequestVerificationToken"]').val();

        $.ajaxSetup({
            headers: {
                'X-CSRF-TOKEN': token
            }
        });

        $("#myForm").submit(function (event) {
            event.preventDefault();
            $.post({
                url: '/Home/SomeAction',
                data: $(this).serialize(),
                success: function (response) {
                    // 處理成功響應
                }
            });
        });
    });
</script>

<form id="myForm" asp-action="SomeAction" method="post">
    @Html.AntiForgeryToken()
    <!-- 其他表單字段 -->
    <button type="submit">提交</button>
</form>

b. 認證與授權

  • 安全的密碼儲存：使用強加密算法（如 bcrypt）對密碼進行哈希處理，並加鹽儲存，以防止數據洩露時的密碼破解。
  • 使用多因素認證 (MFA)：在登入系統時，除了輸入密碼外，還需要提供另一種驗證方式（如短信驗證碼或指紋掃描）以增加安全性。
  • 基於角色的存取控制 (RBAC)：根據用戶的角色分配相應的權限，確保每個用戶只能訪問其職責範圍內的資源和操作。

不恰當的身份驗證

當應用程式不當驗證使用者身份時，就會產生此類型漏洞。這可能導致資源或功能曝露給意外的參與者，從而可能為攻擊者提供敏感資訊。

例如：將工作階段的 Cookie 資訊透過 base64decode 解密成 Json 透過替換其中的 role 使其變成管理員角色。

為了防止此項漏洞，開發人員應符合以下原則

  1. 建議注意身份驗證檢核是否足夠且正確，以避免遺漏
  2. 不要在 URL 中曝露中作階段 ID
  3. 實施多因子身份驗證
  4. 不要將使用者 ID，或可預測的序列值作為工作階段 ID，而要使用安全的伺服器端工作階段管理器，且該管理器產生具有高熵的隨機工作階段 ID

c. 敏感資料保護

  • 資料保護：如果設計良好，應用程式應當實施安全控制項，以確保敏感資訊的保護和完整性。
  • 數據加密：所有敏感數據在存儲和傳輸時都應使用強加密技術保護，以防止未經授權的訪問。
  • 確保API的安全性：API應採用認證、授權和數據驗證機制來保護數據，防止未經授權的存取和攻擊。

  • 深入到 Cookie 和工作階段：Cookie 通常包含工作階段資訊，因此攻擊者可以獲取這些資訊。通常導致 Cookie 工作階段漏洞的可能原因是，由於遺漏或不當配置 cookie flags 導致。例如：「Secure、HttpOnly、Domain」。HTTP 是一種無狀態協定，因此 Cookie 透過儲存與使用者動作相關的值來追蹤使用者的狀態。

    如何保護Cookie

    Headers說明
    Secure避免在不安全的通道上傳輸
    HttpOnly禁止 JavaScript 讀取 Cookie 的值
    Domain設定 Cookie 可以使用的網域
    Path設定 Cookie 可用的子資料夾和頁面
    Expires確定何時應刪除 Cookie

    為了防止此項漏洞，開發人員應符合以下原則

    1. 一律將工作階段資訊儲存在 cookie 中。而不將工作階段資訊作為參數傳遞（URL）。
    2. 設定 Secure、HttpOnly
    3. 將 Domain、Path 設定盡可能窄
    4. 將 Expires 設定為0，但永久性 cookie 除外

    綜上所述，為了防止此項漏洞，開發人員應符合以下原則

    1. 僅在必要時才儲存私人資訊
    2. 永遠不要在程式碼中使用硬編碼（Hard Code）秘密資訊
    3. 不要使用純文字格式來儲存資料庫憑證或加密金鑰
    4. 安全儲存所有敏感資訊
    5. 透過安全通訊通道發送流量請求
    6. 告知使用者已經實施的隱私權原則

    範例：一個良好的電子商務應用程式，在用戶進行信用卡付款時，使用「TLS」保護進出網站的通訊，信用卡號碼因為遮罩(Mask)也不會完整顯示，快取(cache)也被關閉，且信用卡號碼也被「強演算法」加密儲存在資料庫中，因此攻擊者幾乎不可能存取未經授權的資料。

  • 本機儲存空間 又稱 Web 儲存空間，允許應用程式在用戶端儲存索引鍵/值對 localStorage.setltem("age", age);。
    當應用程式顯示使用 localStorage 來儲存資料時，會出現這類漏洞。

    為了防止此項漏洞，開發人員應符合以下原則

    1. 由於 localStorage 始終可以被 JavaScript 存取，並且沒有辦法限制路徑。因此開發人員在儲存機敏資訊時應避免使用
    2. 如果必須使用，可將數據先進行加密處理
    3. 設定適當的過期時間
    4. 確保應用程式使用 HTTPS，防止數據在傳輸過程中被攔截
    5. 定期清理 localStorage 中不再需要的數據，減少潛在風險

d. 重用現有的安全控制措施

  • 在框架或語言中重新使用現有的安全控制措施：這項規則旨在避免過於複雜的開發方法，因為可能增加攻擊面，在可能的情況下，應重複使用已經證明其價值的現有實施作法。

    應當考慮 「整潔編碼（Clear Code）」，假設在一段程式碼中有資訊安全漏洞，有多個地方重複使用到該段程式，但因為各自複雜性不同，遺漏一個應修正的地方，則將來該段程式就有可能被攻擊，因此若實施整潔編碼，使開發人員團隊都從一個特定程式庫取得該段程式，則修改時只須在一個地方上進行修改，且不會因複雜度而遺漏或造成混亂，那麼修復這項問題就可以很輕鬆且快速。

    為了防止此項漏洞，開發人員應符合以下原則

    1. 在設計和實施系統時要謹記簡潔性
      • 盡可能使用經過證實的程式庫，且避免使用複雜的架構
    2. 在團隊中指導開發人員如何使用設計模式，和編碼最佳做法非常重要

e. 威脅建模

威脅建模是一種識別、溝通和理解安全威脅與緩解措施的方法，它可以幫助團隊評估威脅，並確定威脅的優先順序。

目前有許多威脅建模方法，如「STRIDE、Attack Trees等」，但在這些方法中有一些共同點，威脅模型應包含四個主要因素

  1. 資產（Assets）：應用程式
  2. 漏洞（Vulnerabilities）：被破解時可能造成損害的漏洞
  3. 威脅（Threats）：由於破解漏洞而可能發生的潛在損害
  4. 威脅代理者（Threat Agents）：利用漏洞造成威脅的人，這可能是內部人員也可能是外部人員

基本威脅建模過程應包括評估

  1. 正在處理的資產的說明或模型，以確定事前識別的每個威脅的總體風險
  2. 針對威脅的補救措施，確定可以採取哪些對策，來降低風險程度

要開始使用威脅建模，開發人員應符合以下原則

  1. 威脅建模在早期完成的情況下最有效，這樣潛在威脅可以為應用程式設計提供資訊參考
  2. 確保業務目標和需求在此威脅模型中發揮作用，以確保提供恰當的保護
  3. 隨著專案和環境的發展，應定期重新評估威脅
  4. 威脅建模過程應包括以下問題
    1. 我們在建置什麼？
    2. 可能出現的什麼樣的錯誤？
    3. 在哪裡最容易受到攻擊？
    4. 那些威脅最相關？
    5. 我們應該如何因應那些威脅？
    6. 我們怎麼做才能防範這些威脅？
    7. 我們的工作做得好嗎？

STRIDE 威脅建模

這是一種威脅建模方法，可以幫助您識別正在開發的應用程式中的潛在安全問題。它是由微軟Micosoft開發，且被認為是識別威脅最全面的方法之一。

字母英文威脅危及範圍
S冒用（Spoofing）身份驗證（Authentication）
T竄改（Tampering）完整性（Integrity）
R否認（Repudiation）不可否認性（Non-repudiation）
I資訊洩漏（Information Disclosure）機密性（Confidentiality）
D拒絕服務（Denial of Service）可用性（Availability）
E特權提升（Elevation of Privilege）授權的預期屬性（Authorization）

3. 測試階段的安全措施

a. 安全測試方法

  • 靜態應用安全測試 (SAST)：在開發階段分析程式碼，找出潛在的安全漏洞。
  • 動態應用安全測試 (DAST)：在運行階段模擬攻擊，檢測應用程式的安全缺陷。
  • 滲透測試：模擬真實攻擊，評估系統的防禦能力和潛在的安全漏洞。

b. 自動化測試工具

  • 使用CI/CD管道進行自動化安全測試：在持續集成和部署過程中自動執行安全測試，確保及早發現並修正安全問題。

4. 部署階段的安全策略

a. 安全配置

  • 預設安全：表示應用程式的預設配置設定，是最安全的設定。

    範例一：如果註冊使用者時，允許使用「弱密碼」的預設政策，則攻擊者就能很迅速的暴力破解出使用者的帳密，從而進行攻擊行為。

    範例二：弱用戶端輸入驗證，在伺服器端使用損壞、自訂的驗證功能，資料庫使用的連線使用者甚至預設使用具有讀寫權限的使用者，那麼攻擊者就能刪除資料表。

    為了防止此項漏洞，開發人員應符合以下原則

    1. 從一開始就安全地設計應用程式，將安全性整合到開發生命週期中
    2. 應用程式於註冊使用者時，就使用「強密碼」政策
    3. 一律套用「最小特權」原則，且伺服器元件應以最少的必要權限執行
    4. 停用任何不使用的服務或功能
  • 設置安全的Web伺服器：確保Web伺服器配置正確，並使用最新的安全措施保護應用程式。
  • 使用安全的配置文件：應用安全配置文件，防止不必要的訪問和潛在的安全漏洞。

b. 基礎設施安全

  • 虛擬機和容器的安全性：保護虛擬機和容器環境，防止未授權的存取和攻擊。
  • 使用防火牆和入侵檢測系統 (IDS)：部署防火牆和入侵檢測系統，實時監控和防禦惡意活動。

c. 持續監控

  • 日誌紀錄：當應用程式不紀錄與安全相關的資訊，即根本不紀錄時會發生此漏洞。另一方面當應用程式紀錄機密資訊時，也會發生此類漏洞。
    為了防止此項漏洞，開發人員應符合以下原則
    1. 使用框架集中日誌紀錄，這樣做可以確保日誌易於檢視並管理
    2. 應在所有「應用程式層」紀錄活動，並一律記錄關鍵事件（ex: 成功/失敗的登入嘗試、資料修改和查詢）
    3. 一般情況下記錄所有相關資訊，遵循「日誌紀錄的5W」原則
    4. 發生什麼事？
    5. 什麼時間？
    6. 在哪裡？（資訊主機、網路和介面）
    7. 影響範圍？
    8. 來自哪裡？
    9. 應避免記錄機敏資訊
    10. 僅限授權存取人員取得並分析日誌
  • 日誌記錄和監控：持續收集和分析系統日誌，以發現和應對潛在的安全威脅。
  • 安全信息和事件管理 (SIEM)：集中管理和分析安全事件和信息，提供即時的威脅檢測和應對能力。

d. 瀏覽器安全策略

  • CSP、SOP 和 CORS：這類漏洞通常發生在不正確設定 CORS 和 CSP 標頭所引起的。例如指定萬用字元，從而允許所有外部來源。或者遺漏 CSP 標頭，導致應用程式不會限制載入的來源。

  • 相同來源原則（SOP）：是一種將來自不同源頭的來源隔離的安全機制。
    源頭定義：

    protocolhostport
    http://www.example.com:80

  • 內容安全性原則（CSP）：標頭允許應用程式定義，允許在其網站上載入的內容來源，如 javaScript、HTML框架和其他小程式。或者遺漏 CSP 標頭可能允許在應用程式中載入外部來源。Access-Control-Allow-Methods：* （指定存取資源時允許的方法）

    CSP 設置說明
    script-srt定義可以執行哪個腳本
    form-action列出表單提交的有效端點
    child-src定義嵌入框架允許的內容
    object-src限制 Flash 和其他插件的載入位置

    配置良好的 CSP 標頭可以防止跨網站指令馬處理、點擊劫持和網頁上的其他內容注入。

  • 跨來源資源分享（CORS）：標頭允許覆寫 SOP 並使資源對其他來源可用。當 CORS 標頭為外部參與方授予對應嫆程式資源的存取權時，會發生來源問題。Access-Control-Allow-Origin：* (指定可以存取資源的 URL)
    為了防止此項漏洞，開發人員應符合以下原則

    • 內容安全性政策：
      1. 確定應該能夠運行的資源
      2. 為每個頁面明確指定資源
      3. 設定 default-src
    • 跨來源資源分享：
      1. 判斷是否需要向其他來源提供存取資源
      2. 避免配置過於寬鬆，不應指定萬用字元來允許公共存取

e. 用戶端安全

  • 用戶端安全措施存在問題：此類漏洞會在伺服器端，僅依賴在用戶端實施的安全機制時出現，例如輸入表單驗證。
    為了防止此項漏洞，開發人員應符合以下原則
    1. 切勿僅依賴用戶端驗證，應該在伺服器端同時進行驗證，尤其是與安全相關的檢核
    2. 切勿儲存機敏資訊（如使用者密碼等）

    範例：例如輸入留言或評論時，前端針對輸入進行允許字元檢查，但在送出請求時，攻擊者簡單透過「攔截代理」設定，即可在用戶端驗證完成之後修改請求，已修改評論包含未經允許的字元，成功進行儲存 XSS 攻擊，只因該應用程式只依賴於用戶端輸入驗證，而導致 XSS。

5. 維護和更新

a. 定期安全審查

  • 程式碼審查：持續進行程式碼審查，以識別並修復潛在的安全漏洞。
  • 安全漏洞掃描：使用安全漏洞掃描工具，檢測並修復系統中的安全缺陷。

b. 安全補丁管理

  • 更新軟體和依賴項：定期更新應用程式及其所有依賴項，以保持系統的安全性。
  • 快速應對安全漏洞：在發現安全漏洞時，迅速採取行動，發布修補程式以保護系統。

6. 安全設計原則

深度防禦

深度防禦是一種設計原則，旨在透過將網路存取伺服器服務分層化，提高駭客入侵的難度，從而達到保護應用程式的目的。

  1. 資料層級：
    • 機敏資料儲存在資料庫時會被加密（ex: 使用者密碼）
    • 應具備：存取控制、加密、備份、還原程序
  2. 應用程式層級：
    • 應用程式具有廣泛的輸入驗證機制（ex: 防止注入攻擊）
    • 應具備：身份驗證、授權、稽核(也稱AAA)及強化安全編碼
  3. 伺服器層級：
    • 伺服器主機無論是OS版本還是JAVA版本或是其他任何防毒，都一律更新到最新
    • 應具備：強化身份驗證、修補程式管理、防毒軟體
  4. 內部網路層級：
    • 內網被劃分成不同區域，並受防火牆規則保護
    • 應具備：IPsec、TLS、NAT
  5. 周邊層級：
    • 防火牆將內部網路邊界與外部網際網路區分開
    • 應具備：防火牆、TLS、拒絕服務、預防
  6. 實體層級：
    • 伺服器位於一個需要權限識別證保護的機房中
    • 應具備：警衛、鎖具、追蹤裝置、識別證系統
  7. 綜合層級：
    • 進行安全評估與依從性檢查

開放式設計

同樣屬於一種設計原則，開發人員應從頭開始安全地設計並實施系統，不能僅僅依賴「透果隱匿來實現安全性」，一些特殊的伺服器控制項應基於公開且已知的原則，這樣即使駭客知道應用程式的內部運作方式，這些控制項仍然安全且可靠。

例如：網頁中夾雜隱藏表單，用以控制權限高低，只要在提交前竄改，即可取得超越自己本來擁有的權限，進而對伺服器進行不正當的存取控制。

最低權限

這是一條通運規則，它規定所有使用者、應用程式和系統功能都應以盡可能少的權限執行，來完成各自的角色。

例如：在某個功能的後端程式會進行資料庫存取，該存取連線使用者具有「讀寫權限」儘管實際上該應用程式功能不需要，若遭遇「SQL注入攻擊」則可能發生特定資料表被刪除，進而導致應用程式崩潰（生產中斷、資料遺失）。

為了防止此項漏洞，開發人員應符合以下原則

  1. 雖然這並不能修補任何已發現的安全漏洞，但這將使攻擊者儘管竊取到用戶帳號，卻也不能用來執行超過其存取權限的行為
  2. 作為一項一般規則，由應用程式產生的處理程序，應以完成該任務所需的最小權限執行，而非更大的特權權限
  3. 應用程式使用者應具有盡可能少的權限，即完成其業務所需的必要權限
  4. 開發人員應實施角色存取控管，並在「預設拒絕」情況下，依特定情境開放

故障時的安全性

闡述關於應用程式在例外狀況發生時，應該如何呈現的問題，所有異常都應以安全的方式處理。

  1. 除非使用者已明確接收到應用程式某個部分的權限，否則應拒絕他們存取
  2. 所有動作都應具有確定的結果，並且必須使用通用錯誤訊息處理異常
  3. 每個程式碼區塊應該只有三個確定的結果：
    • 如果使用者具有權限，則執行動作行為
    • 如果使用者沒有權限，則不執行動作行為
    • 如果發生例外，則回覆動作並顯示錯誤訊息
  4. 開發人員應實施強大的錯誤處理，為了確保安全性，應於出現異常時使用通用錯誤訊息。
  5. 確保系統在發生故障後處於安全狀態

強大的錯誤檢查

這是一種確保機敏資料，不會透過錯誤訊息洩漏的做法。

當攻擊者輸入一段會造成伺服器崩潰的字段時，伺服器回傳了一個包含程式碼推疊追蹤的例外處理頁面，這使得攻擊者掌握了應用程式使用的框架、資料庫連線、部分程式碼等資訊

為了防止此項漏洞，開發人員應符合以下原則

  1. 當例外錯誤發生時，應盡可能少的向使用者提供資訊，且使用通用錯誤訊息
  2. 應用程式應以可控且安全的方式關閉
  3. 切勿洩漏機敏資訊，如:推疊追蹤、內部IP、使用者資訊或資料庫資訊等
  4. 通常會將錯誤訊息寫入日誌檔，以供系統管理者進一步分析
  5. 確保系統捕獲所有可能的錯誤，以確保應用勝持續進行

不安全的直接物件引用 (IDOR)

應用程式根據使用者提供的輸入，並允許使用者存取物件時，攻擊者可以繞過授權要求，並直接存取系統中的資源。

範例1：登入頁面攻擊者替換查詢使用者ID，任意存取其他人的機敏資訊、私人訊息、檔案或其他資源等，而無須授權檢查。

範例2：如在應用程式中發出的任何請求，而後端API完全不對此進行授權檢查，即會發生此不安全的直接物件引用漏洞。

為了防止此項漏洞，開發人員應符合以下原則

  1. 開發人員應確保行動裝置呼叫的後端 API 對相關端點採取適當的存取控制
  2. 對不同授權等級的使用者進行單元測試檢驗

7. OWASP Web Top 10 2021

OWASP是一個資安界聞名的國際非營利組織。而該組織大約每三年會公布一次Web領域前十大風險類別，供各界參考。

2021年版的Top 3分別是：

  • A01 - Broken Access Control (權限控制失效)
  • A02 - Cryptographic Failures (加密機制失效)
  • A03 - Injection (注入式攻擊)

想瞭解更多有關 OWASP Web Top 10 的資訊可以參考 OWASP Top 10 2021 介紹 OWASP Top 10台灣分會翻譯過的資訊，感謝他們。

若以 A03 - Injection (注入式攻擊) 舉例，這個類型底下有許多弱點：

  • CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’, 俗稱XSS)
  • CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
  • CWE-77: Improper Neutralization of Special Elements used in a Command (‘Command Injection’)
  • …

這一類風險的核心改善措施是 對任何外部輸入的資料都需經過驗證」。

8. 結論

本文深入探討了Web應用程式的全面安全性，從開發、測試到部署，介紹了防範常見網絡攻擊的方法。通過實施安全編碼實踐、使用CSRF令牌、配置內容安全策略（CSP）以及進行持續的安全測試和監控，我們可以有效地保護應用程式免受各種威脅。最終，建立全面的安全意識和遵循最佳實踐是確保Web應用程式安全的關鍵。

9. 附錄

參考文獻和資源

  1. ChatGPT
  2. Secure Code Warrior

腳註

Blogging, Tutorial
Web Secure
本文章以 CC BY 4.0 授權