概述

討論一些應用程式常見漏洞類別：

建議

• Clickjacking
  發生在攻擊者使用 iframe 誘使使用者在打算點選頁面時、按鈕或連結時，使使用者在只有使用者有權存取的頁面上執行敏感操作。

  • 問題範例
    攻擊者現在可以在其網站上包含一個隱藏的 iframe：

    iframe src = "https://hide" style = "opacity：100"></iframe>
    ``
    

  • 修正方法
    設置以下 HTTP 回應標頭(Request Header)：

    -Frame-Options：DENY
    ``
    

  • 參考資料
    https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

• HTTP 安全標頭
  瀏覽器正在嘗試幫助解決Web應用程式中常見的安全問題。
  並考慮向後兼容性，因為Internet上仍有一些既有格式的網站可能有相容性的問題。
  使用HTTP安全標頭可以選擇啟用瀏覽器中的一些新安全功能，以充分利用現代瀏覽器的安全性。

  • 問題範例
    幾乎所有的Web應用程式都從 HTTP->HTTPS 重定向，從而使使用者在存取您的網站時不必在URL的開頭鍵入 https：//。
    但如果使用者已經在站點上取得了 Session，則瀏覽器可能會在重定向前的第一個HTTP請求上發送一些敏感訊息。
  • 修正方法
    在專案的早期階段添加標題，並確保選擇對內容安全策略友好的現代前端技術。
  • 風險等級
    添加安全標頭是基本的安全措施，Mozilla等組織要求其所有應用程式都必須實現它們。
  • 參考資料
    Mozilla在這裡有一個很好的Web安全指南參考，其中包括許多有關安全標頭的訊息：
    https://infosec.mozilla.org/guidelines/web_security

• 防止XSS
  XSS或跨站點Script是常見的Web應用程式漏洞。
  該漏洞使攻擊者可以通過向應用程式中註入JavaScript或HTML來修改應用程式的前端行為，從而更改惡意行為的預期行為。
  XSS漏洞可能它們可用於竊取敏感訊息，例如憑證，Session Token或信用卡資料。
  它可以用來繞過防火牆並存取內部網路，例如辦公網路，因為它允許攻擊者的程式碼在受害者的瀏覽器中運行，而該瀏覽器很可能在辦公室的計算機上運行或通過VPN連接。
  或通過注入瀏覽器利用程式碼直接攻擊瀏覽器，或者如最近所看到的那樣，通過加密貨幣挖掘程式碼注入到無辜的網站中來竊取計算能力來挖掘加密貨幣。

  • 問題範例
    通常，問題是由頁面中包含的輸入字段或URL參數引起的，例如：

    ttps://www.application.com/newuser?name=<script>alert(1)</script>
    ``
    果該參數最終被應用程式視為HTML，則會彈出一個警告框，以證明我們可以注入JavaScript。
    

  • 修正方法
    預防XSS是一個範圍很大的主題：
    - 選擇預設情況下支持輸出程式碼的前端框架。
    - 清理來自使用者和其他應用程式的所有輸入，並拒絕意外的輸入。
    - 實施不允許使用JavaScript的內容安全策略。
    解決此問題的第一個也是最好的方法是使用預設情況下輸出程式碼及轉義資料的前端框架，這使任何開發人員都很難犯不處理惡意輸入的錯誤。
    有更多的框架具有很好的預設XSS預防功能，使用了這兩個框架，它們已得到Google和Facebook等大公司的支持和使用。
    可選的前端框架很多，因為考慮到這些缺陷，在設計XSS漏洞時將更加困難：
    - https://angular.io/guide/security#xss
    - https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks
    請確保您的應用程式清理了所有傳入的資料。
    這需要在伺服器上完成才能使其生效。
    資料可以來自許多來源，包括但不限於使用者直接輸入或來自其他應用程式的資料。
    例如，如果您希望輸入電話號碼，請確保程式驗證應用程式僅接受預期的資料，例如數字，破折號和國家程式碼的+。

    有一些函式庫可以提供幫助，例如Active Record Validation等。
    我們可以實現一種針對所有現代瀏覽器都支持的XSS問題的保護機制。
    內容安全策略可以有效地限制XSS漏洞的影響，即使這些漏洞在您的應用程式中發生，即使在您輸出程式碼資料並清理輸入後也是如此。

    通過精心設計CSP，我們可以告訴瀏覽器哪些Script可以運行，哪些Script不允許運行。
    我們可以限制允許應用程式從中載入JavaScript資源的位置，並且我們可以禁止任何行內JavaScript。
    通過利用XSS漏洞注入的惡意JavaScript通常最終會內嵌在HTML文檔中，而不是在外部.js文件中，因此，如果我們指示瀏覽器不允許使用行內JavaScript，則可以避免許多常見的XSS漏洞。

    僅允許應用程式所在域中的Script文件的策略範例如下所示：
    Content-Security-Policy:："script-src'self'"

  • 風險等級
    XSS漏洞非常普遍，根據情況和應用情況，其構成中等到高風險。
    這是一個漏洞類別，需要應用程式安全團隊提供大量資源來處理，除非該應用程式設計良好，並且我們想在應用程式中消除該漏洞類別。

  • 參考資料

    • https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
    • https://csp.withgoogle.com/

• 防止SQL注入
  SQL注入是一個古老的漏洞類別，它使攻擊者能夠更改應用程式的SQL查詢，以執行開發人員未計劃的其他操作。
  出現此問題是由於資料和程式碼之間缺乏分隔，使攻擊者無法輸入資料r查詢的邏輯。
  即使在現代Web應用程式中，仍然存在SQL注入漏洞，這會導致資料丟失，身份驗證繞過和伺服器受損。

  發現甚至不使用傳統關係資料庫的應用程式也容易受到SQL注入的攻擊。
  如果使用使用者輸入來構建資料庫查詢，則攻擊者可能會更改正在進行的查詢並繞過身份驗證，從而意外存取資料或執行遠程程式碼。

  保護資料免受攻擊者對於任何資料驅動的公司而言都是至關重要的，保護我們的Web應用程式免受SQL注入是防止資料被盜的非常重要的部分。
  多年來發現的許多漏洞是由Web應用程式中的SQL注入引起的，從而導致伺服器受到完全破壞或對資料庫中所有資料的存取。

  • 問題範例
    該漏洞都使我們能夠存取和提取應用程式資料庫的所有內容。
  • 修正方法

    • 關聯資料庫(PostgreSQL等)
      所有SQL查詢都應該是參數化查詢，具體語法會根據所使用的技術堆疊而有所不同：
      SELECT * FROM users where username like '%'
      限制資料庫使用者的權限。
      永遠不應以資料庫管理員或root/admin使用者身份運行應用程式SQL查詢。
      使用對象關係映射器(ORM)可以幫助您安全地構建查詢，還可以減輕編寫原始SQL查詢的麻煩。

    • NoSQL資料庫(MongoDB，CouchDB等)

      幾乎相同的原理適用於保護應用程式免受noSQL注入：

      清理查詢中使用的使用者輸入。
      根據正則表達式或白名單檢查輸入的類型(字串，位元組等)以及所需的格式。
      將資料庫使用者的權限限製到最小。

  • 風險等級
    SQL注入漏洞的嚴重性從高到嚴重不等，具體取決於應用程式和上下文。例如，身份驗證提供程式中的SQL注入將是一個嚴重漏洞，因為它可能導致所有使用者資料受到損害，並有可能繞過存取控制。
  • 參考資料
    • https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
    • https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html

• 防止跨站請求偽造
  跨站點請求偽造攻擊使攻擊者可以在經過身份驗證的使用者的上下文中在應用程式中執行操作。
  通過濫用cookie的工作方式，如果應用程式的身份驗證是基於cookie的(例如，Session Cookie被儲存並隨每個請求一起發送)，則攻擊者可以設置一個網站，例如通過iframe，圖像或通過自動發布一些表單資料，瀏覽器將發送使用者的Cookie。
  此攻擊是從www.malicious.com到不同來源進行的，因此，由於“同源規則"，攻擊者將無法讀取跨域請求的回應。
  但是，如果應用程式僅需要Session Cookie，並且不驗證請求是否來自預期域，則成功攻擊就沒有必要了。

  當使用者瀏覽有趣的貓圖片而沒有任何懷疑時，攻擊可能會在惡意網站的後台發生。
  可利用的行為可以是應用程式允許的任何事情，例如更改密碼，更改收貨地址，刪除使用者或可能用於攻擊者利益的其他任何事情。

  攻擊通常針對單個使用者帳戶，但是如果該使用者帳戶是應用程式的管理員，則業務後果可能非常嚴重。

  • 問題範例

    我們用於網路團隊進行部署的內部遺留系統過去很容易受到跨站點請求偽造的攻擊。由於兩個缺陷的結合，網路外部的攻擊者有可能觸發部署，甚至在伺服器上獲得程式碼執行。

  • 修正方法

    有幾種解決此問題的策略，這在某種程度上取決於應用程式的體系結構。
    以下是最常用的主要策略，被視為解決此問題的標準方法：

    • 通過HTTP標頭進行身份驗證
      一些身份驗證API使用“身份驗證：承載<Token到此處>"標頭進行身份驗證。需要身份驗證標頭才能成功的請求不容易受到CSRF攻擊。

    • CSRF Token
      這是最常見和公認的保護機制。它通過要求每個表單提交和執行操作的請求來在提交的資料中包含隨機CSRF Token的方式工作。由於此Token是由伺服器設置和儲存的，並且與使用者的Session相關聯，因此攻擊者將無法存取或猜測它。這樣可以防止CSRF攻擊成功，因為伺服器應拒絕任何沒有有效Token的請求。
      首先要確保您的應用程式正確使用了HTTP GET和POST動詞，請參閱http://guides.rubyonrails.org/security.html#csrf-countermeasures

      接下來，您應該查看您的Web應用程式框架，以了解它們是否支持CSRF Token。大多數框架，例如上面提到的Ruby on Rails，都將具有內置支持以輕鬆添加CSRF Token或支持實現它的庫。以下是NodeJS和Golang的兩個流行選項：
      - https://github.com/expressjs/csurf
      - https://github.com/utrack/gin-csrf

    • 檢查來源/引薦標頭_

      這是可以用來防止CSRF攻擊的另一種方法。此方法依賴於檢查請求的"Origin"標頭，以確保該請求標頭來自承載應用程式的來源，而不是惡意域。
      只允許瀏覽器設置"Origin"標頭，以防止惡意應用程式對其進行欺騙。
      它不像使用CSRF Token那樣，因為瀏覽器不必(但可以)設置RFC-6454中指定的原始標頭。

      通常將此檢查與檢查請求的"referer"標頭結合在一起。
      "引薦來源"標頭還由瀏覽器專門設置，並且包含請求所源自的URL或域。
      應用程式可以檢查此標頭是否設置為正確的域，以確保請求來自使用者Session，而不是來自惡意域。

    • Samesite Cookies
      這是防止CSRF的機制。
      它是一種新的瀏覽器功能，允許使用標記來標記cookie，該標記控制從第三方站點發起的請求是否將包含cookie。

      有兩種模式：嚴格和寬鬆。
      嚴格模式可防止瀏覽器針對任何請求發送cookie跨域。在登錄使用者點選連結返回到應用程式中經過身份驗證的頁面的情況下，這可能會帶來負面影響，因為將不會發送Cookie，並且使用者需要重新進行身份驗證。
      鬆散模式可防止這種情況，並允許GET請求與cookie一起發送。使用任何其他HTTP動詞的請求都不會隨Cookie一起發送。如果應用程式適當地使用了HTTP動詞，那麼通常就足以防止CSRF攻擊，因為該應用程式不應使用GET請求在應用程式中執行任何操作。

        -設置寬鬆模式：`Set-Cookie：CookieName = CookieValue; SameSite = Lax;`
        -設置嚴格模式：`Set-Cookie：CookieName = CookieValue; SameSite =嚴格;`
      

  • 風險等級
    上例顯示了嚴重的CSRF漏洞。
    根據應用程式的不同，CSRF漏洞的影響範圍可能從低到嚴重。
    CSRF攻擊通常是針對性的，需要針對特定應用進行定制，但是在常用函式庫和框架中也存在CSRF漏洞，攻擊者可以利用這些漏洞同時將多個站點作為目標。

  • 參考

    • https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
    • https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/

• 憑證洩漏
  應用程式開發需要與越來越多的服務整合。
  這要求開發人員處理許多機密訊息：資料庫憑證，API Token，oauth機密訊息等。
  這些訊息應具有高熵，每個服務和每個環境都是唯一的，從而導致需要管理大量機密訊息。
  這些通常最終儲存在配置文件中，然後意外地將其檢入可公開存取的雲託管資料庫中您喜歡的版本控制系統，並因此將其檢入攻擊者的手中。

  機密是出於某種原因而機密的，通常可以提供對許多資料，計算資源或特權帳戶的存取。
  因此，至關重要的是我們要處理e的機密很好，並且使意外洩漏的可能性盡可能小。

  • 問題範例

    到Github的憑證洩漏是業內常見且麻煩的問題。
    這可以使惡意行為者存取內部系統，資料，API等。

    • 修正方法
      開發應用程式時，最佳做法是從環境變量中載入機密。
      • 將憑證儲存在運行程序的記憶體位置中，這意味著伺服器上的其他沒有權限的使用者帳戶將無法存取憑證。
      • 將機密與您的應用程式常規配置文件分開，這些文件經常被檢入版本控制系統中。
        開發應用程式時，在本地運行應用程式之前，使用.env文件儲存機密並將其載入到環境中。
      • 將機密集中儲存在安全的地方。
      • 應用程式安全團隊擁有監視原始碼資料庫中機密的工具，但該機制僅應作為最後一道防線，為避免憑證洩漏。
      • 憑證洩漏很關鍵，因為它們通常會授予系統的高級別存取權限，並可能導致資料和系統受損。