提到這個(gè)我可能想到的就是不要暴露太多的賬號(hào)密碼信息。一些頁(yè)面的請(qǐng)求和操作要加上權(quán)限。

然后下面就詳細(xì)的介紹前端可能遇到的安全問(wèn)題以及解決方法。

首先比較常見(jiàn)的前端的安全性問(wèn)題就是跨站腳本攻擊（XSS）?？缯菊?qǐng)求偽造（csrf）

跨站腳本攻擊（XSS）

攻擊者通過(guò)在目標(biāo)網(wǎng)站上注入惡意腳本，使之在用戶的瀏覽器上運(yùn)行。利用這些惡意腳本，攻擊者可獲取用戶的敏感信息如 Cookie、SessionID 等，進(jìn)而危害數(shù)據(jù)安全。

比如：客將惡意?JavaScript?腳本長(zhǎng)期保存在服務(wù)端數(shù)據(jù)庫(kù)中，用戶一旦訪問(wèn)相關(guān)頁(yè)面數(shù)據(jù)，惡意腳本就會(huì)被執(zhí)行。常見(jiàn)于搜索、微博、社區(qū)貼吧評(píng)論等。

2011年新浪微博曾被黑客 XSS 攻擊，黑客誘導(dǎo)用戶點(diǎn)擊一個(gè)帶有誘惑性的鏈接，便會(huì)自動(dòng)發(fā)送一條帶有同樣誘惑性鏈接微博。攻擊范圍層層擴(kuò)大，也是一種蠕蟲(chóng)攻擊。

XSS攻擊主要有兩大步驟：

• 攻擊者提交惡意代碼
• 瀏覽器執(zhí)行惡意代碼

解決辦法：

在使用 .innerHTML、.outerHTML、document.write() 時(shí)要特別小心，不要把不可信的數(shù)據(jù)作為 HTML 插到頁(yè)面上，而應(yīng)盡量使用 .textContent、.setAttribute() 等。

如果用 Vue/React 技術(shù)棧，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 階段避免 innerHTML、outerHTML 的 XSS 隱患。

DOM 中的內(nèi)聯(lián)事件監(jiān)聽(tīng)器，如 location、onclick、onerror、onload、onmouseover 等，<a> 標(biāo)簽的 href 屬性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作為代碼運(yùn)行。如果不可信的數(shù)據(jù)拼接到字符串中傳遞給這些 API，很容易產(chǎn)生安全隱患，請(qǐng)務(wù)必避免。

• 使用 W3C 提出的?CSP (Content Security Policy，內(nèi)容安全策略)，定義域名白名單

• 設(shè)置?Cookie 的 HttpOnly?屬性，禁止JavaScript讀取cookie
• 驗(yàn)證碼：防止腳本冒充用戶提交危險(xiǎn)操作。

跨站請(qǐng)求偽造（CSRF）

攻擊者誘導(dǎo)受害者進(jìn)入第三方網(wǎng)站，在第三方網(wǎng)站中，向被攻擊網(wǎng)站發(fā)送跨站請(qǐng)求。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊(cè)憑證，繞過(guò)后臺(tái)的用戶驗(yàn)證，達(dá)到冒充用戶對(duì)被攻擊的網(wǎng)站執(zhí)行某項(xiàng)操作的目的。

典型的CSRF攻擊是這樣的：

受害者登錄A網(wǎng)站，并且保留了登錄憑證（Cookie）
攻擊者引誘受害者訪問(wèn)B網(wǎng)站
B網(wǎng)站向A網(wǎng)站發(fā)送了一個(gè)請(qǐng)求，瀏覽器請(qǐng)求頭中會(huì)默認(rèn)攜帶 A 網(wǎng)站的 Cookie
A 網(wǎng)站服務(wù)器收到請(qǐng)求后，經(jīng)過(guò)驗(yàn)證發(fā)現(xiàn)用戶是登錄了的，所以會(huì)處理請(qǐng)求

例子1： <img src="http://bank.example/withdraw?amount=10000&for=hacker" >?
在受害者訪問(wèn)含有這個(gè)img的頁(yè)面后，瀏覽器會(huì)自動(dòng)向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker發(fā)出一次HTTP請(qǐng)求。bank.example就會(huì)收到包含受害者登錄信息的一次跨域請(qǐng)求

例子2：訪問(wèn)該頁(yè)面后，表單會(huì)自動(dòng)提交，相當(dāng)于模擬用戶完成了一次POST操作

<form action="http://bank.example/withdraw" method=POST>
? ? <input type="hidden" name="account" value="xiaoming" />
? ? <input type="hidden" name="amount" value="10000" />
? ? <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>?

• 攻擊一般發(fā)起在第三方網(wǎng)站，而不是被攻擊的網(wǎng)站。被攻擊的網(wǎng)站無(wú)法防止攻擊發(fā)生。
• 攻擊利用受害者在被攻擊網(wǎng)站的登錄憑證，冒充受害者提交操作；而不是直接竊取數(shù)據(jù)。
• 整個(gè)過(guò)程攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”。

解決辦法:

同源檢測(cè):既然CSRF大多來(lái)自第三方網(wǎng)站，那么我們就直接禁止第三方域名（或者不受信任的域名）對(duì)我們發(fā)起請(qǐng)求。?

表單請(qǐng)求攜帶CSRF Token：在瀏覽器向服務(wù)器發(fā)起請(qǐng)求時(shí)，服務(wù)器生成一個(gè) CSRF Token。CSRF Token 其實(shí)就是服務(wù)器生成的隨機(jī)字符串，然后將該字符串植入到返回的頁(yè)面中，通常是放到表單的隱藏輸入框中，這樣能夠很好的保護(hù) CSRF Token 不被泄漏；
當(dāng)瀏覽器再次發(fā)送請(qǐng)求的時(shí)候，就需要攜帶這個(gè) CSRF Token 值一起提交；
服務(wù)器驗(yàn)證 CSRF Token 是否一致；從第三方網(wǎng)站發(fā)出的請(qǐng)求是無(wú)法獲取用戶頁(yè)面中的 CSRF Token 值的。

點(diǎn)擊劫持（ClickJacking）

點(diǎn)擊劫持（Clickjacking）是一種通過(guò)視覺(jué)欺騙的手段來(lái)達(dá)到攻擊目的手段。往往是攻擊者將目標(biāo)網(wǎng)站通過(guò) iframe 嵌入到自己的網(wǎng)頁(yè)中，通過(guò) opacity 等手段設(shè)置 iframe 為透明的，使得肉眼不可見(jiàn)，這樣一來(lái)當(dāng)用戶在攻擊者的網(wǎng)站中操作的時(shí)候，比如點(diǎn)擊某個(gè)按鈕（這個(gè)按鈕的頂層其實(shí)是 iframe），從而實(shí)現(xiàn)目標(biāo)網(wǎng)站被點(diǎn)擊劫持。

解決辦法：

判斷當(dāng)前網(wǎng)頁(yè)是否被 iframe 嵌套。如果有嵌套就讓他跳轉(zhuǎn)到原本的頁(yè)面

加代碼

if(selft===top){

? ? var theBody=document.getElementByTagName('body')[0];

? ? ?theBody.style.display='block';

}else{

? ? ?top.location=self.location;

}

也可以在你的服務(wù)器配置中設(shè)置X-Frame-Options

CDN劫持

讓用戶自動(dòng)轉(zhuǎn)入自己開(kāi)發(fā)的網(wǎng)站。而很多用戶卻往往無(wú)法察覺(jué)到自己已經(jīng)被劫持。其實(shí)驗(yàn)證被劫持的方法，就是輸入任何網(wǎng)址看看所打開(kāi)的網(wǎng)頁(yè)是否和自己輸入的網(wǎng)址一致，

解決辦法：

使用SRI來(lái)解決CDN劫持。SRI?全稱 Subresource Integrity - 子資源完整性，是指瀏覽器通過(guò)驗(yàn)證資源的完整性（通常從 CDN 獲取）來(lái)判斷其是否被篡改的安全特性。

通過(guò)給 link 標(biāo)簽或者 script 標(biāo)簽增加 integrity 屬性即可開(kāi)啟 SRI 功能，比如

<script type="text/javascript" src="//s.url.cn/xxxx/aaa.js"?
? ? integrity="sha256-xxx sha384-yyy"
? ? crossorigin="anonymous"></script>
integrity 值分成兩個(gè)部分，第一部分指定哈希值的生成算法（sha256、sha384 及 sha512），第二部分是經(jīng)過(guò) base64 編碼的實(shí)際哈希值，兩者之間通過(guò)一個(gè)短橫（-）分割。integrity 值可以包含多個(gè)由空格分隔的哈希值，只要文件匹配其中任意一個(gè)哈希值，就可以通過(guò)校驗(yàn)并加載該資源。開(kāi)啟 SRI 能有效保證頁(yè)面引用資源的完整性，避免惡意代碼執(zhí)行。
?

SQL注入（更偏向后端處理）

web應(yīng)用程序?qū)τ脩糨斎霐?shù)據(jù)的合法性沒(méi)有判斷或過(guò)濾不嚴(yán)，攻擊者可以在web應(yīng)用程序中事先定義好的查詢語(yǔ)句的結(jié)尾上添加額外的SQL語(yǔ)句，在管理員不知情的情況下實(shí)現(xiàn)非法操作，以此來(lái)實(shí)現(xiàn)欺騙數(shù)據(jù)庫(kù)服務(wù)器執(zhí)行非授權(quán)的任意查詢，從而進(jìn)一步得到相應(yīng)的數(shù)據(jù)信息。?

?解決辦法：

1、分級(jí)管理

對(duì)用戶進(jìn)行分級(jí)管理，嚴(yán)格控制用戶的權(quán)限，對(duì)于普通用戶，禁止給予數(shù)據(jù)庫(kù)建立、刪除、修改等相關(guān)權(quán)限，只有系統(tǒng)管理員才具有增、刪、改、查的權(quán)限。

2、參數(shù)傳值

在書寫SQL語(yǔ)言時(shí)，禁止將變量直接寫入到SQL語(yǔ)句，必須通過(guò)設(shè)置相應(yīng)的參數(shù)來(lái)傳遞相關(guān)的變量。從而抑制SQL注入。數(shù)據(jù)輸入不能直接嵌入到查詢語(yǔ)句中。同時(shí)要過(guò)濾輸入的內(nèi)容，過(guò)濾掉不安全的輸入數(shù)據(jù)?；蛘卟捎脜?shù)傳值的方式傳遞輸入變量。這樣可以最大程度防范SQL注入攻擊。