資訊專欄INFORMATION COLUMN
摘要：總結(jié)總的來說，前端最重要的就是一個這個代表用戶身份的憑證，保護好這個憑證，同時利用同源策略以及自己加密來識別用戶，最后以最惡意的眼光對待用戶的輸入，不要相信用戶的輸入。
前端安全一直是一個蠻嚴(yán)苛的問題，特別如果設(shè)計到money更是如此。
了解前端安全，在平時的coding中主動考慮，防范于未然，是一個有追求的程序猿應(yīng)該做的。
我們從弱弱的基本開始，第一步當(dāng)然是登錄鑒權(quán)了，如果一個需要用戶身份鑒權(quán)的應(yīng)用系統(tǒng)沒有登錄過濾那簡直是沒法想像的，方案基本都是用戶輸入用戶名
密碼、或是三方 openID 授權(quán)后在 session 里保存用戶此次登錄的憑證來確保每次請求的合法性。由于 session有時效限制，所以若用戶一段時間未與服務(wù)
器交互則會過期重登，當(dāng)然我們也可以通過把登錄憑證存在 cookie 里來自由控制用戶登錄的有效時間。這個是最基本的鑒權(quán)我們就不深入細(xì)節(jié)。
雖然有了登錄驗證后，我們可以擋掉其他非登錄用戶的騷擾了，但悲劇的是壞人們還是可以欺騙我們善良的用戶，借已登錄用戶的手來搞破壞。
即 CSRF（Cross-site request forgery）跨站請求偽造。
舉個栗子：
有個黑客的網(wǎng)站 h.com，我們的網(wǎng)站 a.com。用戶登錄了a.com，但被誘點進入h.com（如收到 QQ 消息或郵件傳播的h.com 的鏈接），當(dāng)用戶訪問
這個鏈接時，h.com 上自動發(fā)送一個請求到 a.com，由于用戶已登錄a.com，瀏覽器根據(jù)同源策略，會在該請求上自動附帶了 cookie，而前面我們
提到了鑒權(quán)是通過 cookie 里的某個 key 值憑證的，所以如若沒有判斷該請求的來源合法性，我們則通過了該偽造的請求，執(zhí)行了相應(yīng)的操作。比如
這個請求是讓該用戶發(fā)一篇日志，或是發(fā)微博，或是嚴(yán)重的發(fā)起一筆轉(zhuǎn)賬。
常見的諸如放一張看不見的圖片發(fā)起get請求
post 請求會稍微麻煩些，但同樣很好實現(xiàn)，可以構(gòu)造一個表誘導(dǎo)用戶點擊，也可以直接利用ajax發(fā)送post請求。
要防住此類偽造請求我們第一反應(yīng)都是檢查這個請求的來源，確實，在上述的情形下發(fā)來的請求報文里refferer字段的網(wǎng)址不是我們的自己站點，
而會是一個三方的，如上假設(shè)的 h.com。但是很多情況下，refferer并不完全靠譜，比如如果眾多二級域名之間需要通信，那么refferer可能會
設(shè)得比較泛，如*.a.com。或是歷史原因一些 refferer 為空的請求會漏過校驗等。所以這種方式只是提高了破解成本，并不能完全杜絕。
現(xiàn)在業(yè)界比較通用的解決方案還是在每個請求上附帶一個anti-CSRF token。
例如，將sessionid加鹽再散列處理。然后一起發(fā)送給后端。
服務(wù)器端拿到 token 后用相同的算法對 sid 運算后匹對，相同則為已登錄用戶發(fā)出請求，沒有或不對等則說明該請求是偽造的。
token = MD5（ sid * salt ）
其實這個算法的精髓在于使用了 cookie 中的 sid（用戶登錄后我們服務(wù)器種的 cookie 憑證），因為前端的代碼對用戶而言都是沒有秘密的，只要花點時
間即可推算出我們的算法，但由于攻擊者無法登錄，又拿不到 cookie 里的 sid（根據(jù)瀏覽器的同源策略，在 h.com 上無法獲取屬于 a.com 的 cookie），
所以無法構(gòu)造出 token。
至于加 MD5當(dāng)然是因為我們不會傻的把登錄憑證 sid 放到 url 上給人直接拿了登錄- -（以前還真有人干過），為什么要加 鹽 salt 則是怕簡單的一層
MD5還是有可能被通過撞庫的方式解出 sid，當(dāng)然加了 salt 也不意味著100%防住，只是大大提高了破解的成本而已。
從上面我們知道防住 CSRF 最關(guān)鍵的是要守住 cookie，如果用戶的 cookie 被人竊取了，那上面的防護就形同虛設(shè)了。而 XSS 就可以很輕易的獲取用戶的 cookie，
所以有句話叫Buy one XSS, get a CSRF for free。
用戶輸入的內(nèi)容原封不動的通過服務(wù)器程序渲染在頁面上 。
反射型舉個栗子
前端get一個請求：
www.a.com/xss.php?name=userA
后臺處理:
代碼本意是根據(jù)queryString 的 name 來動態(tài)展示用戶名，但由于未對 name 做編碼校驗，當(dāng)鏈接為：
www.a.com?xss.php?name=
這時訪問這個鏈接則會彈出我們的 cookie 內(nèi)容，如果這時候再把 alert 改為一個發(fā)送函數(shù)，則可把 cookie 偷走。
前端DOM-Based XSS如上，直接將用戶的輸出輸出到頁面標(biāo)簽中。
但是如果將鏈接中的內(nèi)容設(shè)置為
http://www.a.com/index.html?intro=
那我們的 cookie 又沒了。
持久型XSS也稱為存儲型 XSS，注入腳本跟 XSS 大同小異，只是腳本不是通過瀏覽器->服務(wù)器->瀏覽器這樣的反射方式，而是多發(fā)生在富文本編輯器、日志、留言、
配置系統(tǒng)等數(shù)據(jù)庫保存用戶輸入內(nèi)容的業(yè)務(wù)場景。即用戶的注入腳本保存到了數(shù)據(jù)庫里，其他用戶只要一訪問到都會中招。
前端get一個請求：
www.a.com/xss.php?name=
后臺處理:
前端請求的頁面：
這樣但凡請求了該頁面的都會被XSS攻擊到。
解決XSS從上面我們可以看出各種攻擊手段很重要的一點就是要獲取 cookie，有了 cookie 就相當(dāng)于獲取了我們用戶的身份信息，所以自然的我們要保護我們的 cookie。
在 cookie 里有個 HttpOnly 屬性可以讓頁面無法通過 JS 來讀寫 cookie。
res.cookie("a", "1", { expires: new Date(Date.now() + 900000), httpOnly: true });
開啟這個屬性后 document 將無法獲取 cookie。當(dāng)然這個方法也不是萬能的，我們的 cookie 還是會在 header 中，還是有其他手段去獲取 header 中的 cookie，
不過使用后我們還是提高了攻擊的成本。關(guān)鍵還是我們要不相信用戶的一切輸入，對編碼輸出在頁面中會破壞原有代碼（HTML、JavaScript甚至WML等）規(guī)則的特殊字符
以及對某些標(biāo)簽的某些屬性進行白名單檢查。
看個簡單例子：
請求：www.a.com/query?userId=123
功能是查詢userId為123的用戶出來，這個請求到我們服務(wù)端最后sql語句是這樣：
select * from users where userid=123
如果不做任何校驗，如果用戶輸入如下
123; DROP TABLE users;
嘎嘎，整個表就沒有了。
所以同樣的，還是那個原則，我們不能相信用戶的任何輸入，如果一個sql語句里包含了用戶輸入的內(nèi)容，那我們要對內(nèi)容做sql安全相關(guān)的過濾檢查。
同時，使用一些ORM工具，不使用拼湊字符串型的語句執(zhí)行方式。
總的來說，前端最重要的就是一個sessionId這個代表用戶身份的憑證，保護好這個憑證，同時利用同源策略以及自己加密token來識別用戶，最后以最惡意的眼光對待用戶的輸入，不要相信用戶的輸入。這樣就能屏蔽絕大部分常見的安全問題了。
WilsonLiu"s blog首發(fā)地址：http://blog.wilsonliu.cn
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/80066.html
摘要：新版本新版，是一次新的嘗試，可以看得出作者對中國開發(fā)的開源精神，也算是十分精良的設(shè)計啦。功能點豐富，技術(shù)選型也是給大家一次學(xué)習(xí)轉(zhuǎn)型的機會，一開始并沒有大面積使用組建，嵌套，大家集思廣益，相信將來越來越好。 @TOC 初次接觸Jeecg 最開始接觸 JEECG（非boot版本，那個時候springboot 好像也不是很流行，至少不是人盡皆知 老版地址，功能更豐富，系統(tǒng)更穩(wěn)定 ） ，第...
摘要：歡迎來我的個人站點性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動及頁面渲染優(yōu)化理論寫法對壓縮率的影響唯快不破應(yīng)用的個優(yōu)化步驟進階鵝廠大神用直出實現(xiàn)網(wǎng)頁瞬開緩存網(wǎng)頁性能管理詳解寫給后端程序員的緩存原理介紹年底補課緩存機制優(yōu)化動 歡迎來我的個人站點 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動 scroll 及頁面渲染優(yōu)化 理論 | HTML寫法...
摘要：歡迎來我的個人站點性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動及頁面渲染優(yōu)化理論寫法對壓縮率的影響唯快不破應(yīng)用的個優(yōu)化步驟進階鵝廠大神用直出實現(xiàn)網(wǎng)頁瞬開緩存網(wǎng)頁性能管理詳解寫給后端程序員的緩存原理介紹年底補課緩存機制優(yōu)化動 歡迎來我的個人站點 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動 scroll 及頁面渲染優(yōu)化 理論 | HTML寫法...
閱讀 3212·2023-04-25 18:43
閱讀 891·2021-11-24 09:39
閱讀 1361·2021-10-14 09:43
閱讀 3890·2021-09-22 15:58
閱讀 1899·2019-08-29 17:18
閱讀 409·2019-08-29 14:14
閱讀 3077·2019-08-29 13:01
閱讀 1614·2019-08-29 12:33
