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