網(wǎng)站前端開發(fā)碰到的安全容易被人們忽視，因為大多人認為這些在客戶端瀏覽器運行的代碼不會造成服務器端的安全隱患，通過本文將簡單闡述網(wǎng)站前端中經(jīng)常碰到的安全問題，以及一些應對策略

隨著前端技術(shù)的發(fā)展,安全問題已經(jīng)從服務器悄然來到了每一個用戶的的面前，盜取用戶數(shù)據(jù), 制造惡意的可以自我復制的蠕蟲代碼,讓病毒在用戶間傳播,使服務器當?shù)? 更有甚者可能會在用戶不知覺得情況下,讓用戶成為攻擊者,這絕對不是駭人聽聞。富客戶端的應用越來越廣，前端的安全問題也隨之增多,今天就簡單介紹下一些常見的攻擊方式和預防攻擊辦法。

常見攻擊

XSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入的惡意html代碼會被執(zhí)行，從而達到惡意用戶的特殊目的。XSS屬于被動式的攻擊，因為其被動且不好利用，所以許多人常呼略其危害性。但是隨著前端技術(shù)的不斷進步富客戶端的應用越來越多，這方面的問題越來越受關(guān)注。舉個簡單例子 ： 假如你現(xiàn)在是sns站點上一個用戶，發(fā)布信息的功能存在漏洞可以執(zhí)行js 你在 此刻輸入一個 惡意腳本，那么當前所有看到你新信息的人的瀏覽器都會執(zhí)行這個腳本彈出提示框 （很爽吧 彈出廣告 ：）），如果你做一些更為激進行為呢 后果難以想象。

CSRF(Cross Site Request Forgery)，跨站點偽造請求。顧名思義就是 通過偽造連接請求在用戶不知情的情況下，讓用戶以自己的身份來完成攻擊者需要達到的一些目的。csrf 的攻擊不同于xss csrf 需要被攻擊者的主動行為觸發(fā)。這樣聽來似乎是有“被釣魚”的嫌疑哈哈。
多窗口瀏覽器這這方面似乎是有助紂為虐的嫌疑，因為打開的新窗口是具有當前所有會話的，如果是單瀏覽器窗口類似ie6 就不會存在這樣的問題，因為每個窗口都是一個獨立的進程。舉個簡單例子 ： 你正在玩白社會， 看到有人發(fā)了一個連接，你點擊過去，然后這個連接里面?zhèn)卧炝艘粋€送禮物的表單，這僅僅是一個簡單的例子，問題可見一般。

cookie劫持，通過獲取頁面的權(quán)限，在頁面中寫一個簡單的到惡意站點的請求，并攜帶用戶的cookie 獲取cookie后通過cookie 就可以直以被盜用戶的身份登錄站點。這就是cookie 劫持。舉個簡單例子： 某人寫了一篇很有意思的日志，然后分享給大家，很多人都點擊查看并且分享了該日志，一切似乎都很正常，然而寫日志的人卻另有用心，在日志中偷偷隱藏了一個對站外的請求,那么所有看過這片日志的人都會在不知情的情況下把自己的cookie 發(fā)送給了 某人，那么他可以通過任意一個人的cookie 來登錄這個人的賬戶。

我們該怎么做？

大致可以分為兩類 1 一般用戶 2網(wǎng)站開發(fā)人員。

首先我們來說說做為一個一般的web產(chǎn)品使用者，很多時候我們是被動的，是在不知情的情況下被利用的。那么我們可以：
1 對于安全級別較高的web應用訪問 需要打開一個獨立瀏覽器窗口。
2 對于陌生人發(fā)布的鏈接最好也是復制然后在新開的窗口中打開，當然最好的辦法就是無視 – -。

對于開發(fā)人員來說我們得從相對詳細的一些角度來分析：
對于xss 攻擊 特點是攻擊者的代碼必須能獲取用戶瀏覽器端的執(zhí)行權(quán)限，那么代碼是從哪里來的呢，想要杜絕此類攻擊出現(xiàn) 其實可以在入口 和出口 進行嚴格的過濾，這樣的雙保險應當說99% 的類似問題就被我們解決掉了，另外的1% 是那些蹩腳的瀏覽器帶來的后遺癥，相信在未來這種問題會越來越少的。

這里我對xss漏洞的形式作了一些整理

惡意代碼值被作為某一標簽的內(nèi)容顯示 （如果輸入的是html 則html會被解析）例如你輸入用戶名 更新后用戶名會顯示到頁面中的某一個標簽內(nèi) 如果你輸入的是

popper.w<script src="hack.js" type="text/javajscript"></script>

那么如果不做過濾直接顯示到頁面， 會引進一個第三方的js 代碼并且會執(zhí)行。

策略：在不需要html輸入的地方對html 標簽 及一些特殊字符( ” < > & 等等 )做過濾，將其轉(zhuǎn)化為不被瀏覽器解釋執(zhí)行的字符

惡意代碼被作為某一標簽的屬性顯示（通過用 “ 將屬性截斷來開辟新的屬性 或惡意方法） 這種情況往往是是開發(fā)人員為了實現(xiàn)功能可能會在某些dom標簽上記錄一些用戶輸入的信息例如你輸入的用戶名 會在頁面中的標簽中以 title 的形式出現(xiàn) 這時候 如果 你輸入的是精心設計的內(nèi)容 那么 看看 這個

<a title="popper.w" onclick="alert(1)">popper.w" onclick="alert(1)</a>

這里我實際上輸入的內(nèi)容是“popper.w” onclick=”alert(1)”，當然你可以在上邊寫更多的內(nèi)容。

策略：對屬性中可能存在截斷的一些字符進行過濾 屬性本身存在的 單引號和雙引號都需要進行轉(zhuǎn)碼。

惡意代碼被作為html代碼本身顯示 (常見的html編輯器) 這種情況存在的問題最多，不再這里舉例子了。

策略：最好對用戶輸入的html 標簽及標簽屬性做白名單過濾，也可以對一些存在漏洞的標簽和屬性進行專門過濾。

惡意代碼被作為一段json字符串顯示 （通過 變量截斷 創(chuàng)造新的 惡意的js 變量 甚至是可執(zhí)行的代碼） 這個問題的關(guān)鍵是用戶輸入的信息可能會成為頁面中js 代碼的一部分。

策略：對屬性中可能存在截斷的一些字符進行過濾 屬性本身存在的 單引號和雙引號都需要進行轉(zhuǎn)碼。

對于crsf 和cookie 劫持

特點 隱蔽性比較高 有些時候是先利用xss 漏洞 然后再做 欺騙的

策略
通過 referer、token 或者 驗證碼 來檢測用戶提交。
盡量不要在頁面的鏈接中暴漏任何與用戶唯一號（用戶id）有關(guān)的信息。
對于用戶修改 刪除 提交的操作最好都使用post 操作 。
避免全站通用的cookie 嚴格的設置cookie的域。

ok 就寫到這里~

上邊講的都是一些比較常見的安全問題，主要是從js hack 方面來講的，隨著前端技術(shù)的不斷發(fā)展進步，更多的安全問題可能會展現(xiàn)在我們面，對于開發(fā)者來說大多數(shù)的問題是可以在開發(fā)階段避免的，所以可怕的不是hack 可怕的是我們對自己的產(chǎn)品安全的松懈~。