資訊專欄INFORMATION COLUMN
摘要：系列文章前端安全系列篇前端安全系列篇介紹跨站請求偽造，也被稱為或者，通?？s寫為或者，是一種對網(wǎng)站的惡意利用。
系列文章:
前端安全系列：XSS篇
前端安全系列：CSRF篇
CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通?？s寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。盡管聽起來像跨站腳本，但它與XSS非常不同，XSS利用站點內(nèi)的信任用戶，而CSRF則通過偽裝成受信任用戶的請求來利用受信任的網(wǎng)站。攻擊通過在授權(quán)用戶訪問的頁面中包含鏈接或者腳本的方式工作
CSRF攻擊一個典型的CSRF攻擊流程大概如下:
用戶登錄a.com并保留登錄信息
攻擊者引誘用戶訪問了b.com
b.com在用戶不知情的情況下向a.com發(fā)送請求并攜帶用戶的登錄信息
a.com接收請求驗證登錄信息通過執(zhí)行某些惡意操作
攻擊者在用戶不知情的情況下冒充用戶的身份完成了攻擊.
攻擊方式:
攻擊者的網(wǎng)站
有文件上傳漏洞的網(wǎng)站
第三方論壇,博客等網(wǎng)站
目標(biāo)網(wǎng)站自身的漏洞
相對XSS攻擊,CSRF攻擊不太一樣
一般攻擊發(fā)起點不在目標(biāo)網(wǎng)站,而是被引導(dǎo)到第三方網(wǎng)站再發(fā)起攻擊,這樣目標(biāo)網(wǎng)站就無法防止
攻擊者不能獲取到用戶Cookies,包括子域名,而是利用Cookies的特性冒充用戶身份進(jìn)行攻擊
通常是跨域攻擊,因為攻擊者更容易掌握第三方網(wǎng)站而不是只能利用目標(biāo)網(wǎng)站自身漏洞
攻擊方式包括圖片,URL,CORS,表單,甚至直接嵌入第三方論壇,文章等等,難以追蹤
常見的CSRF攻擊類型 GET請求例如利用隱藏圖片自動發(fā)起一個HTTP請求,會自動附帶用戶cookies
POST請求例如利用隱藏表單自動提交
URL攻擊比較常見的利誘廣告方式或者冒充QQ病毒警告等引誘用戶自己點擊
一刀9999級,神級裝備,頂級神寵,開服就有??！防御
針對CSRF的特點,我們可以制定策略
限制訪問名單 同源檢測HTTP協(xié)議中一般會攜帶兩個帶有來源信息的字段:
Origin指示了請求來自于哪個站點。該字段僅指示服務(wù)器名稱，并不包含任何路徑信息, 用于 CORS 請求或者 POST 請求。Origin在以下兩種情況下并不存在：
IE 11 不會在跨站CORS請求上添加Origin標(biāo)頭
302重定向之后Origin不包含在重定向的請求中，因為Origin可能會被認(rèn)為是其他來源的敏感信息。對于302重定向的情況來說都是定向到新的服務(wù)器上的URL，因此瀏覽器不想將Origin泄漏到新的服務(wù)器上。
Referer包含了當(dāng)前請求頁面的來源頁面的地址，即表示當(dāng)前頁面是通過此來源頁面里的鏈接進(jìn)入的。服務(wù)端一般使用 Referer 首部識別訪問來源，可能會以此進(jìn)行統(tǒng)計分析、日志記錄以及緩存優(yōu)化等。
對于Ajax請求，圖片和script等資源請求，Referer為發(fā)起請求的頁面地址。
對于頁面跳轉(zhuǎn)，Referer為打開頁面歷史記錄的前一個頁面地址
在以下情況下，Referer 不會被發(fā)送：
來源頁面采用的協(xié)議為表示本地文件的 "file" 或者 "data" URI
當(dāng)前請求頁面采用的是非安全協(xié)議，而來源頁面采用的是安全協(xié)議（HTTPS）
雖然HTTP有明確要求,也有Referrer Policy草案對瀏覽器如何發(fā)送做了詳細(xì)規(guī)定,但是瀏覽器實現(xiàn)可能有差別,不能保障安全性.低版本瀏覽器,Flash等情況可能丟失或不可信,新的Referrer規(guī)定了五種策略：
| States | 作用 |
|---|---|
| no-Referrer | 任何情況下都不發(fā)送Referrer信息 |
| no-Referrer-when-downgrade | 僅當(dāng)協(xié)議降級（如HTTPS頁面引入HTTP資源）時不發(fā)送Referrer信息。是大部分瀏覽器默認(rèn)策略 |
| origin | 發(fā)送只包含host部分的referrer. |
| origin-when-cross-origin | 僅在發(fā)生跨域訪問時發(fā)送只包含host的Referer，同域下還是完整的。與Origin Only的區(qū)別是多判斷了是否Cross-origin。協(xié)議、域名和端口都一致，瀏覽器才認(rèn)為是同域 |
| unsafe-url | 全部都發(fā)送Referrer信息。最寬松最不安全的策略 |
設(shè)置Referrer Policy的方法有:
在HTTP的CSP（Content Security Policy）設(shè)置
Content-Security-Policy: referrer no-referrer|no-referrer-when-downgrade|origin|origin-when-cross-origin|unsafe-url;
頁面頭部增加meta標(biāo)簽, 默認(rèn)no-referer策略
a標(biāo)簽增加Referrer Policy屬性,只支持三種
xxx
發(fā)起請求的來源域名可能是網(wǎng)站本域，或者子域名，或者有授權(quán)的第三方域名，又或者來自不可信的未知域名。業(yè)務(wù)上需要針對各種情況作出過濾規(guī)則,一般優(yōu)先使用Origin確認(rèn)來源信息就夠了,Referrer 變數(shù)太多比較適合打輔助.但是如果兩者都獲取不到的情況下,建議直接進(jìn)行阻止.
同源規(guī)則能簡單防范大多數(shù)CSRF攻擊,配合關(guān)鍵接口做額外處理能更好提高安全性.
SameSite一種新的防止跨站點請求偽造（cross site request forgery）的 http 安全特性。該值可以設(shè)置為 Strict 或 Lax,現(xiàn)階段只有部分主流瀏覽器支持,僅做了解即可
Set-Cookie: key=value; SameSite=Strict/Lax
Strict: 跨域請求或者新標(biāo)簽重新打開都不會攜帶該Cokies
Lax: 這個請求是（改變了當(dāng)前頁面或者打開了新頁面）且同時是個GET請求，則攜帶。
還有一個比較嚴(yán)重的問題是SameSite不支持子域名.
附加驗證 驗證碼通過圖形驗證碼或者手機(jī)驗證碼或者郵箱驗證等多種方式強(qiáng)制用戶進(jìn)行交互可以有效遏制CSRF攻擊,缺點是步驟比較繁瑣,只適用于如涉及金額,密碼相關(guān)等關(guān)鍵請求,
CSRF Token基于攻擊者無法獲得用戶信息的特性,我們可以在前后端交互中攜帶一個有效驗證“令牌”來防范CSRF攻擊,大概流程:
當(dāng)用戶首次登錄成功之后, 服務(wù)端會生成一個唯一性和隨機(jī)性的 token 值保存在服務(wù)器的Session或者其他緩存系統(tǒng)中，再將這個token值返回給瀏覽器；
瀏覽器拿到 token 值之后本地保存；
當(dāng)瀏覽器再次發(fā)送網(wǎng)絡(luò)請求的時候,就會將這個 token 值附帶到參數(shù)中(或者通過Header頭)發(fā)送給服務(wù)端；
服務(wù)端接收到瀏覽器的請求之后,會取出token值與保存在服務(wù)器的Session的token值做對比驗證其正確性和有效期。
在大型網(wǎng)站一般使用多臺服務(wù)器,用戶請求經(jīng)過負(fù)載均衡器路由到具體的服務(wù)器上,如果使用Session默認(rèn)儲存在單機(jī)服務(wù)器內(nèi)存中,在分布式環(huán)境下同一用戶的多次請求可能會指向不同的服務(wù)器上,而其他的服務(wù)器無法共享Session導(dǎo)致Session機(jī)制失效無法驗證,所以分布式集群中Token需要儲存在Redis等公共儲存空間.
因為讀取和驗證Token會有復(fù)雜度和性能的問題,還有種方式采用Encrypted Token Pattern方式,通常是使用UserID、時間戳和隨機(jī)數(shù)，通過加密的方法生成而非隨機(jī)性,之后請求校驗不需要讀取而是直接計算即可,這樣既可以保證分布式服務(wù)的Token一致，又能保證Token不容易被破解。
雙重Cookie驗證相較于CSRF Token,這種方式比較簡單實現(xiàn)但是安全性較低.大概流程:
用戶訪問頁面之后域名被注入隨機(jī)字符串Cookie
瀏覽器發(fā)起請求時會取出該Cookie字符串添加到URL參數(shù)中
服務(wù)端驗證是否一致
沒有大規(guī)模應(yīng)用除了安全性問題還有一個就是跨域可能導(dǎo)致獲取不到Cookie.
用戶訪問網(wǎng)站域名www.test.com,服務(wù)端api域名api.test.com,
如果想要共用Cookie就必須注入到test.com,然后子域名都能獲取到
同理每個子域名都能修改該Cookie,如果某個子域名被攻擊了
攻擊者可以自己配置一個Cookie破解雙重Cookie驗證機(jī)制攔截
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/106423.html
摘要：面試網(wǎng)絡(luò)了解及網(wǎng)絡(luò)基礎(chǔ)對端傳輸詳解與攻防實戰(zhàn)本文從屬于筆者的信息安全實戰(zhàn)中滲透測試實戰(zhàn)系列文章。建議先閱讀下的網(wǎng)絡(luò)安全基礎(chǔ)。然而，該攻擊方式并不為大家所熟知，很多網(wǎng)站都有的安全漏洞。 面試 -- 網(wǎng)絡(luò) HTTP 現(xiàn)在面試門檻越來越高，很多開發(fā)者對于網(wǎng)絡(luò)知識這塊了解的不是很多，遇到這些面試題會手足無措。本篇文章知識主要集中在 HTTP 這塊。文中知識來自 《圖解 HTTP》與維基百科，若...
摘要：應(yīng)用常見安全漏洞一覽注入注入就是通過給應(yīng)用接口傳入一些特殊字符，達(dá)到欺騙服務(wù)器執(zhí)行惡意的命令。此外，適當(dāng)?shù)臋?quán)限控制不曝露必要的安全信息和日志也有助于預(yù)防注入漏洞。 web 應(yīng)用常見安全漏洞一覽 1. SQL 注入 SQL 注入就是通過給 web 應(yīng)用接口傳入一些特殊字符，達(dá)到欺騙服務(wù)器執(zhí)行惡意的 SQL 命令。 SQL 注入漏洞屬于后端的范疇，但前端也可做體驗上的優(yōu)化。 原因 當(dāng)使用外...
摘要：應(yīng)用常見安全漏洞一覽注入注入就是通過給應(yīng)用接口傳入一些特殊字符，達(dá)到欺騙服務(wù)器執(zhí)行惡意的命令。此外，適當(dāng)?shù)臋?quán)限控制不曝露必要的安全信息和日志也有助于預(yù)防注入漏洞。 web 應(yīng)用常見安全漏洞一覽 1. SQL 注入 SQL 注入就是通過給 web 應(yīng)用接口傳入一些特殊字符，達(dá)到欺騙服務(wù)器執(zhí)行惡意的 SQL 命令。 SQL 注入漏洞屬于后端的范疇，但前端也可做體驗上的優(yōu)化。 原因 當(dāng)使用外...
摘要：然而在最近的面試中通過學(xué)習(xí)和思考，找到了前進(jìn)的方向，也得到一些大公司的錄用機(jī)會。算是從初級前端畢業(yè)，進(jìn)階了吧。在這里先寫個目錄。趕時間的同學(xué)可以按照我的目錄先自行準(zhǔn)備提升，希望推薦文章和交流。 背景 之前我分享了文章大廠前端面試考什么?,你們一定很想看答案吧？說實話，答案我是有，在準(zhǔn)備面試的時候會時不時翻看，但內(nèi)容比較多，比較凌亂，不能指望我在一篇文章中寫完。 我是從非計算機(jī)專業(yè)自學(xué)前...
閱讀 935·2023-04-26 00:37
閱讀 802·2021-11-24 09:39
閱讀 2235·2021-11-23 09:51
閱讀 3975·2021-11-22 15:24
閱讀 804·2021-10-19 11:46
閱讀 1918·2019-08-30 13:53
閱讀 2508·2019-08-29 17:28
閱讀 1401·2019-08-29 14:11
