1.1. 跨站腳本攻擊(XSS)
概念
跨站腳本攻擊(Cross-Site Scripting, XSS),是一種網站應用程序的安全漏洞攻擊,是代碼注入的一種。它允許惡意用戶將代碼注入到網頁上,其他用戶在觀看網頁時就會受到影響。這類攻擊通常包含了 HTML 以及用戶端腳本語言。
XSS 攻擊示例:
假如有下面一個 textbox
<input type="text" name="address1" value="value1from">
value1from 是來自用戶的輸入,如果用戶不是輸入 value1from,而是輸入 "/><script>alert(document.cookie)</script><!-
那么就會變成:
<input type="text" name="address1" value=""/><script>alert(document.cookie)</script><!- ">
嵌入的 JavaScript 代碼將會被執行。攻擊的威力,取決於用戶輸入了什么樣的腳本。
攻擊手段和目的
常用的 XSS 攻擊手段和目的有:
- 盜用 cookie,獲取敏感信息。
- 利用植入 Flash,通過 crossdomain 權限設置進一步獲取更高權限;或者利用 Java 等得到類似的操作。
- 利用 iframe、frame、XMLHttpRequest 或上述 Flash 等方式,以(被攻擊)用戶的身份執行一些管理動作,或執行一些一般的如發微博、加好友、發私信等操作。
- 利用可被攻擊的域受到其他域信任的特點,以受信任來源的身份請求一些平時不允許的操作,如進行不當的投票活動。
- 在訪問量極大的一些頁面上的 XSS 可以攻擊一些小型網站,實現 DDoS 攻擊的效果。
應對手段
- 過濾特殊字符 - 將用戶所提供的內容進行過濾,從而避免 HTML 和 Jascript 代碼的運行。如
>
轉義為>
、<
轉義為<
等,就可以防止大部分攻擊。為了避免對不必要的內容錯誤轉移,如3<5
中的<
需要進行文本匹配后再轉移,如:<img src=
這樣的上下文中的<
才轉義。 - 設置 Cookie 為 HttpOnly - 設置了 HttpOnly 的 Cookie 可以防止 JavaScript 腳本調用,就無法通過 document.cookie 獲取用戶 Cookie 信息。
1.2. 跨站請求偽造(CSRF)
概念
跨站請求偽造(Cross-site request forgery,CSRF),也被稱為 one-click attack 或者 session riding,通常縮寫為 CSRF 或者 XSRF。它 是一種挾制用戶在當前已登錄的 Web 應用程序上執行非本意的操作的攻擊方法。和跨站腳本(XSS)相比,XSS 利用的是用戶對指定網站的信任,CSRF 利用的是網站對用戶網頁瀏覽器的信任。
攻擊手段和目的
可以如此理解 CSRF:攻擊者盜用了你的身份,以你的名義發送惡意請求。
CSRF 能做的事太多:
- 以你名義發送郵件,發消息
- 用你的賬號購買商品
- 用你的名義完成虛擬貨幣轉賬
- 泄露個人隱私
- ...
應對手段
- 表單 Token - CSRF 是一個偽造用戶請求的操作,所以需要構造用戶請求的所有參數才可以。表單 Token 通過在請求參數中添加隨機數的辦法來阻止攻擊者獲得所有請求參數。
- 驗證碼 - 請求提交是,需要用戶輸入驗證碼,以避免用戶在不知情的情況下被攻擊者偽造請求。
- Referer check - HTTP 請求頭的 Referer 域中記錄着請求資源,可通過檢查請求來源,驗證其是否合法。
1.3. SQL 注入攻擊
概念
SQL 注入攻擊(SQL injection),是發生於應用程序之數據層的安全漏洞。簡而言之,是在輸入的字符串之中注入 SQL 指令,在設計不良的程序當中忽略了檢查,那么這些注入進去的指令就會被數據庫服務器誤認為是正常的 SQL 指令而運行,因此遭到破壞或是入侵。
攻擊示例:
考慮以下簡單的登錄表單:
<form action="/login" method="POST"> <p>Username: <input type="text" name="username" /></p> <p>Password: <input type="password" name="password" /></p> <p><input type="submit" value="登陸" /></p> </form>
我們的處理里面的 SQL 可能是這樣的:
username:=r.Form.Get("username") password:=r.Form.Get("password") sql:="SELECT * FROM user WHERE username='"+username+"' AND password='"+password+"'"
如果用戶的輸入的用戶名如下,密碼任意
myuser' or 'foo' = 'foo' --
那么我們的 SQL 變成了如下所示:
SELECT * FROM user WHERE username='myuser' or 'foo' = 'foo' --'' AND password='xxx'
在 SQL 里面 --
是注釋標記,所以查詢語句會在此中斷。這就讓攻擊者在不知道任何合法用戶名和密碼的情況下成功登錄了。
對於 MSSQL 還有更加危險的一種 SQL 注入,就是控制系統,下面這個可怕的例子將演示如何在某些版本的 MSSQL 數據庫上執行系統命令。
sql:="SELECT * FROM products WHERE name LIKE '%"+prod+"%'" Db.Exec(sql)
如果攻擊提交 a%' exec master..xp_cmdshell 'net user test testpass /ADD' --
作為變量 prod 的值,那么 sql 將會變成
sql:="SELECT * FROM products WHERE name LIKE '%a%' exec master..xp_cmdshell 'net user test testpass /ADD'--%'"
MSSQL 服務器會執行這條 SQL 語句,包括它后面那個用於向系統添加新用戶的命令。如果這個程序是以 sa 運行而 MSSQLSERVER 服務又有足夠的權限的話,攻擊者就可以獲得一個系統帳號來訪問主機了。
雖然以上的例子是針對某一特定的數據庫系統的,但是這並不代表不能對其它數據庫系統實施類似的攻擊。針對這種安全漏洞,只要使用不同方法,各種數據庫都有可能遭殃。
攻擊手段和目的
- 數據表中的數據外泄,例如個人機密數據,賬戶數據,密碼等。
- 數據結構被黑客探知,得以做進一步攻擊(例如
SELECT * FROM sys.tables
)。 - 數據庫服務器被攻擊,系統管理員賬戶被竄改(例如
ALTER LOGIN sa WITH PASSWORD='xxxxxx'
)。 - 獲取系統較高權限后,有可能得以在網頁加入惡意鏈接、惡意代碼以及 XSS 等。
- 經由數據庫服務器提供的操作系統支持,讓黑客得以修改或控制操作系統(例如 xp_cmdshell "net stop iisadmin"可停止服務器的 IIS 服務)。
- 破壞硬盤數據,癱瘓全系統(例如 xp_cmdshell "FORMAT C:")。
應對手段
- 使用參數化查詢 - 建議使用數據庫提供的參數化查詢接口,參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中,即不要直接拼接 SQL 語句。例如使用 database/sql 里面的查詢函數
Prepare
和Query
,或者Exec(query string, args ...interface{})
。 - 單引號轉換 - 在組合 SQL 字符串時,先針對所傳入的參數作字符取代(將單引號字符取代為連續 2 個單引號字符)。
1.4. 拒絕服務攻擊(DoS)
拒絕服務攻擊(denial-of-service attack, DoS)亦稱洪水攻擊,是一種網絡攻擊手法,其目的在於使目標電腦的網絡或系統資源耗盡,使服務暫時中斷或停止,導致其正常用戶無法訪問。
當黑客使用網絡上兩個或以上被攻陷的電腦作為“僵屍”向特定的目標發動“拒絕服務”式攻擊時,稱為分布式拒絕服務攻擊(distributed denial-of-service attack,縮寫:DDoS attack、DDoS)。
攻擊方式
- 帶寬消耗型攻擊
- 資源消耗型攻擊
應對手段
- 防火牆 - 允許或拒絕特定通訊協議,端口或 IP 地址。當攻擊從少數不正常的 IP 地址發出時,可以簡單的使用拒絕規則阻止一切從攻擊源 IP 發出的通信。
- 路由器、交換機 - 具有速度限制和訪問控制能力。
- 流量清洗 - 通過采用抗 DDoS 軟件處理,將正常流量和惡意流量區分開。
2. 加密技術及密鑰安全管理
對於網站來說,用戶信息、賬戶等等敏感數據一旦泄漏,后果嚴重,所以為了保護數據,應對這些信息進行加密處理。
信息加密技術一般分為:
- 消息摘要
- 加密算法
- 對稱加密
- 非對稱加密
- 證書
2.1. 消息摘要
常用數字簽名算法:MD5、SHA 等。
應用場景:將用戶密碼以消息摘要形式保存到數據庫中。
2.2. 加密算法
對稱加密
對稱加密指加密和解密所使用的密鑰是同一個密鑰。
常用對稱加密算法:DES 等。
應用場景:Cookie 加密、通信機密等。
非對稱加密
非對稱加密指加密和解密所使用的不是同一個密鑰,而是一個公私鑰對。用公鑰加密的信息必須用私鑰才能解開;反之,用私鑰加密的信息只有用公鑰才能解開。
常用非對稱加密算法:RSA 等。
應用場景:HTTPS 傳輸中瀏覽器使用的數字證書實質上是經過權威機構認證的非對稱加密公鑰。
2.3. 密鑰安全管理
保證密鑰安全的方法:
- 把密鑰和算法放在一個獨立的服務器上,對外提供加密和解密服務,應用系統通過調用這個服務,實現數據的加解密。
- 把加解密算法放在應用系統中,密鑰則放在獨立服務器中,為了提高密鑰的安全性,實際存儲時,密鑰被切分成數片,加密后分別保存在不同存儲介質中。
2.3. 證書
證書可以稱為信息安全加密的終極手段。公開密鑰認證(英語:Public key certificate),又稱公開密鑰證書、公鑰證書、數字證書(digital certificate)、數字認證、身份證書(identity certificate)、電子證書或安全證書,是用於公開密鑰基礎建設的電子文件,用來證明公開密鑰擁有者的身份。此文件包含了公鑰信息、擁有者身份信息(主體)、以及數字證書認證機構(發行者)對這份文件的數字簽名,以保證這個文件的整體內容正確無誤。
透過信任權威數字證書認證機構的根證書、及其使用公開密鑰加密作數字簽名核發的公開密鑰認證,形成信任鏈架構,已在 TLS 實現並在萬維網的 HTTP 以 HTTPS、在電子郵件的 SMTP 以 STARTTLS 引入並廣泛應用。
眾所周知,常見的應用層協議 HTTP、FTP、Telnet 本身不保證信息安全。但是加入了 SSL/TLS 加密數據包機制的 HTTPS、FTPS、Telnets 是信息安全的。
概念
傳輸層安全性協議(Transport Layer Security, TLS),及其前身安全套接層(Secure Sockets Layer, SSL)是一種安全協議,目的是為互聯網通信,提供安全及數據完整性保障。
證書原理
SSL/TLS 協議的基本思路是采用公鑰加密法,也就是說,客戶端先向服務器端索要公鑰,然后用公鑰加密信息,服務器收到密文后,用自己的私鑰解密。
這里有兩個問題:
(1)如何保證公鑰不被篡改?
解決方法:將公鑰放在數字證書中。只要證書是可信的,公鑰就是可信的。
(2)公鑰加密計算量太大,如何減少耗用的時間?
解決方法:每一次對話(session),客戶端和服務器端都生成一個"對話密鑰"(session key),用它來加密信息。由於"對話密鑰"是對稱加密,所以運算速度非常快,而服務器公鑰只用於加密"對話密鑰"本身,這樣就減少了加密運算的消耗時間。
SSL/TLS 協議的基本過程是這樣的:
- 客戶端向服務器端索要並驗證公鑰。
- 雙方協商生成"對話密鑰"。
- 雙方采用"對話密鑰"進行加密通信。