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