分類
CISSP

最有可能導致數據洩露的針對智能卡(smart cards)的攻擊

https://ithelp.ithome.com.tw/upload/images/20210925/201321603Nk48YiIrz.jpg
-側信道攻擊

側信道攻擊(Side-channel attack)
只需在設備或系統附近放置天線、磁探頭或其他傳感器,即可利用側信道。這允許攻擊者測量功耗、電壓波動或其他側信道,例如溫度或聲音。側信道攻擊可用於從智能卡等設備中提取密鑰。在現實世界中,這允許攻擊者加載或重置餘額並提取或重置設備 PIN。(半工程)
通過從物理密碼系統洩漏信息而啟用的攻擊。可以在側信道攻擊中利用的特徵包括時間、功耗以及電磁和聲發射。
來源:NIST 術語表
在 計算機安全中, 旁道攻擊 是基於從 計算機系統的實施中獲得的信息的任何攻擊 ,而不是實施算法本身的弱點(例如 密碼分析 和 軟體錯誤)。時間信息、功耗、 電磁 洩漏甚至 聲音 都可以提供額外的信息來源,可以加以利用。
資料來源:維基百科

內容可尋址內存 (CAM) 表溢出攻擊(Content addressable memory (CAM) table overflow attack)
當 CAM 表溢出時,交換集線器可能會降級為集線器以通過向所有端口發送幀來保持可用性。這會導致中間人惡意嗅探。
CAM 表溢出攻擊是針對網絡交換機執行的惡意行為,其中大量虛假 MAC 地址被發送到交換機。這種數據洪流導致交換機轉儲其 CAM 數據庫表中的有效地址,以試圖為虛假信息騰出空間。在這之後,交換機的默認行為是向所有端口廣播正常的私有消息。
資料來源:CbtNuggets

竊聽攻擊(Wiretapping Attack)
竊聽是對電話、電報、蜂窩、 傳真 或基於互聯網的通信進行的秘密電子監控 。
竊聽是通過在有問題的線路上放置一個非正式地稱為錯誤的監視設備或通過其他通信技術中的內置機制來實現的。
執法官員可以利用現場監控或錄音。數據包嗅探器——用於捕獲在網絡上傳輸的數據的程序——是一種常用的現代竊聽工具。各種其他工具,例如竊聽木馬,用於不同的應用程序。
資料來源:TechTarget

背負式攻擊(Piggyback attack)
一個 背馱式攻擊 是一種活化形式 竊聽 當攻擊者獲得通過活動的間隔訪問系統中的其他用戶的合法連接。它也被稱為“線間攻擊”或“背負式進入竊聽”。
在安全方面,捎帶指的是當某人與另一個被授權進入限制區域的人一起標記時,該術語 在此上下文中適用於 計算機網路
資料來源:維基百科

參考
了解側信道攻擊
ARP 和 CAM 表
背負式攻擊
保護圖片存檔和通信系統 (PACS):醫療保健行業的網絡安全

資料來源: Wentz Wu QOTD-20210811

分類
CISSP

區塊加密法工作模式

密碼學中,區塊密碼工作模式(mode of operation)允許使用同一個區塊密碼密鑰對多於一塊的資料進行加密,並保證其安全性。[1][2] 區塊密碼自身只能加密長度等於密碼區塊長度的單塊資料,若要加密變長資料,則資料必須先被劃分為一些單獨的密碼塊。通常而言,最後一塊資料也需要使用合適填充方式將資料擴充到符合密碼塊大小的長度。一種工作模式描述了加密每一資料塊的過程,並常常使用基於一個通常稱為初始化向量的附加輸入值以進行隨機化,以保證安全[1]

工作模式主要用來進行加密和認證[1][3] 對加密模式的研究曾經包含資料的完整性保護,即在某些資料被修改後的情況下密碼的誤差傳播特性。後來的研究則將完整性保護作為另一個完全不同的,與加密無關的密碼學目標。部分現代的工作模式用有效的方法將加密和認證結合起來,稱為認證加密模式[2]

雖然工作模式通常應用於對稱加密[2],它亦可以應用於公鑰加密,例如在原理上對RSA進行處理,但在實用中,公鑰密碼學通常不用於加密較長的資訊,而是使用結合對稱加密和公鑰加密的混合加密方案[1]

資料來源:https://zh.wikipedia.org/wiki/%E5%88%86%E7%BB%84%E5%AF%86%E7%A0%81%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F

分類
CISSP

DNS 服務器之間的區域傳輸(Zone transfer)

https://ithelp.ithome.com.tw/upload/images/20210922/20132160vQfp8cj6DA.jpg
-防火牆接口和區域
防火牆通常以兩種方式調解網絡流量:基於上下文和基於區域。傳統的基於上下文的方法也稱為基於上下文的訪問控制 (CBAC)。

基於區域的防火牆(Zone-based Firewalls)
防火牆包含幾個網絡接口,可以配置或分配給區域。安全區域或簡稱區域是共享相同安全要求的防火牆接口的集合。區域之間的流量由防火牆策略控制。有關更多信息,請參閱防火牆接口、區域和層

區域對(Zone Pairs)
區域對可以定義為一個方向上兩個區域的配對。然後將防火牆流量策略應用於區域對。防火牆流量策略在區域之間單向應用。雙向流量需要兩個區域對。但是,如果使用狀態檢查,則不需要第二個區域對,因為由於檢查而允許回复流量。
資料來源:OmniSecu

基於上下文的防火牆(Context-based Firewalls)
所述的ACL提供流量過濾和保護,直到傳輸層,同時在另一方面,CBAC提供高達應用層相同的功能。在 CBAC 配置的幫助下,路由器可以充當防火牆。
資料來源:GeeksForGeeks

基於上下文的訪問控制 (CBAC) 根據應用層協議會話信息智能過濾 TCP 和 UDP 數據包,可用於 Intranet、Extranet 和 Internet。
資料來源:黑羊網絡(BlackSheepNetworks)

Cisco IOS® 防火牆功能集的基於上下文的訪問控制 (CBAC) 功能會主動檢查防火牆後面的活動。CBAC 通過使用訪問列表(與 Cisco IOS 使用訪問列表的方式相同)指定需要允許進入的流量以及需要釋放的流量。但是,CBAC 訪問列表包括 ip inspect 語句,允許檢查協議以確保在協議進入防火牆後面的系統之前它沒有被篡改。
資料來源:思科

DNS 區域(DNS Zones)
DNS 命名空間是按層次結構或樹組織的 DNS 域名的邏輯結構。DNS 區域是 DNS 命名空間的一部分的管理結構。DNS 區域文件是區域的存儲庫。
主 DNS 服務器託管一個可寫區域,該區域可以傳輸到一個或多個輔助 DNS 服務器。輔助 DNS 服務器上的副本或副本通常是只讀的。但是,副本可以是可寫的,例如 Microsoft AD 集成的 DNS;這取決於供應商的實施。
主 DNS 服務器和輔助 DNS 服務器之間的區域傳輸使用 TCP 端口 53。它可以定期或基於通知進行。為了安全起見,主 DNS 服務器可能會維護一個輔助 DNS 服務器的白名單。
DNS 客戶端也稱為 DNS 解析器,它使用 UDP 端口 53 向 DNS 服務器發送遞歸 DNS 查詢。然後 DNS 服務器發出多個非遞歸或迭代查詢來解決來自 DNS 客戶端的查詢。
https://ithelp.ithome.com.tw/upload/images/20210922/20132160jEy54XJ5Zp.jpg
-DNS 命名空間和區域

參考
域名系統(維基百科)
DNS區域傳輸
DNSSEC – 它是什麼以及為什麼重要?
基於區域的防火牆基礎知識
網絡安全區
使用區域(紅帽)
區域對
基於上下文的訪問控制
基於上下文的訪問控制 (CBAC)
Cisco IOS 防火牆功能集和基於上下文的訪問控制
基於上下文的訪問控制 (LDAPWiki)

資料來源:Wentz Wu QOTD-20210810

分類
CISA

SMART原則

SMART原則目標管理中的一種方法。目標管理的任務是有效地進行成員的組織與目標的制定和控制以達到更好的工作績效,由管理學大師彼得·杜拉克於1954年首先提出。SMART原則便是為了達到這一目的而提出的一種方法,目前在企業界有廣泛的應用。它的首次出現被認為是在1981年12月發行的《管理評論》(Management Review)上(由George Doran、Arthur Miller和James Cunningham編著)。[1]

SMART原則中的「S」、「M」、「A」、「R」、「T」五個字母分別對應了五個英文單詞:Specific(明確)、Measurable(可衡量)、Achievable(可達成)、Relevant(相關)和Time-bound(有時限)。

資料來源:https://zh.wikipedia.org/wiki/SMART%E5%8E%9F%E5%88%99

分類
CISSP

資產生命週期(Asset Lifesysle)

分類
CISSP

DNS 安全擴展 (DNSSEC)

https://ithelp.ithome.com.tw/upload/images/20210915/20132160uMqakJgDrS.jpg
-DNSSEC 資源記錄(來源:InfoBlox
DNSSEC使用數字簽名確保DNS 數據的完整性,而 DNS over HTTPS (DoH) 或 DNS over TLS (DoT) 保護機密性。
以下是一些最重要的 DNSSEC 資源記錄 (RR):
. DS(委託簽名者)
. DNSKEY(DNS 公鑰)
. RRSIG(資源記錄簽名)
https://ithelp.ithome.com.tw/upload/images/20210915/201321608gOmwhiDvP.png
DS(委託簽名者)
DS RR 包含子區域 KSK 的哈希值,可用作某些具有安全意識的解析器中的信任錨,並為 DNS 服務器中的簽名子區域創建安全委派點。如圖 22.1 所示,父區域 corpxyz.com 中的 DS RR 包含子區域 sales.corpxyz.com 的 KSK 的哈希值,而子區域 sales.corpxyz.com 的 DS 記錄又包含其子區域的 KSK 的哈希值, nw.sales.corpxyz.com。
-資料來源:InfoBlox

DNSKEY(DNS 公鑰)
當權威名稱服務器對區域進行數字簽名時,它通常會生成兩個密鑰對,一個區域簽名密鑰 (ZSK) 對和一個密鑰簽名密鑰 (KSK) 對。
名稱服務器使用ZSK 對的私鑰對區域中的每個 RRset 進行簽名。(RRset 是一組具有相同所有者、類別和類型的資源記錄。)它將 ZSK 對的公鑰存儲在 DNSKEY 記錄中。
然後名稱服務器使用KSK 對的私鑰對所有 DNSKEY 記錄進行簽名,包括它自己的記錄,並將相應的公鑰存儲在另一個 DNSKEY 記錄中。
因此,一個區域通常有兩個 DNSKEY 記錄;保存 ZSK 對公鑰的 DNSKEY 記錄,以及 KSK 對公鑰的另一個 DNSKEY 記錄。
資料來源:InfoBlox

R RSIG(資源記錄簽名)
一個簽名區域有多個 RRset,每個記錄類型和所有者名稱一個。(所有者是RRset 的域名。)當權威名稱服務器使用ZSK 對的私鑰對區域中的每個RRset 進行簽名時,每個RRset 上的數字簽名都存儲在RRSIG 記錄中。因此,簽名區域包含每個 RRset 的 RRSIG 記錄。
資料來源:InfoBlox

參考
DNSSEC – 回顧
DNSSEC – 它是什麼以及為什麼重要?
域名系統安全擴展
DNSSEC 的工作原理
DNSSEC:它的工作原理和主要考慮因素
RFC 4033:DNS 安全介紹和要求
RFC 4034:DNS 安全擴展的資源記錄
RFC 4035:DNS 安全擴展的協議修改
基於 HTTPS 的 DNS
如何配置 DoT/DoH
DNSKEY 資源記錄

資料來源: Wentz Wu QOTD-20210809

分類
CISSP

Risk Treatment

分類
Cissp-WentzWu

受保護的內容: 20210914

這篇內容受到密碼保護。如需檢視內容,請於下方欄位輸入密碼:

分類
CISSP

系統和應用軟體提供安全保證- 通用標準(Common Criteria)

https://ithelp.ithome.com.tw/upload/images/20210913/20132160wBxk3wtKD2.jpg
-通用標準評估
TCSEC 在 DoD 中用於評估受信任的計算機系統。它適用於整個計算機系統,而不適用於特定的軟體組件。此外,它已經過時了。
可信計算機系統評估標準 ( TCSEC ) 是 美國政府國防部 (DoD) 標準,它為評估 內置於計算機系統中的計算機安全控制 的有效性設定了基本要求 。TCSEC 用於評估、分類和選擇被考慮用於處理、存儲和檢索敏感或機密資訊的計算機系統 。(維基百科
CMMI 是一種基於過程的模型,用於評估組織在軟體開發、採購或服務交付方面的能力成熟度。它不適用於軟體本身。
SOC 2 Type II 是關於服務組織中與安全性、可用性、處理完整性、機密性或隱私相關的控制的報告。這些報告旨在滿足廣大用戶的需求,這些用戶需要有關服務組織用於處理用戶數據和服務的系統的安全性、可用性和處理完整性相關的控制的詳細信息和保證。這些系統處理的信息的機密性和隱私性。(AICPA)

參考
批准的保護配置文件
認證產品
Windows 10:內部版本 10.0.15063(也稱為版本 1703)

資料來源: Wentz Wu QOTD-20210808

分類
Information Security

OWASP Top 10-A01:2021 – 權限控制失效

A01:2021 – 權限控制失效

對照因素

可對照 CWEs 數量最大發生率平均發生率最大覆蓋範圍平均覆蓋範圍平均加權弱點平均加權影響出現次數所有相關 CVEs 數量
3455.97%3.81%94.55%47.72%6.925.93318,48719,013

概述

從第五名晋升至第一名,94% 的應用程式都對中斷的存取控制進行了某種形式的測試。著名 的 CWE 包括 CWE-200:將敏感資訊暴露給未經授權的演員CWE-201:通過發送資料 和 CWE-352暴露敏感資訊:跨站請求偽造

描述

存取控制強化政策,使得用戶不能採取在預期權限之外的行動。故障通常會導致未經授權 的資訊洩露、修改或破壞所有資料,或執行超出用戶限制的業務功能。 常見的存取控制弱點包括:

  • 通過修改URL、內部應用程式狀態或HTML頁面,或僅使用自定義API攻擊工具來繞過存取控制檢查。
  • 容許主鍵被更改為其他用戶的記錄,允許查看或編輯其他人的帳戶。
  • 特權提升。未登入即成為用戶,或以用戶身份登入即成為管理員。
  • 中繼資料操作,例如重放或篡改JSON網站令牌(JWT)之存取控制令牌,或被操縱以提升特權或濫用 JWT失效的cookie或隱藏欄位。
  • CORS錯誤配置允許未經授權的API存取。
  • 以未經身份驗證的用戶身份強制瀏覽已驗證的頁面或以標準用戶身份存取特權頁面。 存取缺少存取控制的API以進行POST、PUT 和 DELETE操作。

如何預防

存取控制僅在受信任的伺服器端代碼或無伺服器的API有效果,攻擊者無法修改這裏的存取控制檢查或中繼資料。

  • 除公開資源外,以拒絕為預設值。
  • 一次性地建置存取控制機制,之後在整個應用程式中重複使用它們,包括最大限度地減少使用CORS。
  • 模型的存取控制措施應該強化記錄所有權,而不是讓用戶可以創建、讀取、更新或刪除任何記錄。
  • 獨特的應用程式業務限制要求應由領域模型予以強化。
  • 停用Web伺服器目錄列表,並確保檔案中繼資料(例如,.git)和備份檔案不在web根目錄中。
  • 記錄存取控制失效,並在適當的時間警示管理員(例如,重覆性失效)。
  • 對API和控制器存取進行流量限制,以最小化自動攻擊工具所帶來的損害。
  • JWT令牌於登出後,在伺服器端應使其失效。

開發人員和QA品保人員應納入與功能有關之存取控制的單元和整合測試。

攻擊情境範例

情境 #1: 應用程式在存取帳戶資訊的SQL呼叫中使用未經驗證的資料:

pstmt.setString(1, request.getParameter(“acct”));

ResultSet results = pstmt.executeQuery( );

攻擊者只需修改瀏覽器的“acct”參數即可發送他們想要的任何帳號。如果沒有正確驗證, 攻擊者可以存取任何用戶的帳戶。

https://example.com/app/accountInfo?acct=notmyacct

情境#2: 攻擊者僅強迫瀏覽某些目標網址。存取管理頁面需要管理員權限。

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

如果未經身份驗證的用戶可以存取任一頁面,那就是一個缺陷。 如果一個非管理員可以存取管理頁面,這也是一個缺陷。

參考

對應的CWE列表

CWE-22 不當限制受限目錄的路徑名稱(路徑遍訪)

CWE-23 相對路徑遍訪

CWE-35 路徑遍訪: ‘…/…//’

CWE-59 檔案存取前不當的路徑解析 (‘連結指向’)

CWE-200 將敏感資訊曝露給未經授權的行為者

CWE-201 經由發送的資料曝露敏感資訊

CWE-219 在網站根目錄下存放敏感資料

CWE-264 權限、特權和存取控制(不應再使用)

CWE-275 權限問題

CWE-276 不正確的預設權限

CWE-284 不當的存取控制

CWE-285 不當的授權

CWE-352 跨站請求偽造 (CSRF)

CWE-359 將私有的個人資訊曝露給未經授權的行為者

CWE-377 不安全的暫存檔案

CWE-402 私有資源輸入新領域(“資源洩漏”)

CWE-425 直接請求(“強制瀏覽”)

CWE-441 意外代理或中介(“困惑的代理”)

CWE-497 將敏感系統資訊曝露給未經授權的控制領域

CWE-538 將敏感資訊插入外部可存取的檔案或目錄

CWE-540 原始程式中包含敏感資訊

CWE-548 透過列示目錄而曝露資訊

CWE-552 外部各方可存取的檔案或目錄

CWE-566 通過用戶控制的 SQL 主鍵繞過授權

CWE-601 URL重新導向至不受信任的站台(“開放而不受限的重新導向”)

CWE-639 通過用戶控制的金鑰繞過授權

CWE-651 曝露包含敏感資訊的WSDL檔案

CWE-668 資源曝露於錯誤領域

CWE-706 使用被不正確解析的名稱或參考

CWE-862 缺少授權

CWE-863 不正確的授權

CWE-913 不當的動態管理的代碼資源控制

CWE-922 不安全儲存的敏感資訊

CWE-1275 具有不當SameSite屬性設定的敏感Cookie

資料來源:https://github.com/ninedter/Top10/blob/2021-zhtw/2021/docs/A01_2021-Broken_Access_Control.zh_TW.md