国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

前端安全系列：CSRF篇

Java_oldboy / 3345人閱讀

摘要：系列文章前端安全系列篇前端安全系列篇介紹跨站請(qǐng)求偽造，也被稱為或者，通常縮寫為或者，是一種對(duì)網(wǎng)站的惡意利用。

系列文章:

前端安全系列：XSS篇
前端安全系列：CSRF篇

CSRF介紹

CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。盡管聽起來像跨站腳本，但它與XSS非常不同，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過偽裝成受信任用戶的請(qǐng)求來利用受信任的網(wǎng)站。攻擊通過在授權(quán)用戶訪問的頁面中包含鏈接或者腳本的方式工作

CSRF攻擊

一個(gè)典型的CSRF攻擊流程大概如下:

用戶登錄a.com并保留登錄信息

攻擊者引誘用戶訪問了b.com

b.com在用戶不知情的情況下向a.com發(fā)送請(qǐng)求并攜帶用戶的登錄信息

a.com接收請(qǐng)求驗(yàn)證登錄信息通過執(zhí)行某些惡意操作

攻擊者在用戶不知情的情況下冒充用戶的身份完成了攻擊.

攻擊方式:

攻擊者的網(wǎng)站

有文件上傳漏洞的網(wǎng)站

第三方論壇,博客等網(wǎng)站

目標(biāo)網(wǎng)站自身的漏洞

相對(duì)XSS攻擊,CSRF攻擊不太一樣

一般攻擊發(fā)起點(diǎn)不在目標(biāo)網(wǎng)站,而是被引導(dǎo)到第三方網(wǎng)站再發(fā)起攻擊,這樣目標(biāo)網(wǎng)站就無法防止

攻擊者不能獲取到用戶Cookies,包括子域名,而是利用Cookies的特性冒充用戶身份進(jìn)行攻擊

通常是跨域攻擊,因?yàn)楣粽吒菀渍莆盏谌骄W(wǎng)站而不是只能利用目標(biāo)網(wǎng)站自身漏洞

攻擊方式包括圖片,URL,CORS,表單,甚至直接嵌入第三方論壇,文章等等,難以追蹤

常見的CSRF攻擊類型 GET請(qǐng)求

例如利用隱藏圖片自動(dòng)發(fā)起一個(gè)HTTP請(qǐng)求,會(huì)自動(dòng)附帶用戶cookies


POST請(qǐng)求

例如利用隱藏表單自動(dòng)提交



    
    


 

URL攻擊

比較常見的利誘廣告方式或者冒充QQ病毒警告等引誘用戶自己點(diǎn)擊



  一刀9999級(jí),神級(jí)裝備,頂級(jí)神寵,開服就有！！


防御

針對(duì)CSRF的特點(diǎn),我們可以制定策略

限制訪問名單
同源檢測(cè)

HTTP協(xié)議中一般會(huì)攜帶兩個(gè)帶有來源信息的字段:

Origin

指示了請(qǐng)求來自于哪個(gè)站點(diǎn)。該字段僅指示服務(wù)器名稱，并不包含任何路徑信息, 用于 CORS 請(qǐng)求或者 POST 請(qǐng)求。Origin在以下兩種情況下并不存在：



IE 11 不會(huì)在跨站CORS請(qǐng)求上添加Origin標(biāo)頭


302重定向之后Origin不包含在重定向的請(qǐng)求中，因?yàn)镺rigin可能會(huì)被認(rèn)為是其他來源的敏感信息。對(duì)于302重定向的情況來說都是定向到新的服務(wù)器上的URL，因此瀏覽器不想將Origin泄漏到新的服務(wù)器上。


Referer

包含了當(dāng)前請(qǐng)求頁面的來源頁面的地址，即表示當(dāng)前頁面是通過此來源頁面里的鏈接進(jìn)入的。服務(wù)端一般使用 Referer 首部識(shí)別訪問來源，可能會(huì)以此進(jìn)行統(tǒng)計(jì)分析、日志記錄以及緩存優(yōu)化等。



對(duì)于Ajax請(qǐng)求，圖片和script等資源請(qǐng)求，Referer為發(fā)起請(qǐng)求的頁面地址。


對(duì)于頁面跳轉(zhuǎn)，Referer為打開頁面歷史記錄的前一個(gè)頁面地址



在以下情況下，Referer 不會(huì)被發(fā)送：



來源頁面采用的協(xié)議為表示本地文件的 "file" 或者 "data" URI


當(dāng)前請(qǐng)求頁面采用的是非安全協(xié)議，而來源頁面采用的是安全協(xié)議（HTTPS）



雖然HTTP有明確要求,也有Referrer Policy草案對(duì)瀏覽器如何發(fā)送做了詳細(xì)規(guī)定,但是瀏覽器實(shí)現(xiàn)可能有差別,不能保障安全性.低版本瀏覽器,Flash等情況可能丟失或不可信,新的Referrer規(guī)定了五種策略：





States
作用





no-Referrer
任何情況下都不發(fā)送Referrer信息




no-Referrer-when-downgrade
僅當(dāng)協(xié)議降級(jí)（如HTTPS頁面引入HTTP資源）時(shí)不發(fā)送Referrer信息。是大部分瀏覽器默認(rèn)策略




origin
發(fā)送只包含host部分的referrer.




origin-when-cross-origin
僅在發(fā)生跨域訪問時(shí)發(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ā)起請(qǐng)求的來源域名可能是網(wǎng)站本域，或者子域名，或者有授權(quán)的第三方域名，又或者來自不可信的未知域名。業(yè)務(wù)上需要針對(duì)各種情況作出過濾規(guī)則,一般優(yōu)先使用Origin確認(rèn)來源信息就夠了,Referrer 變數(shù)太多比較適合打輔助.但是如果兩者都獲取不到的情況下,建議直接進(jìn)行阻止.


同源規(guī)則能簡(jiǎn)單防范大多數(shù)CSRF攻擊,配合關(guān)鍵接口做額外處理能更好提高安全性.

SameSite

一種新的防止跨站點(diǎn)請(qǐng)求偽造（cross site request forgery）的 http 安全特性。該值可以設(shè)置為 Strict 或 Lax,現(xiàn)階段只有部分主流瀏覽器支持,僅做了解即可


Set-Cookie: key=value; SameSite=Strict/Lax



Strict: 跨域請(qǐng)求或者新標(biāo)簽重新打開都不會(huì)攜帶該Cokies


Lax: 這個(gè)請(qǐng)求是（改變了當(dāng)前頁面或者打開了新頁面）且同時(shí)是個(gè)GET請(qǐng)求，則攜帶。



還有一個(gè)比較嚴(yán)重的問題是SameSite不支持子域名.

附加驗(yàn)證
驗(yàn)證碼

通過圖形驗(yàn)證碼或者手機(jī)驗(yàn)證碼或者郵箱驗(yàn)證等多種方式強(qiáng)制用戶進(jìn)行交互可以有效遏制CSRF攻擊,缺點(diǎn)是步驟比較繁瑣,只適用于如涉及金額,密碼相關(guān)等關(guān)鍵請(qǐng)求,

CSRF Token

基于攻擊者無法獲得用戶信息的特性,我們可以在前后端交互中攜帶一個(gè)有效驗(yàn)證“令牌”來防范CSRF攻擊,大概流程:



當(dāng)用戶首次登錄成功之后, 服務(wù)端會(huì)生成一個(gè)唯一性和隨機(jī)性的 token 值保存在服務(wù)器的Session或者其他緩存系統(tǒng)中，再將這個(gè)token值返回給瀏覽器；


瀏覽器拿到 token 值之后本地保存；


當(dāng)瀏覽器再次發(fā)送網(wǎng)絡(luò)請(qǐng)求的時(shí)候,就會(huì)將這個(gè) token 值附帶到參數(shù)中(或者通過Header頭)發(fā)送給服務(wù)端；


服務(wù)端接收到瀏覽器的請(qǐng)求之后,會(huì)取出token值與保存在服務(wù)器的Session的token值做對(duì)比驗(yàn)證其正確性和有效期。



在大型網(wǎng)站一般使用多臺(tái)服務(wù)器,用戶請(qǐng)求經(jīng)過負(fù)載均衡器路由到具體的服務(wù)器上,如果使用Session默認(rèn)儲(chǔ)存在單機(jī)服務(wù)器內(nèi)存中,在分布式環(huán)境下同一用戶的多次請(qǐng)求可能會(huì)指向不同的服務(wù)器上,而其他的服務(wù)器無法共享Session導(dǎo)致Session機(jī)制失效無法驗(yàn)證,所以分布式集群中Token需要儲(chǔ)存在Redis等公共儲(chǔ)存空間.


因?yàn)樽x取和驗(yàn)證Token會(huì)有復(fù)雜度和性能的問題,還有種方式采用Encrypted Token Pattern方式,通常是使用UserID、時(shí)間戳和隨機(jī)數(shù)，通過加密的方法生成而非隨機(jī)性,之后請(qǐng)求校驗(yàn)不需要讀取而是直接計(jì)算即可,這樣既可以保證分布式服務(wù)的Token一致，又能保證Token不容易被破解。

雙重Cookie驗(yàn)證

相較于CSRF Token,這種方式比較簡(jiǎn)單實(shí)現(xiàn)但是安全性較低.大概流程:



用戶訪問頁面之后域名被注入隨機(jī)字符串Cookie


瀏覽器發(fā)起請(qǐng)求時(shí)會(huì)取出該Cookie字符串添加到URL參數(shù)中


服務(wù)端驗(yàn)證是否一致



沒有大規(guī)模應(yīng)用除了安全性問題還有一個(gè)就是跨域可能導(dǎo)致獲取不到Cookie.



用戶訪問網(wǎng)站域名www.test.com,服務(wù)端api域名api.test.com,


如果想要共用Cookie就必須注入到test.com,然后子域名都能獲取到


同理每個(gè)子域名都能修改該Cookie,如果某個(gè)子域名被攻擊了


攻擊者可以自己配置一個(gè)Cookie破解雙重Cookie驗(yàn)證機(jī)制攔截

           
               
                                           
                       
                 

            
                     
             
               

                   
 文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

                 
                   
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/106423.html

               

                      
               
              

              

                
相關(guān)文章

                
    
                             
                                                                                                    
  • 
                                                
    
                          
    網(wǎng)絡(luò)與安全
    
                                                     
    摘要：面試網(wǎng)絡(luò)了解及網(wǎng)絡(luò)基礎(chǔ)對(duì)端傳輸詳解與攻防實(shí)戰(zhàn)本文從屬于筆者的信息安全實(shí)戰(zhàn)中滲透測(cè)試實(shí)戰(zhàn)系列文章。建議先閱讀下的網(wǎng)絡(luò)安全基礎(chǔ)。然而，該攻擊方式并不為大家所熟知，很多網(wǎng)站都有的安全漏洞。

面試 -- 網(wǎng)絡(luò) HTTP
現(xiàn)在面試門檻越來越高，很多開發(fā)者對(duì)于網(wǎng)絡(luò)知識(shí)這塊了解的不是很多，遇到這些面試題會(huì)手足無措。本篇文章知識(shí)主要集中在 HTTP 這塊。文中知識(shí)來自 《圖解 HTTP》與維基百科，若...
    
                                                   
                          
    
                                
    
                                    Integ
                                    
                                    評(píng)論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                                       
  • 
                                                
    
                          
    前端——影子殺手篇
    
                                                     
    摘要：前言對(duì)于一個(gè)影子殺手而言，總能殺人于無形。前端也有影子殺手，它總是防不勝防地危害著你的網(wǎng)站本篇打算介紹一些前端的影子殺手們和。影子殺手們，由來已久，幾乎伴隨著整個(gè)互聯(lián)網(wǎng)的發(fā)展。

前言
對(duì)于一個(gè)影子殺手而言，總能殺人于無形。前端也有影子殺手，它總是防不勝防地危害著你的網(wǎng)站
本篇打算介紹一些前端的影子殺手們——XSS和CSRF。或許，你對(duì)它恨之入骨；又或者，你運(yùn)用的得心應(yīng)手。恨之入骨，可能...
    
                                                   
                          
    
                                
    
                                    李世贊
                                    
                                    評(píng)論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                                       
  • 
                                                
    
                          
    web 應(yī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àn)上的優(yōu)化。
原因
當(dāng)使用外...
    
                                                   
                          
    
                                
    
                                    darkerXi
                                    
                                    評(píng)論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                                       
  • 
                                                
    
                          
    web 應(yī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àn)上的優(yōu)化。
原因
當(dāng)使用外...
    
                                                   
                          
    
                                
    
                                    Panda
                                    
                                    評(píng)論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                                       
  • 
                                                
    
                          
    前端進(jìn)階系列-目錄
    
                                                     
    摘要：然而在最近的面試中通過學(xué)習(xí)和思考，找到了前進(jìn)的方向，也得到一些大公司的錄用機(jī)會(huì)。算是從初級(jí)前端畢業(yè)，進(jìn)階了吧。在這里先寫個(gè)目錄。趕時(shí)間的同學(xué)可以按照我的目錄先自行準(zhǔn)備提升，希望推薦文章和交流。

背景
之前我分享了文章大廠前端面試考什么?,你們一定很想看答案吧？說實(shí)話，答案我是有，在準(zhǔn)備面試的時(shí)候會(huì)時(shí)不時(shí)翻看，但內(nèi)容比較多，比較凌亂，不能指望我在一篇文章中寫完。
我是從非計(jì)算機(jī)專業(yè)自學(xué)前...
    
                                                   
                          
    
                                
    
                                    cod7ce
                                    
                                    評(píng)論0 
                                    收藏0 
                                
    
                          
    
                      
    
                    
    •  
                                                                           
                

              

              
               

                  
                  
發(fā)表評(píng)論

                   
               

              

                

                  
0條評(píng)論
   
                
 
                      

              

           

           

              
 
                

                   
              
  

                  
最新活動(dòng)
 
           
                             
              





                                
              

           

        

      
 
    

    
     

      
    

    
    

    
       
       

         
閱讀需要支付1元查看
  
         
     
       

      
  
    
    













<