關於SSRF與CSRF漏洞的解釋

時間  2021-01-19
標籤 php html 前端 程序員 web 正則表達式 sql 數據庫 後端 api 欄目 系統安全 简体版
原文   原文鏈接

目錄

SSRF服務端請求僞造（外網訪問內網）

SSRF(Server-Side Request Forgery:服務器端請求僞造) 是一種由攻擊者構造造成由服務端發起請求的一個安全漏洞。通常狀況下，SSRF是要目標網站的內部系統。（由於他是從內部系統訪問的，全部能夠經過它攻擊外網沒法訪問的內部系統，也就是把目標網站當中間人）php

其實也就至關於一箇中間人攻擊（主要目的就是：由外網攻擊者利用SSRF漏洞攻擊內網）html

通常來講基本都是經過腳本去掃內網的ip、端口點到爲止前端

一、SSRF造成緣由

SSRF 造成的緣由大都是因爲服務端提供了從其餘服務器應用獲取數據的功能，且沒有對目標地址作過濾與限制。好比從指定URL地址獲取網頁文本內容，加載指定地址的圖片，文檔，等等。程序員

即也就是說服務器端的驗證並無對其請求如獲取圖片的參數（image=）作出嚴格的過濾以及限制，從而致使A網站能夠從其餘服務器的獲取數據web

在這裏插入圖片描述

（默認網站webserver192.168.1.5的參數指定訪問內網中的某臺機器的內部資源地址，若是沒有對其指定地址嚴格限制，那麼就可能形成由webserver192.168.1.5這太機器訪問內部的任意一臺機器的資源。）——>>如：www.xxx.com/xx.php?image=URL，通常像分享、在線翻譯這些功能地址。正則表達式

即咱們要對目標網站的架構瞭解，腦子了要有一個架構圖。好比 ： A網站，是一個全部人均可以訪問的外網網站，B網站是一個他們內部的OA網站，咱們普通用戶只能夠訪問a網站，不能訪問b網站。可是咱們能夠同過a網站作中間人，訪問b網站，從而達到攻擊b網站需求。sql

主要標誌就是：xx.php?url=.....數據庫

(也能夠命令執行，須要條件。甚至腳本執行。。。。)後端

二、利用SSRF漏洞的目的

SSRF漏洞就是經過篡改獲取資源的請求發送給服務器，可是服務器並無檢測這個請求是否合法的，而後服務器以他的身份來訪問其餘服務器的資源。api

三、SSRF漏洞的用途

  • 能夠對外網服務器所指向的內網、服務器本地進行端口掃描，獲取一些服務的banner信息
  • 攻擊運行在內網或服務器本地的應用程序（好比溢出）
  • 對內網web應用進行指紋識別，經過訪問默認文件實現
  • 攻擊內外網的web應用，主要是使用get參數就能夠實現的攻擊（好比struts2，sqli等
  • 利用file協議讀取本地文件等

四、SSRF漏洞的特性

SSRF的強大和成功概率由函數自己功能決定

即代碼中是什麼函數其功能有多強大，那麼存在SSRF漏洞的話，漏洞利用的機率和影響力就有多大。好比下面的兩個函數curl_init、file_get_contents：一個能達到執行腳本的地步，一個能達到讀文件的地步。

實例

對於curl_init函數，利用這個遠程包含的特性，使用端口掃描腳本http://192.168.18.62:86/bwapp/evil/ssrf-1.txt去掃描內網ip開放的端口

在這裏插入圖片描述

注意：這裏爲何txt被執行了，由於這裏有個包含漏洞才執行了

對於file_get_content函數：(不支持https，支持http，支持php://內置協議）

讀文件須要base64編碼（php://filter/read=convert.base64-encode/resource=xxx.php）

http://192.168.18.23/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=../../index.php

在這裏插入圖片描述

這裏我得總結一下，上面爲何我須要用文件包含去實現我SSRF的目的？，並且爲何要用內置函數去讀文件？，若是是這樣我直接用文件包含不就好了麼，簡直跟我文件包含沒有任何區別嘛。

其實這裏文件包含是文件包含，SSRF是SSRF，兩者之間是本質的不一樣，一個主要目的是包含文件，一個主要目的是經過中間服務器探測內網信息，這裏只是藉助了文件包含的能力舉得例子，實際的例子多得很並不都涉及到文件包含，並不能混淆。就比如文件上傳利用文件包含開啓一句話同樣。

以上只是對兩個實例的說明。

其本質是：文件包含了站點web服務器上的東西，而ssrf的目的是打進內網，搞內網的東西。

不懂能夠去wooyun看例子，ssrf是藉助站點web服務器進入內網進行信息蒐集。

五、如何挖掘SSRF漏洞

  • 分享：經過URL地址分享網頁內容
  • 轉碼服務
  • 在線翻譯
  • 圖片加載與下載：經過URL地址加載或下載圖片
  • 圖片、文章收藏功能
  • 未公開的api實現以及其餘調用URL的功能
  • 從URL關鍵字中尋找

share
wap
url
link
src
source
target
u
3g
display
sourceURl
imageURL
domain
...

六、經常使用SSRF去作什麼事

  • 利用執行腳本進行端口探測
  • 任意地址訪問
  • 內網訪問
  • 任意文件讀取
  • 內網攻擊

七、繞過方法（繞開通常ssrf的防禦）

1、更改IP地址寫法

一些開發者會經過對傳過來的URL參數進行正則匹配的方式來過濾掉內網IP，如採用以下正則表達式：

^10(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){3}$

^172\.([1][6-9]|[2]\d|3[01])(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){2}$

^192\.168(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){2}$

對於這種過濾咱們能夠採用改編IP的寫法的方式進行繞過，例如192.168.0.1這個IP地址咱們能夠改寫成：

(1)、8進制格式：0300.0250.0.1

(2)、16進制格式：0xC0.0xA8.0.1

(3)、10進制整數格式：3232235521

(4)、16進制整數格式：0xC0A80001

還有一種特殊的省略模式，例如10.0.0.1這個IP能夠寫成10.1

二、利用解析URL所出現的問題

在某些狀況下，後端程序可能會對訪問的URL進行解析，對解析出來的host地址進行過濾。這時候可能會出現對URL參數解析不當，致使能夠繞過過濾。

http://www.Jeromeyoung.com@192.168.0.1/

當後端程序經過不正確的正則表達式（好比將http以後到com爲止的字符內容，也就是www.Jeromeyoung.com，認爲是訪問請求的host地址時）對上述URL的內容進行解析的時候，頗有可能會認爲訪問URL的host爲www.Jeromeyoung.com，而實際上這個URL所請求的內容都是192.168.0.1上的內容。

八、防禦SSRF措施

（1）（黑名單）過濾10.0.0.0/8 、172.16.0.0/十二、192.168.0.0/1六、localhost私有地址、IPv6地址

（2）（黑名單）過濾file:///、dict://、gopher://、ftp:// 危險schema

（3）使用地址白名單

（4）內網服務開啓鑑權（Memcached, Redis, Elasticsearch and MongoDB）

（5）對回顯內容進行識別，採起限制措施

（6）須要使用互聯網資源（好比貼吧使用網絡圖片）而沒法使用白名單的狀況：首先禁用 CURLOPT_FOLLOWLOCATION；而後經過域名獲取目標ip，並過濾內部ip；最後識別返回的內容是否與假定內容一致

CSRF跨站請求僞造（也叫點擊攻擊）

Cross-site request forgery 簡稱爲「CSRF」，在CSRF的攻擊場景中攻擊者會僞造一個請求（這個請求通常是一個連接），而後欺騙目標用戶進行點擊，用戶一旦點擊了這個請求，整個攻擊就完成了。因此CSRF攻擊也成爲"one click"攻擊。 不少人搞不清楚CSRF的概念，甚至有時候會將其和XSS混淆,更有甚者會將其和越權問題混爲一談,這都是對原理沒搞清楚致使的。

一、CSRF攻擊原理

程序員開發的時候，未對相關頁面進行token和referer判斷，形成攻擊者可構造本身的URL地址欺騙目標用戶進行點擊。（點擊後由於未對相關頁面進行token和referer判斷，即連接中沒得帶token或者數據包中沒得referer這類的操做，因此連接地址沒得校驗操做直接執行了）其實也就是像下面的重要頁面的防範措施沒有作到位

以例子進行說明：

當咱們打開網站或者登錄某個網站後，就會產生一個會話(這裏指用戶登錄後)，這個會話多是SESSION，Cookie控制，可是這是可有可無的。惟一的重點是瀏覽器與服務器之間是在會話之中，在這個會話沒有結束時候，你能夠利用你的權限對網站進行操做，如進行發表文章，發郵件，刪除文章等操做。當這個會話結束後，你在進行某些操做時候Web應用程序一般會來提醒你，您的會話已過時，或者是請從新登錄等提示。

這很是好理解，就像咱們登錄網上銀行後，Web瀏覽器已經跟可信的站點創建了一個經認證的會話。以後，只要是經過該Web瀏覽器這個認證的會話所發送的請求，都被視爲可信的動做，例如轉帳，匯款等操做。當咱們在一段時間內不進行操做後，在來從新作轉帳，或者匯款操做，那麼這個站點可能會提示你：您的身份已過時，請從新登錄或者會話結束等消息。

而CSRF攻擊則是創建會話之上的攻擊。好比當你登錄了網上銀行，正在進行轉帳業務，這時你的某個QQ好友（攻擊者）發來一條消息(URL)，這條消息是攻擊者精心構造的轉帳業務代碼。並且與你所登陸的網站是同一個銀行，你可能認爲這個網站是安全的，並非什麼釣魚網站之類的，而後打開了這條URL，那麼你的帳戶的錢可能就在你的這一次小小點擊上所有丟失。

怎麼可能這麼神奇呢？其實這並不神奇。主要是由於你的瀏覽器正處於與此網站的會話之中，那麼一些操做都是合法的，而入侵者構造的這段代碼只不過是正常的轉帳操做代碼而已。好比說你想給用戶spisec轉帳1000元，那麼點擊提交按鈕以後，可能會發送如下請求：

http://www.taobao.com/pay.jsp?user=spisec&money=1000

而攻擊者僅僅是改變一下user參數與money參數便可完成一次「合法」的攻擊，如：

http://www.taobao.com/pay.jsp?user=hack&money=10000

當你訪問了這條URL以後，就會自動向hack這個帳戶裏面轉入10000元。而這是你親手形成的，並沒由於有人去破解你的密碼或者是Web服務器被入侵所致使的你的金錢丟失。下面以CSRF攻擊原理圖給你們形象總結:

在這裏插入圖片描述

  1. 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登陸網站A；

  2. 在用戶信息經過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A；

  3. 用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B；

  4. 網站B接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問第三方站點A；

  5. 瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。

二、達成CSRF攻擊的條件

  • 攻擊創建在瀏覽器與Web服務器的會話之中
  • 會話期間須要受害者進行訪問或者說是點擊

若是以上任意一個不知足都不能達成跨站請求僞造攻擊。即目標必須處於會話狀態，且須要點擊

說白了，CSRF攻擊也就是所謂的釣魚攻擊。

三、CSRF分類

  • 站內
  • 站外

四、檢測方法

  • 手工

檢測CSRF漏洞是一項比較繁瑣的工做，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段後再從新提交，若是該提交還有效，那麼基本上能夠肯定存在CSRF漏洞。

  • 工具

  • burp

  • CSRF Request Builder

  • CSRFTester

工具檢測的原理：

以CSRFTester工具爲例，CSRF漏洞檢測工具的測試原理以下：使用CSRFTester進行測試時，首先須要抓取咱們在瀏覽器中訪問過的全部連接以及全部的表單等信息，而後經過在CSRFTester中修改相應的表單等信息，從新提交，這至關於一次僞造客戶端請求。若是修改後的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，固然此款工具也能夠被用來進行CSRF攻擊。

五、如何挖掘CSRF漏洞

  • 掃描器(注意並非每一個頁面爆沒有token漏洞都是對的，由於前端的進行CSRF有毛用，主要就是對後臺管理那一層的，因此不要盲目認爲。)，
  • 修改密碼的地方
  • 添加用戶的地方
  • 數據庫備份的地方
  • 數據交易、支付等
  • 其餘一些對話框的釣魚頁面
  • CSRF通常與XSS結合使用
  • 注意頁面是否帶token或者包中有沒得Referer，Referer在包中刪除是否依然能夠訪問url目標等。光靠一個Referer來講也沒用，Referer也能僞造

注意可能有預測的token，即有規律的token，若是是隨機的就放棄吧。

六、經常使用攻擊手段實例

通常的攻擊思路：（首先，開源的web源碼，攻擊者瞭解網站的框架，搭建環境構造攻擊url，例如數據備份的，下面實驗中有過程。

去目標網站建立普通用戶，發帖插入url等待目標管理會話在線狀態瀏覽帖子，中招，攻擊者訪問備份下來的數據庫，脫褲，完事。

）

1）、dz網站數據庫備份（快速脫庫）

兩個ip：192.168.18.56:82攻擊者本身的ip、192.168.18.62:86管理員的ip

總體思路：

實驗步驟：攻擊者本身搭建環境，以管理員身份登陸，建立普通帳戶，以管理員身份進行數據備份，抓包，修改包的post數據，構造url爲本身要求的。（這裏url的IP地址爲目標的IP地址）

複製好url，前往目標網站，註冊，以普通用戶身份登陸發帖帶入url（試一下直接在文本中插入，按道理來講須要自動運行地址而不是文本內容），等待管理員登陸且爲會話狀態點擊查看攻擊者發帖的內容，達成指定備份。

攻擊者訪問構造的url，脫庫。

攻擊者環境配置url（建立帳號忽略，直接上關鍵步驟）：

在這裏插入圖片描述

本來應該這是樣的：

在這裏插入圖片描述

在這裏插入圖片描述

當攻擊者重構備份的文件夾名稱和文件名的時候：

注意：這裏構造是抓到包的時候抓了改，再放包，不是重發器裏發一次。

在這裏插入圖片描述

在這裏插入圖片描述

在這裏插入圖片描述

找到攻擊url，構形成目標的地址：

http://192.168.18.62:86/dz/upload/uc_server/admin.php?m=db&a=operate&t=export&appid=0&backupdir=Jerome%26backupfilename%3Dtest

在目標網站上建立用戶、發帖。

在這裏插入圖片描述

發帖成功：

在這裏插入圖片描述

如今當管理員登陸以後查看帖子，會發現是正常的帖子：

在這裏插入圖片描述

在這裏插入圖片描述

當管理員在線且點擊了這篇帖子，結果就是數據庫已經達成了備份，且能被攻擊者訪問。

在這裏插入圖片描述

這裏得說明一下這個路徑，在上面攻擊者搭建的環境中，必定會去模擬攻擊才知道最後的結果在哪一個路徑下，上面省卻了這個步驟，這裏直接在目標機器上看結果。

在這裏插入圖片描述

2）、修改密碼

修改密碼的前提是：利用CSRF漏洞

以dvwa的低級爲例，直接抓包：

在這裏插入圖片描述

在這裏插入圖片描述

上面把referer刪除了，能夠改密碼，說明csrf可用。

構造對目標構造以下url，存在CSRF漏洞的狀況下，一旦在線點擊訪問就能改密碼：

http://192.168.18.62:86/dvwa/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change

在這裏插入圖片描述

說一下中級的：

中級的發現沒法直接執行再改密碼，先看源碼：

在這裏插入圖片描述

在這裏插入圖片描述

在這裏插入圖片描述

但經過觀察數據包發現，其沒有referer信息，那麼對其進行了一個僞造Referer：

​ Referer:http://192.168.18.62:86/dvwa/vulnerabilities/csrf/

加入數據包中，發現密碼被修改了。

在這裏插入圖片描述

（改密碼也就是說：沒得任何驗證如沒有驗證碼、沒得token、沒得Referer、沒得原密碼校驗等，很容易就形成通殺直接，受害者回話狀態點擊插入了url的地址，直接被修改密碼。）

3）、添加帳號

下面利用一個網站進行添加帳號操做：

首先，利用自建網站進行添加帳號操做，抓包將包生成爲poc，創建test.html，廢掉此包。

在這裏插入圖片描述

在這裏插入圖片描述

目前仍爲管理登陸狀態，在這個狀態下點擊了攻擊者的test.html。看下效果：

在這裏插入圖片描述

在這裏插入圖片描述

攻擊者的效果成功達成。

4）、自解壓縮包

配置方式以下：

在這裏插入圖片描述

在這裏插入圖片描述

一旦解壓就會打開百度，自行嘗試吧。

七、防範方法

  • 驗證HTTP Referer字段
  • 在請求地址中添加token並驗證
  • 在HTTP頭中自定義屬性並驗證
  • 在服務端嚴格區分好POST和GET的數據請求
  • 使用驗證碼或者密碼確認方式進行
  • 白名單
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程