日韩国产精品99成人不卡在线无毒|狠狠躁夜夜爽一级二级精品|亚洲日日噜噜孕妇中文字幕|日韩久草中文三级片

• 同源策略

• XSS

• CSRF

• SQL注入

• 點(diǎn)擊劫持

• window.opener 安全問(wèn)題

• 文件上傳漏洞

同源策略

如果兩個(gè) URL 的協(xié)議、域名和端口都相同，我們就稱(chēng)這兩個(gè) URL 同源。

• 同源策略限制了來(lái)自不同源的 JavaScript 腳本對(duì)當(dāng)前 DOM 對(duì)象讀和寫(xiě)的操作。

• 同源策略限制了不同源的站點(diǎn)讀取當(dāng)前站點(diǎn)的 Cookie、IndexDB、LocalStorage 等數(shù)據(jù)。

• 同源策略限制了通過(guò) XMLHttpRequest 等方式將站點(diǎn)的數(shù)據(jù)發(fā)送給不同源的站點(diǎn)。

解決同源策略的方法：

• 跨文檔消息機(jī)制:  可以通過(guò) window.postMessage 的 JavaScript 接口來(lái)和不同源的 DOM 進(jìn)行通信。

• 跨域資源共享（CORS）:   跨域資源在服務(wù)端設(shè)置允許跨域，就可以進(jìn)行跨域訪問(wèn)控制，從而使跨域數(shù)據(jù)傳輸?shù)靡园踩M(jìn)行。

• 內(nèi)容安全策略（CSP）:  主要以白名單的形式配置可信任的內(nèi)容來(lái)源，在網(wǎng)頁(yè)中，能夠使白名單中的內(nèi)容正常執(zhí)行（包含 JS，CSS，Image 等等），而非白名單的內(nèi)容無(wú)法正常執(zhí)行。

XSS，跨站腳本攻擊(Cross Site Scripting)

存儲(chǔ)型 XSS 攻擊

利用漏洞提交惡意 JavaScript 代碼，比如在input, textarea等所有可能輸入文本信息的區(qū)域，輸入<script src="http://惡意網(wǎng)站"></script>等，提交后信息會(huì)存在服務(wù)器中，當(dāng)用戶(hù)再次打開(kāi)網(wǎng)站請(qǐng)求到相應(yīng)的數(shù)據(jù)，打開(kāi)頁(yè)面，惡意腳本就會(huì)將用戶(hù)的 Cookie 信息等數(shù)據(jù)上傳到黑客服務(wù)器。

反射型 XSS 攻擊

用戶(hù)將一段含有惡意代碼的請(qǐng)求提交給 Web 服務(wù)器，Web 服務(wù)器接收到請(qǐng)求時(shí)，又將惡意代碼反射給了瀏覽器端，這就是反射型 XSS 攻擊。
在現(xiàn)實(shí)生活中，黑客經(jīng)常會(huì)通過(guò) QQ 群或者郵件等渠道誘導(dǎo)用戶(hù)去點(diǎn)擊這些惡意鏈接，所以對(duì)于一些鏈接我們一定要慎之又慎。

Web 服務(wù)器不會(huì)存儲(chǔ)反射型 XSS 攻擊的惡意腳本，這是和存儲(chǔ)型 XSS 攻擊不同的地方。

基于 DOM 的 XSS 攻擊

基于 DOM 的 XSS 攻擊是不牽涉到頁(yè)面 Web 服務(wù)器的。它的特點(diǎn)是在 Web 資源傳輸過(guò)程或者在用戶(hù)使用頁(yè)面的過(guò)程中修改 Web 頁(yè)面的數(shù)據(jù)。比如利用工具(如Burpsuite)掃描目標(biāo)網(wǎng)站所有的網(wǎng)頁(yè)并自動(dòng)測(cè)試寫(xiě)好的注入腳本等。

預(yù)防策略：

1. 將cookie等敏感信息設(shè)置為httponly，禁止Javascript通過(guò)document.cookie獲得

2. 對(duì)所有的輸入做嚴(yán)格的校驗(yàn)尤其是在服務(wù)器端，過(guò)濾掉任何不合法的輸入，比如手機(jī)號(hào)必須是數(shù)字，通常可以采用正則表達(dá)式.

3. 凈化和過(guò)濾掉不必要的html標(biāo)簽，比如：<iframe>, <script>等 ;凈化和過(guò)濾掉不必要的Javascript的事件標(biāo)簽，比如：onclick, onfocus等

4. 轉(zhuǎn)義單引號(hào)，雙引號(hào)，尖括號(hào)等特殊字符，可以采用htmlencode編碼 或者過(guò)濾掉這些特殊字符

5. CSP，全稱(chēng)為 Content Security Policy，即內(nèi)容安全策略。主要以白名單的形式配置可信任的內(nèi)容來(lái)源，在網(wǎng)頁(yè)中，能夠使白名單中的內(nèi)容正常執(zhí)行（包含 JS，CSS，Image 等等），而非白名單的內(nèi)容無(wú)法正常執(zhí)行，從而減少跨站腳本攻擊（XSS），當(dāng)然，也能夠減少運(yùn)營(yíng)商劫持的內(nèi)容注入攻擊。
   配置方式：

//1、meta

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

//2、Http 頭部

Content-Security-Policy:
script-src 'unsafe-inline' 'unsafe-eval' 'self' *.54php.cn *.yunetidc.com *.baidu.com *.# *.duoshuo.com *.jiathis.com;report-uri /error/csp

CSRF，跨站請(qǐng)求偽造(Cross-site request forgery)

引誘用戶(hù)打開(kāi)黑客的網(wǎng)站，在黑客的網(wǎng)站中，利用用戶(hù)的登錄狀態(tài)發(fā)起的跨站請(qǐng)求。

發(fā)起 CSRF 攻擊的三個(gè)必要條件：

1. 目標(biāo)站點(diǎn)一定要有 CSRF 漏洞；

2. 用戶(hù)要登錄過(guò)目標(biāo)站點(diǎn)，并且在瀏覽器上保持有該站點(diǎn)的登錄狀態(tài)；

3. 需要用戶(hù)打開(kāi)一個(gè)第三方站點(diǎn)，如黑客的站點(diǎn)等。

預(yù)防策略：

1. 充分利用好 Cookie 的 SameSite 屬性。

SameSite 選項(xiàng)通常有 Strict、Lax 和 None 三個(gè)值。

• SameSite 的值是 Strict，那么瀏覽器會(huì)完全禁止第三方 Cookie。

• Lax 相對(duì)寬松一點(diǎn)。在跨站點(diǎn)的情況下，從第三方站點(diǎn)的鏈接打開(kāi)和從第三方站點(diǎn)提交 Get 方式的表單這兩種方式都會(huì)攜帶 Cookie。但如果在第三方站點(diǎn)中使用 Post 方法，或者通過(guò) img、iframe 等標(biāo)簽加載的 URL，這些場(chǎng)景都不會(huì)攜帶 Cookie。

• 而如果使用 None 的話，在任何情況下都會(huì)發(fā)送 Cookie 數(shù)據(jù)。如：

set-cookie: 1P_JAR=2019-10-20-06; expires=Tue, 19-Nov-2019 06:36:21 GMT; path=/; domain=.google.com; SameSite=none

1. 驗(yàn)證請(qǐng)求的來(lái)源站點(diǎn)

在服務(wù)器端驗(yàn)證請(qǐng)求來(lái)源的站點(diǎn)，就是驗(yàn)證 HTTP 請(qǐng)求頭中的 Origin 和 Referer 屬性。Referer 是 HTTP 請(qǐng)求頭中的一個(gè)字段，記錄了該 HTTP 請(qǐng)求的來(lái)源地址，而O rigin 屬性只包含了域名信息，并沒(méi)有包含具體的 URL 路徑。這是 Origin 和 Referer 的一個(gè)主要區(qū)別。

服務(wù)器的策略是優(yōu)先判斷 Origin，如果請(qǐng)求頭中沒(méi)有包含 Origin 屬性，再根據(jù)實(shí)際情況判斷是否使用 Referer 值。

1. 在請(qǐng)求地址中添加 token 并驗(yàn)證

CSRF 攻擊之所以能夠成功，是因?yàn)楹诳涂梢酝耆珎卧煊脩?hù)的請(qǐng)求，該請(qǐng)求中所有的用戶(hù)驗(yàn)證信息都是存在于 cookie 中，因此黑客可以在不知道這些驗(yàn)證信息的情況下直接利用用戶(hù)自己的 cookie 來(lái)通過(guò)安全驗(yàn)證。因此要抵御 CSRF，關(guān)鍵在于在請(qǐng)求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中。可以在 HTTP 請(qǐng)求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的 token，并在服務(wù)器端建立一個(gè)攔截器來(lái)驗(yàn)證這個(gè) token，如果請(qǐng)求中沒(méi)有 token 或者 token 內(nèi)容不正確，則認(rèn)為可能是 CSRF 攻擊而拒絕該請(qǐng)求。

1. 在 HTTP 頭中自定義屬性并驗(yàn)證

這種方法也是使用 token 并進(jìn)行驗(yàn)證，和上一種方法不同的是，這里并不是把 token 以參數(shù)的形式置于 HTTP 請(qǐng)求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過(guò) XMLHttpRequest 這個(gè)類(lèi)，可以一次性給所有該類(lèi)請(qǐng)求加上 csrftoken 這個(gè) HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請(qǐng)求中加入 token 的不便，同時(shí)，通過(guò) XMLHttpRequest 請(qǐng)求的地址不會(huì)被記錄到瀏覽器的地址欄，也不用擔(dān)心 token 會(huì)透過(guò) Referer 泄露到其他網(wǎng)站中去。

然而這種方法的局限性非常大。XMLHttpRequest 請(qǐng)求通常用于 Ajax 方法中對(duì)于頁(yè)面局部的異步刷新，并非所有的請(qǐng)求都適合用這個(gè)類(lèi)來(lái)發(fā)起，而且通過(guò)該類(lèi)請(qǐng)求得到的頁(yè)面不能被瀏覽器所記錄下，從而進(jìn)行前進(jìn)，后退，刷新，收藏等操作，給用戶(hù)帶來(lái)不便。另外，對(duì)于沒(méi)有進(jìn)行 CSRF 防護(hù)的遺留系統(tǒng)來(lái)說(shuō)，要采用這種方法來(lái)進(jìn)行防護(hù)，要把所有請(qǐng)求都改為 XMLHttpRequest 請(qǐng)求，這樣幾乎是要重寫(xiě)整個(gè)網(wǎng)站，這代價(jià)無(wú)疑是不能接受的。

SQL注入

拼接 SQL 時(shí)未仔細(xì)過(guò)濾，黑客可提交畸形數(shù)據(jù)改變語(yǔ)義。比如查某個(gè)文章，提交了這樣的數(shù)據(jù)id=-1 or 1=1等。1=1 永遠(yuǎn)是true，導(dǎo)致where語(yǔ)句永遠(yuǎn)是ture.那么查詢(xún)的結(jié)果相當(dāng)于整張表的內(nèi)容，攻擊者就達(dá)到了目的。或者，通過(guò)屏幕上的報(bào)錯(cuò)提示推測(cè) SQL 語(yǔ)句等。

預(yù)防策略：

1. 禁止目標(biāo)網(wǎng)站利用動(dòng)態(tài)拼接字符串的方式訪問(wèn)數(shù)據(jù)庫(kù)

2. 減少不必要的數(shù)據(jù)庫(kù)拋出的錯(cuò)誤信息

3. 對(duì)數(shù)據(jù)庫(kù)的操作賦予嚴(yán)格的權(quán)限控制

4. 凈化和過(guò)濾掉不必要的SQL保留字，比如：where, or, exec 等

點(diǎn)擊劫持

• 誘使用戶(hù)點(diǎn)擊看似無(wú)害的按鈕（實(shí)則點(diǎn)擊了透明 iframe 中的按鈕）.

• 監(jiān)聽(tīng)鼠標(biāo)移動(dòng)事件，讓危險(xiǎn)按鈕始終在鼠標(biāo)下方.

• 使用 HTML5 拖拽技術(shù)執(zhí)行敏感操作（例如 deploy key）.

預(yù)防策略：

1. 服務(wù)端添加 X-Frame-Options 響應(yīng)頭,這個(gè) HTTP 響應(yīng)頭是為了防御用 iframe 嵌套的點(diǎn)擊劫持攻擊。這樣瀏覽器就會(huì)阻止嵌入網(wǎng)頁(yè)的渲染。

2. JS 判斷頂層視口的域名是不是和本頁(yè)面的域名一致，不一致則不允許操作，top.location.hostname === self.location.hostname；

3. 敏感操作使用更復(fù)雜的步驟（驗(yàn)證碼、輸入項(xiàng)目名稱(chēng)以刪除）。

window.opener 安全問(wèn)題

window.opener 表示打開(kāi)當(dāng)前窗體頁(yè)面的的父窗體的是誰(shuí)。例如，在 A 頁(yè)面中，通過(guò)一個(gè)帶有 target="_blank" 的 a 標(biāo)簽打開(kāi)了一個(gè)新的頁(yè)面 B，那么在 B 頁(yè)面里，window.opener 的值為 A 頁(yè)面的 window 對(duì)象。

一般來(lái)說(shuō)，打開(kāi)同源(域名相同)的頁(yè)面，不會(huì)有什么問(wèn)題。但對(duì)于跨域的外部鏈接來(lái)說(shuō)，存在一個(gè)被釣魚(yú)的風(fēng)險(xiǎn)。比如你正在瀏覽購(gòu)物網(wǎng)站，從當(dāng)前網(wǎng)頁(yè)打開(kāi)了某個(gè)外部鏈接，在打開(kāi)的外部頁(yè)面，可以通過(guò) window.opener.location 改寫(xiě)來(lái)源站點(diǎn)的地址。利用這一點(diǎn)，將來(lái)源站點(diǎn)改寫(xiě)到釣魚(yú)站點(diǎn)頁(yè)面上，例如跳轉(zhuǎn)到偽造的高仿購(gòu)物頁(yè)面，當(dāng)再回到購(gòu)物頁(yè)面的時(shí)候，是很難發(fā)現(xiàn)購(gòu)物網(wǎng)站的地址已經(jīng)被修改了的，這個(gè)時(shí)候你的賬號(hào)就存在被釣魚(yú)的可能了。

預(yù)防策略：

1. 設(shè)置 rel 屬性

<a href="https://xxxx" rel="noopener noreferrer"> 外鏈 <a>

rel=noopener 規(guī)定禁止新頁(yè)面?zhèn)鬟f源頁(yè)面的地址，通過(guò)設(shè)置了此屬性的鏈接打開(kāi)的頁(yè)面，其 window.opener 的值為 null。

1. 將外鏈替換為內(nèi)部的跳轉(zhuǎn)連接服務(wù)，跳轉(zhuǎn)時(shí)先跳到內(nèi)部地址，再由服務(wù)器 redirect 到外鏈。

2. 可以由 widow.open 打開(kāi)外鏈。

文件上傳漏洞

服務(wù)器未校驗(yàn)上傳的文件，致使黑客可以上傳惡意腳本等方式。

預(yù)防策略：

1. 用文件頭來(lái)檢測(cè)文件類(lèi)型，使用白名單過(guò)濾(有些文件可以從其中一部分執(zhí)行，只檢查文件頭無(wú)效，例如 PHP 等腳本語(yǔ)言)；

2. 上傳后將文件徹底重命名并移動(dòng)到不可執(zhí)行的目錄下；

3. 升級(jí)服務(wù)器軟件以避免路徑解析漏洞；

4. 升級(jí)用到的開(kāi)源編輯器；

5. 管理后臺(tái)設(shè)置強(qiáng)密碼。