利用Window.Opener繞過CSRF保護

2021-02-23 黑白之道

【新朋友】點擊標題下面藍字「黑白之道」關注

【老朋友】點擊右上角，分享或收藏本頁精彩內容

【公眾號】搜索公眾號：黑白之道，或者ID:i77169

　

　　隨著Web應用的流行，安全問題日益受到矚目。目前Web應用的安全性更多依靠Web開發人員來保障，而非依靠客戶端驗證機制。這使得Web應用變的更加靈活可靠，但同時也伴隨著高昂的代價。目前70%的Web應用都非常脆弱，正是由於基於客戶端的認證機制非常容易被繞過。日前，我在一項Web應用中，發現了一個有趣的防範CSRF攻擊的安全機制。

　　1.簡介

　　當我們談論CSRF防護時，通常會使用三種方法：

　　1.檢查Referrer

　　2.基於表單的隨機Token

　　3.基於Cookie的隨機Token

　　目前我們進行的CSRF防護多是使用JavaScript代碼在客戶端進行防護的。

　　2.分析

　　我們來看一個HTTP頭

　　

　　由於沒有使用隨機Token，我們可以說上面這段代碼存在CSRF威脅。為了驗證這點，我創建了一個html頁面:

　　

　　當我使用一個合法的會話去執行這個頁面的時候，Web應用立即踢出了我，之後我反覆嘗試重新執行，Web應用均立即踢出了我並註銷了我的會話。我猜想可能是Web使用了Referrer進行驗證，所以我手動增加了一個合法的Referrer值，結果Web應用再次註銷了我的會話。

　　在經歷了數次嘗試之後，我發現了一段用來防護的JavaScript代碼

　　

　　我們發現這段代碼請求了一個Window.opener值。如果Window.opener的值為空，則Web應用則會踢出我並註銷我們的會話。就CSRF防護來說，這段代碼相當不錯。關於Window.opener請參見：Windows Opener Description

　　當一個窗口由另一個窗口打開時，這個窗口會維護一個指向前一個窗口的參考值，這個值就是window.opener。如果當前窗口沒有由其他窗口來打開，那麼window.opener值為空。目前Windows Phone瀏覽器不支持window.opener，同時當窗口由不同安全區域的窗口來打開時，IE瀏覽器也不支持window.opener。

　　那麼現在我們就需要設置window.opener來實現CSRF攻擊。

　　3.利用

　　通過分析我找到了一種通過使用HTTP標籤中href屬性來創建Opener值的方法。

　　首先創建兩個頁面

　　1.xss.php

　　2.csrf3.html

　　1.這兩個頁面都存在於受攻擊的Web伺服器上，暫且假設為"localhost"

　　在"xss.php"中我創建了一個指向"csrf3.html"的連結，同時使用get方法傳遞一個名為"zip"的變量。這裡我們假設zip變量沒有進行任何過濾。那麼我們使用href進行如下注入：

　　href="http://127.0.0.1/csrf3.html">Link For Target Application

　　2.對於csrf3.html我們使用之前的代碼

　　

　　最終我們發向目標的URL為

　　http://127.0.0.1/xss.php?zip= href="http://127.0.0.1/csrf3.html">Link For Target Application

　　效果截圖如下：

　　3.現在我成功了，在檢查過href給的連結後，我可以打開新的頁面而不被Web應用踢出了，同時也繞過了CSRF的防護。

　　4.結論

　　就像我們平時常說的基於客戶端的驗證機制不是一個很好的方法。經過這次實驗，我想說使用新的方法去防護Web應用攻擊是非常不錯的，但我們必須要注意具體的實現方式。

　　

比特幣贊助打賞地址：13sbdFRyFBeqmXY9GJQf66s5cwmvLvWaAD

----

要聞、乾貨、原創、專業
關注「黑白之道」 微信：i77169
華夏黑客同盟我們堅持，自由，免費，共享！

相關焦點

  • 危險的 target=＂_blank＂ 與 「opener」
    起源parent 與 opener在說 opener 之前，可以先聊聊 <iframe> 中的 parent。我們知道，在 <iframe> 中提供了一個用於父子頁面交互的對象，叫做 window.parent，我們可以通過 window.parent 對象來從框架中的頁面訪問父級頁面的 window。
  • Django CSRF Bypass (CVE-2016-7401) 漏洞分析
    在兩年前有研究人員在hackerone上提交了一個利用Google Analytics來繞過Django的CSRF防護機制的漏洞(CSRF protection bypass on any Django powered site via Google Analytics)，通過該漏洞，當一個網站使用了Django作為Web框架並且設置了Django的CSRF防護機制，同時又使用了Google Analytics
  • 利用基於AngularJS的XSS實現提權
    一切都在我們的控制之中，大部分保護都被打破了。管理員用戶擁有應用程式的最高權限可以對任意用戶執行添加/刪除/編輯操作。而我最終得以提升到管理員權限就是通過XSS做到的。每當我發現XSS，我都會嘗試使用一些獨特的方式來利用它們。令牌抓取，CSRF保護繞過或是抓取cookie，現在看來已經顯得有些過時。在我的測試期間，在用戶配置文件頁面我發現了多個XSS漏洞。
  • CVE-2016-7401-Django CSRF防禦繞過漏洞分析
    ;SimpleCookie: __utmz='blah'csrftoken='x'>可見，當c.load('__utmz=blah]csrftoken=x')後，cookie被錯誤地解析為兩個，一個Cookie[__utmz]=blah，一個csrftoken=x。
  • 【第1211期】危險的 target=＂_blank＂ 與 「opener」
    前言今日早讀文章由知道創宇團隊FED@jinliming2授權分享。@知道創宇FED，我們是有內容的前端團隊，專注於探索大數據可視化、信息安全、開發效率、產品交互等內容，我們將精益求精，將科技藝術化呈現。正文從這開始～在網頁中使用連結時，如果想要讓瀏覽器自動在新的標籤頁打開指定的地址，通常的做法就是在 a 標籤上添加 target等於」_blank」 屬性。然而，就是這個屬性，為釣魚攻擊者帶來了可乘之機。
  • Burp Suite | CSRF Token Tracker —— 繞過CSRF限制進行暴力破解
    CSRF Token Tracker 可以自動獲取 csrf 的 token，對於一些有 csrf 限制的請求，它可以繞過該限制，如暴力破解具有 csrf token 的登錄請求，在滲透測試過程中CSRF Token的自動更新。該插件可以直接在Bapp Store 安裝。
  • 你從未注意的隱藏危險: target = ＂_blank＂ 和 ＂opener＂
    前言parent 和 opener在討論 opener 對象之前，我們先看看 <iframe> 裡面的 parent 對象。我們都知道 <iframe> 提供了一個用於父頁面與子頁面交互的對象，它就是 window.parent。
  • 當SameSite屬性為默認值Lax時,繞過它並獲得一個CSRF
    SameSite cookies, source:web.devSameSite Cookies 是每個人都在談論的新 cookie 屬性，可用於防止 SOP 的繞過和
  • 文庫 | CSRF知識總結
    利用受害者在被攻擊網站已經獲取的註冊憑證，繞過後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的csrf與xss區別XSS：跨站腳本（Cross-site scripting，通常簡稱為XSS）是一種網站應用程式的安全漏洞攻擊，是代碼注入的一種。它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響。
  • 通過DVWA學CSRF
    對於CSRF教程，我並嘗試針對DVWA繞過低安全級別。跨站點請求偽造，也稱為one-click attack 或 session riding，縮寫為CSRF（有時被稱為sea-surf）或XSRF，是一種惡意利用網站session 的攻擊方式，通過用戶發送未授權的命令，利用網站信任完成。與跨站點腳本（XSS）不同，後者利用用戶對特定站點的信任，CSRF利用站點在用戶瀏覽器中的信任。
  • CSRF 攻擊的應對之道
    所以，我們要保護的對象是那些可以直接產生數據改變的服務，而對於讀取數據的服務，則不需要進行 CSRF 的保護。比如銀行系統中轉帳的請求會直接改變帳戶的金額，會遭到 CSRF 攻擊，需要保護。而查詢餘額是對金額的讀取操作，不會改變數據，CSRF 攻擊無法解析伺服器返回的結果，無需保護。
  • laravel的表單偽造與CSRF保護
    CSRF保護然後，我們換成post方法，然後刷新點擊提交按鈕，看會出現設麼情況。你會發現出現「page expired」，狀態碼為419的錯誤。laravel為什麼接受不了post請求？這裡就要引出laravel的默認CSRF保護機制了。
  • 淺析CSRF的防禦和攻擊案例
    利用受害者在被攻擊網站已經獲取的註冊憑證，繞過後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。>來繞過, 再比如下面的例子那可以用來繞過, 這都是正則沒寫好的例子, 大廠的正則也會有或多或少的問題2333因此這個防禦方式應當作為輔助而不是主要的防禦方式, 當然我認為應該不會有大公司是單純靠這個來檢測的2333CSRF token從第2點防禦, 這也是現在用的最多的一種方式
  • PortSwigger之身份驗證+CSRF筆記
    您的憑據：wiener:peter候選人用戶名候選人密碼暗示為了增加挑戰，該實驗室還實施了一種基於 IP 的蠻力保護形式。但是，這可以通過操縱 HTTP 請求標頭輕鬆繞過。解決方案如果直接爆破會觸發保護機制（30分鐘限制）
  • DVWA 1.10 High等級的CSRF另類通關法
    >這裡已經分析確認了$name可被我們利用做XSS，這樣就可以配合CSRF來重置用戶密碼了。需要先說明一下DVWA的資料庫設計，guestbook表的name欄位類型為varchar(100)，也就是說最多name只能寫入100個字符，超過的字符會被資料庫拋棄不存儲。那麼如何做到bypass呢，就是本文要表達的重點了。
  • CSRF 原理與防禦案例分析
    CSRF 利用實例1) 常用利用方式攻擊者構造惡意 html，通過引誘用戶/管理員訪問，觸發 CSRF 漏洞。  不過此方法有時也存在著一定的漏洞，比如可繞過等，所以最好還是使用 Token。  判斷 Referer 的一般方法就是利用正則進行判斷，而判斷 Referer 的正則一定要寫全，不然就會如上所說，可繞過！
  • window.open() 和 target= blank 有個安全漏洞
    我們經常使用 HTML target="_blank" 或 window.open() 在新窗口中打開頁面
  • 注意:內存注入利用「WinSxS」繞過UAC保護代碼開源
    近日，Ernesto Fernandez上傳了一份繞過UAC保護的利用代碼，該Metasploit模塊將通過進程注入的方式，利用受信任的發布者證書來繞過
  • csrf+self-xss實現反射性xss
    最近偶然挖到了幾個xss漏洞，結果提交後發現，均為self-xss，無奈廠商均認為危害小，所以駁回，於是在網上搜集了很多資料，現在整理一下，給出同時存在csrf