段智華 ()
年
月
一
SOAP簡介以及SOAP安全介紹
SOAP（Simple Object Access Protocol ）簡單對象訪問協議是在分散或分布式的環境中交換信息的簡單的協議
是一個基於XML的協議
它包括四個部分
SOAP封裝（envelop)
封裝定義了一個描述消息中的內容是什麼
是誰發送的
誰應當接受並處理它以及如何處理它們的框架
SOAP編碼規則（encoding rules）
用於表示應用程序需要使用的數據類型的實例; SOAP RPC表示(RPC representation)
表示遠程過程調用和應答的協定;SOAP綁定（binding）
使用底層協議交換信息
雖然這四個部分都作為SOAP的一部分
作為一個整體定義的
但他們在功能上是相交的
彼此獨立的
特別的
信封和編碼規則是被定義在不同的XML命名空間(namespace)中
這樣使得定義更加簡單
SOAP的兩個主要設計目標是簡單性和可擴展性
這就意味著有一些傳統消息系統或分布式對象系統中的某些性質將不是SOAP規范的一部分
比如
分布式垃圾收集 (Distributed garbage collection)
成批傳送消息(Boxcarring or batching of messages)
對象引用 (Objects
by
reference（which requires distributed garbage collection）)
對象激活 (Activation（which requires objects
by
reference）)
自從SOAP規范從去年發布以來
SOAP規范的加密性
認證和授權等安全機制一直受到人們的廣泛關注
這三個方面對於任何的B
B來說都是很重要的
但SOAP標准在制定規范時並沒有過多考慮SOAP 的安全性要求
因為SOAP一個很重要的設計目標就在於它的簡單性
盡可能的利用已有的標准和協議來實現相應的功能
而不是另起爐灶
重新定義一個嶄新的協議
如果這樣的話
會大大的降低它的實用性和兼容性
安全性是個復雜的問題
在最低層SOAP 消息可通過 HTTPS 傳遞
通用 SSL 傳輸信息
這就確保被編碼消息內容可以避免被竊聽
也確保客戶端和服務器可互相驗證身份
盡管 HTTPS 解決了對竊聽者屏蔽消息的問題
但不能滿足安全性更高的特殊用戶認證的特定 Web 服務的要求
比如下面需要SOAP安全的幾個場景
僅僅依靠SSL的安全機制是不滿足信息的安全要求的
端對端的信息傳送（End
to
end messaging）
SOAP消息可以與不同的運輸層協議（如HTTP
SMTP等）捆綁在一起進行傳輸
傳輸的過程中可能經過一系列中間設備或應用程序
假如應用程序對SOAP消息進行惡意破壞
可以在SOAP消息插入一系列相似的頭元素
再傳給下一個中間設備或程序
從而破壞了信息的完整性
在這種情況之下
中間設備或應用程序是不值得完全信任的
它們隨時可以修改傳輸的信息
因此
SSL/TLS並不能保證端到端傳輸的安全性
中間件的獨立性（Middleware independence）
在應用層中保證端對端的安全要求
如果在傳輸中的傳輸的消息是平文
而不是是經過加密 的密文
極易受到黑客的攻擊
但假如在應用程序中進行安全加密的處理
需要用戶對加密算法有詳細的了解
有許多不同的加密算法適合不同的安全要求
這對於用戶來說是額外的負擔
因此
標准的
安全的
獨立的
透明的運輸層是必要的
在SOAP中進行適當的安全擴展
保證了中間件應用程序的獨立性
不用考慮過多的加密算法細節
傳輸的獨立性 （Transport independence）
SOAP消息在傳輸的時候可以與不同的運輸層協議進行捆綁
如HTTP
SMTP協議
有可能存在這麼一個場景
所有的通信連接是安全的
中間層應用程序也是值得信賴的
但是
安全信息需要經過兩個運輸層協議
比如前一段是經過HTTP協議傳輸
在下一個階段
則需要通過SMTP協議進行傳輸
兩者之間的轉換是煩瑣的
易出錯的
因此
在SOAP中加入擴展信息
保證了運輸層的獨立性
從而使與運輸層無關
駐留信息的安全性
運輸層可以進行安全傳輸
但不能保證信息駐留時也是安全的
假如消息保存後繼續向前傳輸
駐留信息的安全十分重要
在電子商務中
常常要求用戶填寫帳號和密碼
這些信息通常保留在本地的COOKIE中
對於這些持久保存的信息進行加密
可通過SOAP的安全擴展來實現
在目前應用最廣泛的INTERNET
運行著許多基於TCP/IP協議的應用
由於TCP/IP協議本身的不安全性
造成了這些應用的不安全性
如
幾乎所有的數據在網絡上都是明文傳輸和用戶在網絡上的身份僅通過IP地址表現
由於這兩個原因
使得一些軟件產品的安全工作形同虛設
比如一些網絡應用通過網絡將用戶口令傳輸的服務方
由服務方驗證用戶的合法性
由於用戶口令在網絡上傳輸是明文的
它很容易被網絡監聽者獲取
又如一些防火牆進行的IP過濾工作是通過IP數據包中的IP地址來實現的
實際上在NTERNET上偽造一個IP地址是相當容易的
SOAP協議基於運輸層之上
有必要通過SOAP的擴展來增強SOAP的安全功能
因此
我們必須了解當前Internet網絡面臨哪些威脅
以及網絡網絡安全的要求是什麼
這不僅僅是SOAP必須考慮的問題
也是其他基於Internet網絡分布式應用程序必須考慮的
只有更好的了解各種無所不在的攻擊手段和侵犯方式
才能更好的建立安全的防范機制
二
互聯網絡的安全要求以及存在的安全威脅
總的來說
網絡安全的五個基本的安全要求
機密性(Confidentiality)
保證沒有經過授權的用戶
實體或進程無法竊取信息
在 一個開放的網絡環境裡
維護信息機密是全面推廣應用的重要保障
因此
要預防非法的信息存取和信息在傳輸過程中被非法竊取
授權
(Authorization
) 授權是確定允許用戶做什麼的過程
可將不同的特權給予不同類型的用戶
例如
每個人都能閱讀公共圖書館的聯機卡片目錄
甚至不必是該系統的認證用戶
換句話說
所有用戶都被授權可閱讀目錄
但系統可能會將借書的權限僅限於已認證用戶
這裡已認證是指持有此圖書館的有效借書卡
取決於認證機制的復雜程度
系統可能根據所持的卡來限制用戶的特權
例如
可能授權某些用戶可以借的書不限數量
而限制其他用戶只能借一定數量的書籍
數據完整性(Data integrity)
保證沒有經過授權的用戶不能改變或者刪除信息
從而信息在傳送的過程中不會被偶然或故意破壞
保持信息的完整
統一
因此
要預防對信息的隨意生成
修改和刪除
同時要防止數據傳送過程中信息的丟失和重復
原始性證明（Proof of Origin
） 對信息或數據的發送者的進行標示
保證信息被經過標示的發送者所傳送
從而避免以前的數據包被重復發送
防止抵賴(Nonrepudiation): 保證信息的發送者不能抵賴或否認對信息的發送
當然信息發送前需要對發送者進行安全認證
要在信息的傳輸過程中為參與交易的個人
企業或國家提供可靠的標識
最後的三個安全要求是彼此相關的
數據完整性與原始性證明的區別在於數據是完整的
並不能保證信息不被重復發送
換句話說
數據完整性不能防止反復攻擊
哈希散列算法如 HMAC
認證時使用一個經過加密的密鑰對於原始性證明來說是合適的
但並不適用於
防止抵賴
相應的
目前網絡存在的威脅主要表現在以下幾個方面
非授權訪問
沒有預先經過同意
就使用網絡或計算機資源被看作非授權訪問
它主要有以下幾種形式
假冒
身份攻擊
非法用戶進入網絡系統進行違法操作
合法用戶以未授權方式進行操作等
信息遺漏丟失
指敏感數據在有意或無意中被洩漏出去或丟失
破壞數據完整性
以非法手段竊得對數據的使用權
刪除
修改
插入或重發某些重要信息
以取得有益於攻擊者的響應
惡意添加
修改數據
以干擾用戶的正常使用
拒絕服務攻擊
是一種比較簡單
但又日益流行的攻擊和禁用企業信息資源的方法
在拒絕服務攻擊中
作惡者發送大量的信息流量
使 Web 服務器
主機
路由器和其它網絡設備負擔過重
通過這種方式發送的信息流量非常之大
致使企業的用戶
客戶和合作伙伴都在好長一段時間內無法訪問網絡
基於以上的安全威脅以及網絡安全的迫切要求
僅僅依靠SSL的安全機制不能解決所有的問題
SOAP安全的解決方案基於三個W
C的XML規范來實現
XML Digital Signature
XML encryption
and XML Key Management Services
SOAP層安全處於傳輸層和應用層之上
對SOAP層的安全性進行擴展
把關於安全的五個基本要求應用到整個的SOAP信息中
包括SOAP頭以及SOAP體
同時
更多的安全措施也可結合SOAP層安全與傳輸層以及應用程序 來共同解決
由於網絡安全十分復雜
目前W
C正在嘗試制定相應的規范
不斷的完善和更新
下面介紹SOAP數字簽名的一個草案
三
SOAP 安全擴展: 數字簽名
．
SOAP Security Extensions: Digital Signature
這個文本目前只是W
C的討論方案
正處於不斷修改的過程中
提出此文本的最初設想是利用XML的數字簽名（XML Digital Signature syntax [XML
Signature]）對SOAP進行擴展
在SOAP的頭元素中定義簽名屬性（
）來實現以下部分是我翻譯了WC的SOAP數字簽名草案中的一部分以供大家參考如有不當之處敬請大家指正
工作組在SOAP頭元素的擴展命名空間中加入安全特征通過擴展在方案中加入一個新的元素這個元素在schema中可以不用改變如果要在SOAP協議的進行加密性擴展可以在命名空間中引入適當的標准實現
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27395.html
