Information Security Management

資安管理 OWASP Top 10 (1)

基本介紹

教學目標

初步了解 OWASP Top 10 十大資安風險。

重點概念

首先開放網站應用程式安全專案 (The Open Web Application Security Project,OWASP) 每隔幾年就會匯整出十大網路資安的風險,在 2017 年 11 月 20 日則公佈最新版本,分別為:

  1. 注入攻擊 (Injection)
  2. 無效身份認證 (Broken Authentication)
  3. 敏感資料外洩 (Sensitive Data Exposure)
  4. XML 外部處理器漏洞 (XML External Entity,XEE)
  5. 無效的存取控管 (Broken Access Control)
  6. 不安全的組織設定 (Security Misconfiguration)
  7. 跨站攻擊 (Cross-Site Script,XSS)
  8. 不安全的反序列化漏洞 (Insecure Deserialization)
  9. 使用已有漏洞的元件 (Using Components with Known Vulnerabilities)
  10. 記錄與監控不足的風險 (Insufficient Logging & Monitoring)

接著其中相較於 2013 年主要新增 XML 外部處理器漏洞、不安全的反序列化漏洞和記錄與監控不足風險三大資安風險,主要與越來越多微服務的應用有關,因此當我們在快速提供服務的過程中,更需要許多跌謹的資安驗證和授權的程序,避免因為忽略而造成敏感資料的外洩。

XML 外部處理器漏洞

XML 外部處理器漏洞,主要是因為以 XML 為基礎的網路應用程式沒有管控好權限,直接處理 XML 語法的請求或上傳,此時攻擊者僅需要加入一個惡意的 XML 文件,就能夠鎖定 XML 處理器漏洞進行攻擊,進而導致資料外洩的風險。更進一步,目前 XML 訊息主要採用簡單物件存取協定 (Simple Object Access Protocal,SOAP) 簡化網路應用程式訊息傳遞的標準格式,此時若是採用 SOAP 1.2 之前版本的訊息交換格式,則預設皆有 XML 外部處理器漏洞的風險,因此容易遭受到阻斷式服務的攻擊。所以建議採用 SOAP 1.2 版本避免因為 XML 外部處理器漏洞的風險遭受到阻斷式服務的攻擊。

不安全的反序列化漏洞

不安全的反序列化漏洞主要是針對 Java 、 Node.js、…等平台常見的攻擊方式,簡單來說,序列化主要會將執行時的變數和程序物件轉換為可以儲存或傳輸形式的過程,形式主要有 JSON、XML 或二進位格式,反序列化則是將序列化形式轉換為記憶體變數和程序物件的相反過程,此時攻擊者若可以將資料進行反序列化,那將會對記憶體中的變數和程序物件產生影響, 之後將會導致遠端程式碼執行、重播攻擊、注入攻擊、特權升級攻擊、…等攻擊方式成功。所以建議針對任何序列化的物件落實完整性的檢查,像是數位簽章,以利防止惡意物件的建立或資料被篡改。

記錄與監控不足的風險

記錄與監控不足的風險主要是因為微服務快速興起,卻沒有針對應用程式進行記錄和監控,此時因為記錄和監控的不足,所以當資安事件發生時就無法立即處理與解決問題,同時讓攻擊者有機會更進一步攻擊系統。所以建議確保所有使用者登入、存取控制失敗和伺服器端輸入驗證失敗皆進行記錄,以利識別可疑或惡意的帳戶,並且保留足夠的時間允許延遲進行數位鑑識分析。

再來第一名注入攻擊,不僅只是 SQL 注入攻擊,更進一步包括作業系統、LDAP、SQL 、NoSQL 、… 等注入攻擊,當惡意程式語法輸入時,若沒有經過妥善的檢查和驗證將會造成資安的風險,所以建議使用安全的 API,或者使用參數化的介面,以及使用物件關係對應 (Object Relational Mapping,ORM) 工具。第二名無效身份認證,主要是因為網路應用程式必須進行身份認證和工作階段管理,此時若導入方式不正確,就有可能會讓攻擊者取得密碼、金鑰、工作階段存取令牌、…等暫時或永久取得使用者的身份資訊。所以建議在可能的情況下落實多因素的身份驗證機制,以利避免無效身份認證的攻擊成功。第三名敏感資料外洩,主要是因為有許多網路應用程式對於金融資訊、健康資料和個人資料的保護不足,若是被攻擊者取得,將能夠進行信用卡詐欺、身份竊取或其它犯罪行為。所以建議針對應用程式的處理、存儲或傳輸的資料進行分類,並且根據個人隱私法、監管機關的要求和業務的需求確定哪些資料是敏感性資料,以利進行額外的保護措施。

最後跨站請求偽造攻擊 (Cross-Site Request Forgery,CSRF) 沒有在 2017 年十大資安風險之一,同時許多開發框架和套裝軟體皆已經內建跨站請求偽造攻擊的風險防禦機制,但還是要特別小心僅慎,像是跨站攻擊雖然也有許多成熟的自動化掃描工具,能夠加速漏洞修補的速度,但是風險並沒有因此減少還是在十大資安風險之一。此外若是沒有針對開發框架和套件軟體進行安全的組態設定,則將會因為不安全的組態設定提高被攻擊的風險,此時必須定期做到系統更新與升,以利確保系統安全,避免攻擊者使用已有漏洞的元件進行攻擊。至於無效的存取控管,則僅能藉由嚴格的存取控管,以利避免攻擊者利用漏洞存取沒有經過授權的功能或查看敏感資料。同時授權使用者、群組和角色存取的功能也是許多套裝軟體解決方案基本的安全功能之一,所以存限控管會是資安管理的首要第一步,有完善的存限控管機制將能夠降低被攻擊的資安風險。

總結 OWASP Top 10 僅是風險框架,其會因為技術發展而持續進行變動,因為除了十大資安風險之外,針對企業和組織則還有許多更需要特別注意的資安風險,以利通透過稽核或法遵的檢查。至於下一步要如何開始進行,則可以參考「OWASP Top 10 - 2017 The Ten Most Critical Web Applications Security Risks」報告文件。

相關資源

資安管理 WebGoat (1)

基本介紹

教學目標

初步了解 WebGoat 平台有系統學習網站漏洞,以利進行後續資安管理。

重點概念

首先 WebGoat 平台主要是由 OWASP 研究開發的弱點測試平台,主要是以 J2EE 進行開發的網站,其中設計了大量的網站漏洞,同時一步一步引導使用者如何利用這些漏洞進行攻擊的方式,以利我們學習資安管理。

接著請先從 OWASP WebGoat 專案官方網站,下載「webgoat-container-7.1-exec.jar」檔案,下一步執行下述指令就能開啟 WebGoat 平台。

1
$ java -jar webgoat-container-7.1-exec.jar

再來開啟瀏覽器輸入「127.0.0.1:8080/WebGoat」網址,下一步輸入使用者帳號和密碼為「webgoat」進行登入 WebGoat 平台,此時畫面的右方為課程分類,中間為課程內容主要有顯示程式碼、解決方式、目標與目的和提示等功能。左方為 HTTP 請求的資料主要顯示 Cookies 和參數。

最後課程分類主要以攻擊方式的類別為主,總共有十六個類別,每個類別還有許多不同的攻擊手法,分別為:

  1. Access Control Flaws
  2. AJAX Security
  3. Authentication Flaws
  4. Buffer Overflows
  5. Code Quality
  6. Concurrency
  7. Cross-Site Scripting (XSS)
  8. Improper Error Handling
  9. Injection Flaws
  10. Denial of Service
  11. Insecure Communication
  12. Insecure Storage
  13. Malicious Execution
  14. Parameter Tampering
  15. Session Management Flaws
  16. Web Services

總結我們可以透過 WebGoat 平台將能夠有系統的學習利用網站漏洞進行攻擊的手法,唯有清楚知道如何駭客如何攻擊網站,才能夠進行網站防守,同時目前許多企業的解決方案皆還是以 J2EE 平台為主,此時我們要能夠因應不同的攻擊手法採取適當的設定,以利達到適當的資安管理。

相關資源

資安管理 SSL/TLS (2)

基本介紹

教學目標

初步了解 SSL/TLS 的資安風險和金鑰產生的流程。

重點概念

目前已知 SSL/TLS 有許多弱點可能會讓駭客遠端進行攻擊,弱點主要可以分為兩大類,分別為協定本身的弱點和特定工具的弱點,其中像是 SSL 3.0 和 TLS 1.0 已經證實有嚴重實作的缺陷會導致不安全,以及 OpenSSL 被發現有 heartbleed 漏洞,請參考下表。

CVE 編號 攻擊名稱 說明 解決方式
CVE-209-3555 TLS 端點可能支援不安全重新協商,此時有網路存取權的使用者就能夠將自己的流程加在客戶端傳給伺服器的流量之前執行惡意攻擊。 將客戶端和伺服器軟體升級到最新版本。
CVE-2011-3389 BEAST 當使用 CBC 模式加密時 TLS 1.0 產生的初始向量值是可以被預測,接著注入代理程式,再來監視取得密文之後,就能夠執行惡意攻擊,找出明文資料。 強制使用 TLS 1.1 以上的版本協定。
CVE-2012-4929 CRIME 伺服器執行具有壓縮機制的 TLS 1.2 之前的版本,就會容易受到惡意攻擊 停用 TLS 壓縮功能。
CVE-2013-0169 Lucky 13 當使用 CBC 模式加密時跨頻道的惡意攻惠會造成已知位置的資料被找出明文資料。 停用 CBC 加密方式。(OpenSSL 1.0.1d)
CVE-2013-2566 RC4 RC4 演算法中有許多位元組偏移,當知道機密資料位置,接著在相同的明文加密多次,就能找出明文資料。 停用支援 RC4 加密套件。
CVE-2013-3587 BREACH 網頁應用程式使用 HTTP 壓縮,並且經由 HTML 靜態機密回傳給客戶端時,就能夠執行惡意攻擊,找出明文資料。 停用 HTTP 壓縮功能。
CVE-2014-0160 heartbleed 當收到特製的請求之後,會導致洩露堆積記憶體中的機敏資料。 將客戶端和伺服器軟體升級到最新版本。(OpenSSL 1.0.1~1.0.1f)
CVE-2014-3566 POODLE 當使用 CBC 模式加密時 SSL 3.0 容易受到 Pading oracle 的惡意攻擊,找出明文資料。 停用 SSL 3.0。
CVE-2015-0400 Logjam 當系統支援 DH 群組小於 1024 位元時,就容易受到中間人 (Man In The Middle,MITM) 惡意攻擊。 強制使用 1024 位元以上的 DH 群組之大小。

接著駭客針對 SSL/TLS 攻擊主要破解憑證內容,以及依賴客戶端瀏覽器執行 JavaScript 代理程式,以利在 SSL/TLS 上產生所需要的請求,至於針對位元組偏移的攻擊,像是 RC4 和 Lucky 13 攻擊時會產生大量資料,所以實務應用較不切實際。此時為了防止駭客進行攻擊,所以加密組合的選擇就非常的重要,在 TLS 1.2 加密組合 (Cipher Suites) 的資訊主要有金鑰交換的方法、身分驗證的方法、對稱加密演算法、金鑰長度和模式和訊息驗證碼的演算法,在 RFC 5246 的技術標準中會列出基本的加密套件,此外我們也可以透過 OpenSSL 指令查看支援的加密套件。

查看 OpenSSL 支援的加密套件指令之範例

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
c:\Apache24\bin>openssl ciphers -v
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD
RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(256) Mac=SHA1
SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(256) Mac=SHA1
RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA384
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA384
RSA-PSK-AES256-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA1
DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1
SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(128) Mac=SHA1
SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(128) Mac=SHA1
RSA-PSK-AES128-CBC-SHA256 TLSv1 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA256
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA256
RSA-PSK-AES128-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA1
DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1

其中 Kx 為金鑰交換演算法、Au 為身份驗證機制,Enc 為對稱加密演算法和金鑰長度,Mac 為訊息驗證碼的演算法,像是 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 代表金鑰交換演算法為 DH、身份驗證機制為 RSA、對稱加密演算法為 AES、金鑰長度為 128 bits,訊息驗證碼的演算法為 SHA256。

再來 DH 金鑰交換演算法主要是允許雙方在公開通道上建立加密通道,其中 Pre-master Key 是由客戶端產生,接著由伺服器的公鑰加密之後,再來傳送給伺服器。其中 DH 公鑰,主要是由伺服器以憑證和伺服器金鑰交換訊息傳送給客戶端,其中金鑰類型又可分為靜態和短暫,所謂靜態公鑰主要是從伺服器的私鑰所衍生,因此可以在伺服器的憑證中找到,所謂短暫金鑰則是為每一個 SSL/TLS 工作階段而產生。此外因為 DH 金鑰交換演算法主要為匿名,因此無法進行身份驗證,所以我們會使用 RSA 進行身份驗證。若透過 RSA 進行協商時,客戶端和伺服器會向雙方傳送 256 bits 的亂數,其中前 32 bits 是由本機系統時間所產生,剩下的 224 bits來自虛擬亂數產器。接著客戶端會額外產生 368 bits 的亂數,再加上 16 bits 的 TLS 協定版本之後,總計 384 bits 就是 Pre-master Key ,因此 Pre-master Key 主要是使用伺服器的 RSA 公加密,再以客戶端金鑰交換訊息傳送,其中因為使用伺服器的公鑰加密代表此方法不提供轉送保密機制。當我們具備 Pre-master Key、伺服器的亂數和客戶端的亂數使用相同的虛擬亂數函數就能夠產生 Master Secret,此外雖然 Master Secret 的長度為 384 bits,但還是會透過 Master Secret、伺服器的亂數和客戶端的亂數使用相同的虛擬亂數函數產生不同大小的金鑰區塊,下一步客戶端和伺服器將會使用 Master Secret 產生工作階段金鑰進行資料的加密、解密、簽章和驗證。

最後 TLS 加密協定主要會使用 X.509 憑證進行客戶端和伺服器的驗證,通常會藉由的憑證頒發機構的根憑證和 X.509 憑證的簽章來驗證雙方的身份,其中憑證頒發機構會使用其私鑰對憑證進行簽章,接著會將對應的公鑰發佈給通訊雙方的作業系統和瀏覽器中當成受信任的根憑證。此外 X.509 憑證是可以進行串鏈,首先憑證頒發機構的根憑證主有包括根憑證名稱、根憑證公鑰、根憑證簽章、… 等資訊,接著中繼憑證和網站憑證皆包括擁有者名稱、擁有者公鑰、憑證頒發機構名稱、憑證頒發機構簽章、… 等資訊。其中憑證頒發機構的根憑證會透過根憑證公鑰驗證根憑證簽章,接著憑證頒發機構的根憑證驗證中繼憑證,以及中繼憑證驗證網站憑證。

總結本篇主要是先 SSL/TLS 的資安風險和金鑰產生的流程,至於有關 SSL/TLS 更多除錯方式將在之後進行說明。

相關資源

資安管理 SSL/TLS (1)

基本介紹

教學目標

初步了解 SSL/TLS 基本概念,尤其是 SSL Handshake 協商流程。

重點概念

SSL 的全名為 Secure Socket Layer,TLS 的全名稱 Transport Layer Security 兩者皆為加密協定主要提供網際網路中安全的通訊。SSL 主要被使用於證明內容,其將會透過加密技術在網際網路中提供端點驗證和通訊隱私,然而通常僅有伺服器被驗證,我們會使用公開金鑰基礎架構 (Public Key Infrastructure,PKI) 部署驗證資訊至客戶端,其協定允許客戶端和伺服器應用程式通訊時避免 eavesdropping、tampering 、 message forgery 、… 等問題發生。

大部份網站會透過網頁瀏覽器交換機密的使用者資訊,此時透過 SSL 加密協定就能夠保護其工作階段中的機敏資訊,為了方便識別我們會將網址中的 HTTP 以 HTTPS 取代之後,該網址連線至的網站使用 SSL 加密協定,也就是所謂 HTTPS 安全協定,SSL 主要使用非對稱金鑰交換在客戶端與伺服器進行協商,所有主流網頁瀏覽器皆會支援 SSL 加密協定,其中 SSL Handshake 就是在客戶端與伺服器建立初始安全通訊的工作階段。

SSL Handshake 協定組成主要有兩個階段,分別為必要的第一階段伺服器驗證和非必要的第二階段客戶端驗證。在第一個階段伺服器在回應給客戶端的請求中會傳送憑證和 Cipher 相關屬性,接著客戶端會產生主要的金鑰,主要是用於加密伺服器的公開金鑰和傳送被加密的主要金鑰至伺服器。伺服器透過主要金鑰驗證訊息,並且再透過主要金鑰返回被驗證的訊息,接著會再透過主要的金鑰衍生出金鑰持續針對通訊的資料進行加密和驗證。第二個階段伺服器傳送 Challenge 的訊息給客戶端,客戶端會進行驗證同時傳送客戶端包括公開金鑰的數位憑證,至於 SSL 資訊交換的流程主要有八個步驟:

  1. 客戶端傳送 SSL 相關資訊給伺服器,像是版本號碼、Cipher 設定、隨機產生資料、…等需要與伺服器進行 SSL 安全通訊的資訊。
  2. 伺服器傳送 SSL 相關資訊給客戶端,像是版本號碼、Cipher 設定、隨機產生資料、…等需要與客戶端進行 SSL 安全通訊的資訊。同時伺服器也會傳送所擁有的憑證,以及若客戶端請求伺服器資源時則會需要客戶端驗證的相關數位憑證。
  3. 客戶端使用與伺服器相同的資訊驗證伺服器,若是伺服器無法被驗證,則連線就無法被建立,代表 SSL Handshake 協商發生錯誤。
  4. 客戶端使用在 SSL Handshake 中所有被產生的資料建立工作階段的 Parameter Secret,接著會透過伺服器公開金鑰進行加密,之後傳送被加密的 Parameter Secret 給伺服器。
    若是伺服器已經請求客戶端驗證,則客戶端也會簽署此次 SSL Handshake 僅有伺服器和客戶端知道的資料,之後會傳送被簽署的資料、憑證和被加密的 Parameter Secret 至伺服器。
    若是伺服器已經請求客戶端驗證,則伺服器會嘗試驗證客戶端,若是客戶端無法被驗證,則工作階段就會被終止,接著伺服器會使用私密金鑰解密 Parameter Secret,然後執行接下來的步驟產生 Master Secret。
  5. 伺服器和客戶端會使用 Master Secret 產生工作階段金鑰,主要為被使用於加密和解密在 SSL 工作階段資訊交換的對稱金鑰,以及驗證完整性,同時還會偵測 SSL 安全連線之間的任何資料改變情況。
  6. 客戶端透過工作階段金鑰加密訊息傳送給伺服器,同時讓伺服器知道客戶端 SSL Handshake 已結束。
  7. 伺服器透過工作階段金鑰加密訊息傳送給客戶端,同時讓客戶端知道伺服器 SSL Handshake 已結束。
  8. 當客戶端和伺服器 SSL Handshake 皆已結果,就完成 SSL Handshake ,接著代表 SSL 工作階段開始,客戶端和伺服器將會使用工作階段金鑰加密和解密傳送的資料,同時驗證資料的完整性。

可是上述的流程有點太多技術名詞,是否能夠更簡單的說明流程呢? 請參考下述說明流程。

  1. 客戶端會傳送訊息至伺服器,訊息內容為:「嗨,請您設定加密工作階段,這有我們將會使用的 Chiper 組合列表和 SSL/TLS 的版本。」。
  2. 伺服器會回應訊息至客戶端,訊息內容為:「嗨,請使用這個來自於您列表中特別的 Chiper 組合,我也已經確認,並且我會使用 1.2 版本的 TLS 協定,此外這有我的憑證主要包括公開金鑰。」。
  3. 客戶端驗證伺服器憑證,然後取得公開金鑰,接著客戶端會使用公開金鑰的憑證加密全新的 Pre-master Key 給伺服器。
  4. 伺服器會使用私密金鑰解密 Pre-master Key,也就是 Parameter Secret。
  5. 客戶端和伺服器現在皆使用前置主金鑰運算將被分享的秘密金鑰,稱為 Shared Secret,也就是 Master Secret。
  6. 客戶端會傳送已被加密訊息至伺服器,訊息內容為:「嗨,這有一個被加密的訊息,請嘗試解密訊息和驗證訊息是否符合規格,同時之後我將會傳送以 Shared Secret 加密的訊息。」。
  7. 伺服器會解密和驗證訊息,若是正常運作則伺服器會回傳訊息至客戶端,訊息內容為:「嗨,您的加密訊息確認無誤,現在我傳送一個被加密的訊息,請嘗試解密訊息和驗證訊息是否符合規格,同時之後我將會傳送以 Shared Secret 加密的訊息。」。
  8. 客戶端和伺服器現在皆使用 Shared Secret 加密和保護它們接下來工作階段的所有通訊內容。

但是流程有八個步驟太複雜了,是否能夠更簡化為階段流程呢? 請參考下述三個主要階段流程說明。

  1. 伺服器在傳送其包含公開金鑰的憑證之後就完成部份的 SSL Handshake 協商。(細節請參考第 1 步驟至第 4 步驟)
  2. 客戶端在傳送已完成的訊息,代表已經確認 Shared Secret 交換和驗證流程已順利成功。(細節請參考第 5 步驟至第 7 步驟)
  3. 客戶端開始傳送應用程式的資料,以利進行安全的操作。(細節請參考第 8 步驟)

最後在實務應用中我們經常會碰到 SSL Handshke Failures 的錯誤訊息導致網頁應用程式無法正常使用,此時最有可能會發生在初始協商第一個階段,客戶端和伺服器可能無法進行驗證,原因可能是通訊協定版本和 Cipher 不相同所造成,當然也有可能是重新協商的安全選項或客戶端憑證請求。至於要如何確認 SSL/TLS 連線和相關資訊進行分析,則可以透過下述指令。

測試 SSL 連線指令之範例

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
c:\Apache24\bin>openssl s_client -connect leoyeh.me:443
CONNECTED(00000158)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/CN=www.leoyeh.me
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCDCCA/CgAwIBAgISA3OASIRpV7eLLmq/wHnuCKs1MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA4MTMwMDE1MDBaFw0x
NzExMTEwMDE1MDBaMBgxFjAUBgNVBAMTDXd3dy5sZW95ZWgubWUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhPPRlDV858i61vNclVmg6C6nC9fi2SLJ
sHDeLZRMfGd+7+dkJL4PNk5PiBfsZPS8oXDSviSwHcE/bWVTHSuaMXMvvYVpnQu/
K03UJaSGLvSbKofVH+56OYIbyGJ18PT8Aj4eWiVI5+gS6fmVx6jv5ASISRBJdMze
R057PXE63zXumu/IeYzwz8jDGQd4yFuyXIlQP1HKJTS65zHHX+hO2N8KheSN4t7Q
twG6h+YXKv90ufTv5SXijEJuM406brxEMutz+y6Mkn5JvLAhuwEB38RgxuLOR8qF
QxOX9q+xo8v7/lgdNnLwBpCbsrG7WZaE105VJEN4CMAs7Zp35Q3rAgMBAAGjggIY
MIICFDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFNnw6L8lvnlIq/Ys9uKcgU1tZuYj
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wIwYDVR0RBBwwGoIJbGVveWVoLm1lgg13d3cubGVveWVoLm1lMIH+BgNVHSAE
gfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAmBggrBgEFBQcCARYa
aHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUFBwICMIGeDIGbVGhp
cyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBSZWx5aW5n
IFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBDZXJ0aWZp
Y2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvcmVw
b3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBAHTJepxm+oj1irBJXYmqiAcsPUm2
BQmeD+rWffwVl4U2QrX/ddTsnD7PANHJpOS+PB1XHxMGvRekWp8/Kq+tcTDujQTq
i6gd5tWI/lEpiYlVOMw9GBPbvgr2EBXfEbcYX9Zhdr/g9q8A10gFPlvdiFFQc57Q
HieDVJN0M1T/4A1i5ajS7iuRDmxxZCTX390zXZ5ZAULSLJX4u2Q3CFy2Gjlj/XbN
NzoMAETvx62n8XvkbyT4OeOjpYgTpV26437pzyX1Ks9lzB0nqoT59FWAPbq0Qskj
WZARXHeQPMPIARHj2RLX83LkXPo814D+Tjl18UIY10Gx0dBeZx9jkNuU4xo=
-----END CERTIFICATE-----
subject=/CN=www.leoyeh.me
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3155 bytes and written 302 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 57C8C964E802FDE202E1B7219A73E5339377872D605B7CB11F77DDB609F1A110
Session-ID-ctx:
Master-Key: 953F9FC02F91B3592C98B00908959626B0D6643836F102762F07BA90A53168D2CCF2BC70CCCE823AC7A5858637AE740D
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - ba b6 f2 21 e4 08 8c 67-04 95 04 3b 3e b0 1f 8e ...!...g...;>...
0010 - 04 89 d8 00 14 d6 2a a2-2f 50 bb 97 76 6f 1e b4 ......*./P..vo..
0020 - 3e 2f 6e c0 6f 48 c8 82-52 41 fa e8 52 59 de c3 >/n.oH..RA..RY..
0030 - c8 5f e8 08 67 ce c3 77-22 56 5c cc 57 8c 72 e0 ._..g..w"V\.W.r.
0040 - 0c 60 32 6d 60 6e 86 09-ed a3 14 ab 4a 2a 39 db .`2m`n......J*9.
0050 - 18 09 81 5b 0a 88 1d fd-a7 01 aa 89 dd 2b 54 73 ...[.........+Ts
0060 - 03 fa 21 9c 0b 98 19 a2-c4 7b ee 9a 81 54 8b 5a ..!......{...T.Z
0070 - c7 c3 e7 2a 19 71 c8 99-09 77 ae a1 33 e7 39 45 ...*.q...w..3.9E
0080 - 81 43 22 e0 f1 a9 d3 6b-64 5b 7c 67 4e da 01 54 .C"....kd[|gN..T

0090 - 18 3a d7 e1 e4 46 d1 0f-48 1c 05 3a e5 6a 8c 76 .:...F..H..:.j.v
00a0 - ab d4 9b 6f 6e 1c 01 2a-49 a4 c7 79 57 45 0b a4 ...on..*I..yWE..
00b0 - 2c 7b 49 c0 cb bc bd 89-d2 4a 4d 0b 4d ff 0a 54 ,{I......JM.M..T


Start Time: 1504939264
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no
---

總結本篇主要是先了解 SSL/TLS 基本概念,尤其是 SSL Handshake 流程,至於有關 SSL/TLS 更多的資安風險和除錯方式將在之後進行說明。

相關資源

SAS 資訊安全 (5)

基本介紹

教學目標

初步了解 SAS 解決方案中有關單一登入的運作原理和資訊安全政策相關設定。

重點概念

目前若要導入解決方案至企業中,有關 SAS 解決方案中單一登入一直是最被關注的資訊安全議題,在資訊安全中存取控制 (Access Control) 之單一登入 (Single Sign-On,SSO) 皆是企業評估解決方案必須考量的項目之一,因此在 SAS 解決方案中要如何設定單一登入 (Single Sign-On,SSO)呢? 在 SAS 9.4 平台支援許多不同類型的安全驗證協定,像是整合 Windows 驗證 (Integrated Windows Authentication,IWA)、IBM WebSEAL、CA SiteMinder 和 SAML 2.0、…等,但在了解 SAS 9.4 平台中資訊安全設定之前,我們需要先了解 SAS 9.4 平台的企業架構,主要有四個層級,分別為客戶端、中間層、伺服器層和資料層。首先客戶端,像是 Java 應用程式客戶端、.NET 應用程式客戶端、網頁瀏覽器、微軟辦公室軟體,接著主要透過 SAS 網頁伺服器進行負載平衡和反向代理的功能,再來連線至中間層的 SAS 網頁應用程式伺服器,其中主要包括網頁應用程式、網頁服務、網頁基礎平台、Message Broker 和 Cache Locator 等元件,所有元件皆透過網頁基礎平台進行溝通,此外網頁基礎平台還會與 SAS 伺服器、SAS 中繼資料伺服器、SAS 內容伺服器和 SAS 網頁基礎平台資料伺服器或資料庫進行溝通,最後伺服器層主要由 SAS 應用程式伺服器,像是 SAS 中繼資料伺服器、SAS 工作區伺服器和 SAS 預儲程式伺服器所組成,至於資料層則是由 SAS 網頁基礎架構平台資料伺服器和第三方資料庫伺服器所組成。

接著我們開始了解 SAS 9.4 平台是如何進行單一登入的應用,以利進行資訊安全的管理,尤其在金融產業資訊安全的管理首要任務就是單一登入,然而 SAS 網頁應用程式單一登入主要是使用 SAS 登入管理員 統一登入所有 SAS 網頁應用程式伺服器。所謂 SAS 登入管理員 主要是一個網頁應用程式主要是處理所有針對 SAS 網頁應用程式的驗證請求,此時對於使者者來說當需要存取 SAS 網頁應用程式時將會看到相同的登入頁面,至於 SAS 登入管理員 目的主要為驗證和直接成功登入至適當的網頁應用程式,此外透過 SAS 登入管理員 也能夠集中變更與管理驗證機制非常方便。再來當使用者成功通過 SAS 登入管理員 的驗證之後,使用者將會接收全域的單一登入工作階段,所謂全域的單一登入工作階段主要允許使用者存取所有已被授權的 SAS 網頁應用程式,如此一來使用者就不用當存取任何一個網頁應用程式時重新透過憑據進行驗證,請注意在 SAS 9.4 平台中全域的單一登入工作階段到期時間獨立於網頁應用程式到期時間,在 SAS 9.4 平台中有許多有關 Middle Tier 的資訊安全政策設定,可透過 SAS Management Console 進行設定,像是「Log user off on time-out」設定就是決定 SAS 網頁應用程式的到期時間如何影響使用者全域單一登入的工作階段,其值主要為「Yes」或「No」,當為「Yes」代表無論何時任何網頁應用程式達到到期時間的限制時,則全域單一登入的工作階段就會結束,此時使用者就必須重新驗證使用網頁應用程式,反之若為「No」代表無論何時任何網頁應用程式達到到期時間的限制時,則使用者仍然有效使用全域單一登入的工作階段使用其它網頁應用程式,在 SAS 9.4 平台中預設為「No」,至於其它與資訊安全政策相關設定,請參考下表。

政策設定 預設值 說明
Allow client password storage Yes 決定網站是否允許遠端 SAS 客戶端會將使用者密碼憑據儲存至客戶端本機中,請注意許多網站禁止客戶端緩存或持久使用分佈應用程式中的密碼。
Log user off on time-out No 決定 SAS 網頁應用程式的到期時間如何影響使用者全域單一登入的工作階段,其值主要為「是」或「否」,當為「是」代表無論何時任何網頁應用程式達到到期時間的限制時,則全域單一登入的工作階段就會結束,此時使用者就必須重新驗證使用網頁應用程式,反之若為「否」代表無論何時任何網頁應用程式達到到期時間的限制時,則使用者仍然有效使用全域單一登入的工作階段使用其它網頁應用程式。
Allow user sign-in from web sign-out page Yes 決定是否顯示登入按鈕在登出成功的頁面中。
Allow user sign-in from web time-out page Yes 決定是否顯示登入按鈕在工作階段時間到期的頁面中。
Display custom sign-in message No 決定是否顯示客制化訊息在標準登入頁面中。
Display custom sign-out message No 決定是否顯示客制化訊息在標準登出頁面中。
Display custom s time-out message No 決定是否顯示客制化訊息在標準工作階段時間到期頁面中。
Display custom s time-out message No 決定是否顯示客制化訊息在標準工作階段時間到期頁面中。
Display sign-out security message No 決定是否顯示安全訊息在登出成功的頁面中。
Display time-out security message No 決定是否顯示安全訊息在成功工作階段時間到期的頁面中。
Display failed sign-in hints No 決定是否在失敗登入頁面中顯示詳細訊息,若設定「Yes」則會指出密碼無效的錯誤訊息,反之設定「No」則只會顯示使用者輸入錯誤的錯誤訊息。
Enable autocomplete feature on sign-in page No 決定是否在登入頁面中使用自動完成功能。
Allow clients to keep service sessions alive Yes 決定是在應用程式客戶端保持資源的存活,若設定「Yes」則會透過 ping 伺服器保留資源的可用性,反之設定「No」則資源到期時間類似於網頁應用程式。

在 SAS 9.4 平台中 SAS 登入管理員 僅會執行在 SASServer1_1 實體伺服器中,所有 SAS 網頁應用程式伺服器皆會使用相同的 SAS 登入管理員 進行登入。然而當我們整合第三方單一登入產品時,則驗證將會強制在 SASServer1_1 實體伺服器中執行,請注意整合第三方單一登入產品可能會使用 SAS 網頁伺服器或 SAS 網頁應用程式伺服器。接著 SASServer1_1 實體伺服器主要以 Pivotal tc Server 為主,也就是 Tomcat ,其中單一登入功能相關的元件最主要有 Authenticator Valve 和 Realm 兩個元件,所謂 Authenticator Valve 是自動針對任何內容增加使用基本驗證設定,所謂 Realm 是儲存識別網頁應用程式中有效使用者的帳號和密碼,同時也包括角色的關聯。再來 SAS 登入管理員 主要是使用 CAS 進行實作,所謂 CAS 主要是開源程式碼的驗證系統,CAS 主要使用票據減少應用程式透過憑據驗證使用者的步驟,其中 CAS 主要是由 Java Spring Framework 所建置,以及 CAS 伺服器與 SAS 網頁基礎架構平台相關的套件為 sas.svcs.logon.war,Servlet 會自動對應像是「/login」直接透過適當網址導入至 CAS 伺服器中,以利提供單一登入的功能。

範例網址

1
http://www.company.com/SASLogon/login?service=http://www.company.com/SASStudio/j_spring_cas_security_check

最後我們到底是如何透過 SAS 登入管理員 和 CAS 伺服器驗證使用者呢?請參考下述流程,情境中主要有四個角色,分別為網頁瀏覽器、SAS 網頁應用程式、SAS 登入管理員和 CAS 伺服器。

  1. 使用者會先透過網頁瀏覽器輸入網址,像是 SAS Studio 網頁應用程式的網址 http://www.company.com/SASStudio
  2. SAS 網頁應用程式會透過 Spring Framework 中的 SecurityFilterChain 設定重新導至 SAS 登入管理員中。
  3. SAS 登入管理員將會與 CAS 伺服器進行安全處理的溝通。
  4. 若發現使用者還未進行驗證,則 SAS 登入管理員會使用者輸入的憑據,像是帳號與密碼。
  5. SAS 登入管理員將會使用使用者輸入的憑據請求 CAS 服務票據,之後網頁瀏覽器就會透過票據針對 SAS 網頁應用程式進行登入和回應。
  6. 網頁瀏覽器會透過 CAS 服務票據重新傳送初始登入的請求至 SAS 網頁應用程式。
  7. 此時 SAS 網頁應用程式會透過 Spring Framework 中的 SecurityFilterChain 設定與 CAS 伺服器驗證票據,以利完成登入,若是驗證成功就會回傳 SAS 網頁應用程式的頁面。

至於使用者憑據的產生預設是在 SAS 網頁應用程式中使用在 SAS 登入管理員中以表單為基礎的驗證方式,當憑據由 SAS 登入管理員所提供時,憑據將會傳送給 SAS 中繼資料伺服器進行驗證,此時 SAS 中繼資料伺服器主要會透過驗證提供者驗證憑據是否正確,預設驗證提供者為本機作業系統。

總結有關導入企業解決方案中存取控制的問題所涉及的範圍非常廣泛,本篇僅針對 SAS 9.4 平台單一登入進行簡單說明,下一篇將會針對 SAS 登入管理員如何因應資訊安全的議題進行系統設定或客制開發的詳細說明。

相關資源