網(wǎng)站前端開發(fā)碰到的安全容易被人們忽視，因?yàn)榇蠖嗳苏J(rèn)為這些在客戶端瀏覽器運(yùn)行的代碼不會造成服務(wù)器端的安全隱患，通過本文將簡單闡述網(wǎng)站前端中經(jīng)常碰到的安全問題，以及一些應(yīng)對策略
隨著前端技術(shù)的發(fā)展,安全問題已經(jīng)從服務(wù)器悄然來到了每一個(gè)用戶的的面前，盜取用戶數(shù)據(jù), 制造惡意的可以自我復(fù)制的蠕蟲代碼,讓病毒在用戶間傳播,使服務(wù)器當(dāng)?shù)? 更有甚者可能會在用戶不知覺得情況下,讓用戶成為攻擊者,這絕對不是駭人聽聞。富客戶端的應(yīng)用越來越廣，前端的安全問題也隨之增多,今天就簡單介紹下一些常見的攻擊方式和預(yù)防攻擊辦法。
常見攻擊
XSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入的惡意html代碼會被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。XSS屬于被動式的攻擊，因?yàn)槠浔粍忧也缓美茫栽S多人常呼略其危害性。但是隨著前端技術(shù)的不斷進(jìn)步富客戶端的應(yīng)用越來越多，這方面的問題越來越受關(guān)注。舉個(gè)簡單例子 ： 假如你現(xiàn)在是sns站點(diǎn)上一個(gè)用戶，發(fā)布信息的功能存在漏洞可以執(zhí)行js 你在 此刻輸入一個(gè) 惡意腳本，那么當(dāng)前所有看到你新信息的人的瀏覽器都會執(zhí)行這個(gè)腳本彈出提示框 （很爽吧 彈出廣告 ：）），如果你做一些更為激進(jìn)行為呢 后果難以想象。
CSRF(Cross Site Request Forgery)，跨站點(diǎn)偽造請求。顧名思義就是 通過偽造連接請求在用戶不知情的情況下，讓用戶以自己的身份來完成攻擊者需要達(dá)到的一些目的。csrf 的攻擊不同于xss csrf 需要被攻擊者的主動行為觸發(fā)。這樣聽來似乎是有“被釣魚”的嫌疑哈哈。
多窗口瀏覽器這這方面似乎是有助紂為虐的嫌疑，因?yàn)榇蜷_的新窗口是具有當(dāng)前所有會話的，如果是單瀏覽器窗口類似ie6 就不會存在這樣的問題，因?yàn)槊總€(gè)窗口都是一個(gè)獨(dú)立的進(jìn)程。舉個(gè)簡單例子 ： 你正在玩白社會， 看到有人發(fā)了一個(gè)連接，你點(diǎn)擊過去，然后這個(gè)連接里面?zhèn)卧炝艘粋€(gè)送禮物的表單，這僅僅是一個(gè)簡單的例子，問題可見一般。
cookie劫持，通過獲取頁面的權(quán)限，在頁面中寫一個(gè)簡單的到惡意站點(diǎn)的請求，并攜帶用戶的cookie 獲取cookie后通過cookie 就可以直以被盜用戶的身份登錄站點(diǎn)。這就是cookie 劫持。舉個(gè)簡單例子： 某人寫了一篇很有意思的日志，然后分享給大家，很多人都點(diǎn)擊查看并且分享了該日志，一切似乎都很正常，然而寫日志的人卻另有用心，在日志中偷偷隱藏了一個(gè)對站外的請求,那么所有看過這片日志的人都會在不知情的情況下把自己的cookie 發(fā)送給了 某人，那么他可以通過任意一個(gè)人的cookie 來登錄這個(gè)人的賬戶。
我們該怎么做？
大致可以分為兩類 1 一般用戶 2網(wǎng)站開發(fā)人員。
首先我們來說說做為一個(gè)一般的web產(chǎn)品使用者，很多時(shí)候我們是被動的，是在不知情的情況下被利用的。那么我們可以：
1 對于安全級別較高的web應(yīng)用訪問 需要打開一個(gè)獨(dú)立瀏覽器窗口。
2 對于陌生人發(fā)布的鏈接最好也是復(fù)制然后在新開的窗口中打開，當(dāng)然最好的辦法就是無視 – -。
對于開發(fā)人員來說我們得從相對詳細(xì)的一些角度來分析：
對于xss 攻擊 特點(diǎn)是攻擊者的代碼必須能獲取用戶瀏覽器端的執(zhí)行權(quán)限，那么代碼是從哪里來的呢，想要杜絕此類攻擊出現(xiàn) 其實(shí)可以在入口 和出口 進(jìn)行嚴(yán)格的過濾，這樣的雙保險(xiǎn)應(yīng)當(dāng)說99% 的類似問題就被我們解決掉了，另外的1% 是那些蹩腳的瀏覽器帶來的后遺癥，相信在未來這種問題會越來越少的。
這里我對xss漏洞的形式作了一些整理
惡意代碼值被作為某一標(biāo)簽的內(nèi)容顯示 （如果輸入的是html 則html會被解析）例如你輸入用戶名 更新后用戶名會顯示到頁面中的某一個(gè)標(biāo)簽內(nèi) 如果你輸入的是
popper.w<script src="hack.js" type="text/javajscript"></script>
那么如果不做過濾直接顯示到頁面， 會引進(jìn)一個(gè)第三方的js 代碼并且會執(zhí)行。
策略：在不需要html輸入的地方對html 標(biāo)簽 及一些特殊字符( ” < > & 等等 )做過濾，將其轉(zhuǎn)化為不被瀏覽器解釋執(zhí)行的字符
惡意代碼被作為某一標(biāo)簽的屬性顯示（通過用 “ 將屬性截?cái)鄟黹_辟新的屬性 或惡意方法） 這種情況往往是是開發(fā)人員為了實(shí)現(xiàn)功能可能會在某些dom標(biāo)簽上記錄一些用戶輸入的信息例如你輸入的用戶名 會在頁面中的標(biāo)簽中以 title 的形式出現(xiàn) 這時(shí)候 如果 你輸入的是精心設(shè)計(jì)的內(nèi)容 那么 看看 這個(gè)
<a onclick="alert(1)">popper.w" onclick="alert(1)</a>
這里我實(shí)際上輸入的內(nèi)容是“popper.w” onclick=”alert(1)”，當(dāng)然你可以在上邊寫更多的內(nèi)容。
策略：對屬性中可能存在截?cái)嗟囊恍┳址M(jìn)行過濾 屬性本身存在的 單引號和雙引號都需要進(jìn)行轉(zhuǎn)碼。
惡意代碼被作為html代碼本身顯示 (常見的html編輯器) 這種情況存在的問題最多，不再這里舉例子了。
策略：最好對用戶輸入的html 標(biāo)簽及標(biāo)簽屬性做白名單過濾，也可以對一些存在漏洞的標(biāo)簽和屬性進(jìn)行專門過濾。
惡意代碼被作為一段json字符串顯示 （通過 變量截?cái)?創(chuàng)造新的 惡意的js 變量 甚至是可執(zhí)行的代碼） 這個(gè)問題的關(guān)鍵是用戶輸入的信息可能會成為頁面中js 代碼的一部分。
策略：對屬性中可能存在截?cái)嗟囊恍┳址M(jìn)行過濾 屬性本身存在的 單引號和雙引號都需要進(jìn)行轉(zhuǎn)碼。
對于crsf 和cookie 劫持
特點(diǎn) 隱蔽性比較高 有些時(shí)候是先利用xss 漏洞 然后再做 欺騙的
策略
通過 referer、token 或者 驗(yàn)證碼 來檢測用戶提交。
盡量不要在頁面的鏈接中暴漏任何與用戶唯一號（用戶id）有關(guān)的信息。
對于用戶修改 刪除 提交的操作最好都使用post 操作 。
避免全站通用的cookie 嚴(yán)格的設(shè)置cookie的域。
ok 就寫到這里~
上邊講的都是一些比較常見的安全問題，主要是從js hack 方面來講的，隨著前端技術(shù)的不斷發(fā)展進(jìn)步，更多的安全問題可能會展現(xiàn)在我們面，對于開發(fā)者來說大多數(shù)的問題是可以在開發(fā)階段避免的，所以可怕的不是hack 可怕的是我們對自己的產(chǎn)品安全的松懈~。