浮雲雅築: XSRF

顯示具有 XSRF 標籤的文章。顯示所有文章

2025年7月18日星期五

[研究]ASP.NET WebForm網站被 HCL AppScan 10.8報告 __AntiXsrfToken (Cookie)【參數指令注入】弱點

[研究]ASP.NET WebForm網站被 HCL AppScan 10.8報告 __AntiXsrfToken (Cookie) 【參數指令注入】弱點

2025-07-18

HCL AppScan Standard 10.8.0 建立

********************************************************************************

實際到受測主機測試

✅ DNS 查詢會發送到內部 DNS Server 172.16.xxxx.xxx

❌ 內部 DNS Server 未能將此查詢往外轉送，或被網路政策擋下

根據這些事實，在這種網路架構下：

AppScan 嘗試觸發 SSRF、Command Injection、外部連線等弱點時，可能無法實際送出封包

因為：主機連 DNS 查詢都 timeout，就不可能觸發成功的 OOB（Out-of-Band）漏洞

🔍 AppScan 報告是否為誤判？

本次掃描報告中出現的 OOB 連線測試（如 v3-ping-xxx.adns.appsechcl.com），實測本主機無法進行外部 DNS 查詢（內部 DNS 無法解析外部域名），可合理判定為誤判（False Positive）。

(完)

2025年7月8日星期二

[研究]HCL AppScan報告看到的 v3-ping-169-f4f15c7d-e080-4552-aebf-ca6432bff9b1.adns.appsechcl.com 是甚麼網站 ?

[研究]HCL AppScan報告看到的 v3-ping-169-f4f15c7d-e080-4552-aebf-ca6432bff9b1.adns.appsechcl.com 是甚麼網站 ?

2025-07-08

ping -c 1 v3-ping-169-f4f15c7d-e080-4552-aebf-ca6432bff9b1.adns.appsechcl.com，ping 的是甚麼網站 ? 我可以看到對方 Log ? 用 log 知道我是否成功 ping 到對方 ?

ChatGPT 說：

你提到的 ping -c 1 v3-ping-169-f4f15c7d-e080-4552-aebf-ca6432bff9b1.adns.appsechcl.com 是使用 ICMP（Internet Control Message Protocol）對該網域名稱進行一次性測試。

是由安全掃描工具或滲透測試平台自動生成的 URL，通常用來檢查目標伺服器是否會「出站連線」或被惡意注入觸發，例如：

OWASP ZAP
HCL AppScan
Burp Suite 的 Collaborator
DNSLog 工具（例如 DNSLog.cn、Interact.sh）

這種域名背後是個監控平台（callback receiver），用來接收你主機所發出的 DNS 請求或 ping 等反向連線，以此來判斷你是否受到某些漏洞影響（例如 SSRF、命令注入、RCE）。

✅ 我可以看到對方的 Log 嗎？

你自己無法看到該平台的 log，除非：

你有註冊並登入該平台（如 Interact.sh 或 HCL AppScan Cloud DNS Receiver）
或該工具是你自己架設的 callback server

如果你是測試者，在工具上會看到是否有成功收到 ping、DNS 或 HTTP 請求（例如在 AppScan 中會顯示 "Outbound Connection Detected"）。

🤔 對方是否可以從 log 知道你是否 ping 成功？

是的，對方可以透過以下方式看到你是否成功 ping 到他們的伺服器：

DNS 查詢記錄：即使 ping 不成功，只要 DNS 查詢發生（即發出 A 或 AAAA 查詢），平台就能記錄到你主機的 IP 與查詢時間。
ICMP 請求/回應：如果對方伺服器允許 ICMP，並有記錄，你的 ping 將留下記錄，包括來源 IP、時間等。
HTTP/S 請求（如果你不是 ping，而是 curl、wget）

🔧 實際用法範例

如果你在測試網站中加入以下程式碼：

然後瀏覽該頁面，只要有網頁讀取圖片的動作，就會觸發對該 URL 的 DNS 查詢（甚至 HTTP），對方就會在 log 中看到你機器的來源資訊。

如你是要測試 CSRF、XSS、命令注入是否可導致出站連線，這種 ping / DNS callback 機制就是常見手法。

(完)

2025年6月24日星期二

[研究]ASP.NET, WebForm, MasterPage, 跨站請求偽造 XSRF/CSRF（Cross-Site Request Forgery）防護

[研究]ASP.NET, WebForm, MasterPage, 跨站請求偽造 XSRF/CSRF（Cross-Site Request Forgery）防護

2025-06-24

環境：Visual Studio 2022 + ASP.NET + WebForm + Web Application + C# + SQL Server 2019 + SQL Server Management Studio (SSMS) 19

********************************************************************************

Site1.master

<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site1.master.cs" 
    Inherits="WebApplication1.Site1" %>

<!DOCTYPE html>

<html>
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title></title>
    <asp:ContentPlaceHolder ID="head" runat="server">
    </asp:ContentPlaceHolder>
</head>
<body>
    <form id="form1" runat="server">
        <asp:HiddenField ID="AntiCsrfToken" runat="server" />
        <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
        </asp:ContentPlaceHolder>
    </form>
</body>
</html>

Site1.master.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class Site1 : System.Web.UI.MasterPage
    {
        private const string AntiXsrfTokenKey = "__AntiXsrfToken";
        private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
        private string _antiXsrfTokenValue;

        protected void Page_Init(object sender, EventArgs e)
        {
            // The code below helps to protect against XSRF attacks
            var requestCookie = Request.Cookies[AntiXsrfTokenKey];

            if (requestCookie != null && Guid.TryParse(requestCookie.Value, out Guid requestCookieGuidValue))
            {
                // Use the Anti-XSRF token from the cookie
                _antiXsrfTokenValue = requestCookie.Value;
                Page.ViewStateUserKey = _antiXsrfTokenValue;
            }
            else
            {
                // Generate a new Anti-XSRF token and save to the cookie
                _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
                Page.ViewStateUserKey = _antiXsrfTokenValue;

                var responseCookie = new HttpCookie(AntiXsrfTokenKey)
                {
                    HttpOnly = true,
                    Value = _antiXsrfTokenValue
                };
                if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
                {
                    responseCookie.Secure = true;
                }
                Response.Cookies.Set(responseCookie);
            }

            Page.PreLoad += master_Page_PreLoad;
        }
        protected void master_Page_PreLoad(object sender, EventArgs e)
        {
            if (!IsPostBack)
            {
                // Set Anti-XSRF token
                ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;
                ViewState[AntiXsrfUserNameKey] = Context.User.Identity.Name ?? string.Empty;
            }
            else
            {
                // Validate the Anti-XSRF token
                if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue 
                    || (string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? string.Empty))
                {
                    throw new InvalidOperationException("Validation of Anti-XSRF token failed.");
                }
            }
        }
        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

Default.aspx

<%@ Page Title="" Language="C#" MasterPageFile="~/Site1.Master" AutoEventWireup="true"
    CodeBehind="Default.aspx.cs" Inherits="WebApplication1.Default" %>
<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
    <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />
</asp:Content>

Default.aspx.cs

using System;

namespace WebApplication1
{
    public partial class Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            Response.Write("XSRF (CSRF) 測試範例！");
        }
    }
}

用 OWASP Zed Attack Proxy (ZAP) 2.16.1 (2025-03-26 釋出) 測試

(完)

相關

[研究]ASP.NET, WebForm, 跨站請求偽造 XSRF/CSRF（Cross-Site Request Forgery）防護

[研究]ASP.NET, WebForm, 跨站請求偽造 XSRF/CSRF（Cross-Site Request Forgery）防護

2025-06-24

環境：Visual Studio 2022 + ASP.NET + WebForm + Web Application + C# + SQL Server 2019 + SQL Server Management Studio (SSMS) 19

********************************************************************************

Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" 
    Inherits="WebApplication1.Default" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
        <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />
    </form>
</body>
</html>

Default.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class Default : System.Web.UI.Page
    {

        protected void Page_Load(object sender, EventArgs e)
        {

        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            Response.Write("XSRF (CSRF) 測試範例！");
        }
    }
}

用 OWASP Zed Attack Proxy (ZAP) 2.16.1 (2025-03-26 釋出) 測試

********************************************************************************

修改後 Default.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class Default : System.Web.UI.Page
    {
        private string AntiXsrfTokenKey = "__AntiXsrfToken";
        private string AntiXsrfTokenValue;

        protected void Page_Init(object sender, EventArgs e)
        {
            // 取得或產生 Anti-XSRF Token
            AntiXsrfTokenValue = (string)ViewState[AntiXsrfTokenKey];
            if (string.IsNullOrEmpty(AntiXsrfTokenValue))
            {
                AntiXsrfTokenValue = Guid.NewGuid().ToString("N");
                ViewState[AntiXsrfTokenKey] = AntiXsrfTokenValue;
            }

            // 綁定驗證事件
            Page.PreLoad += Page_PreLoad;
        }

        protected void Page_PreLoad(object sender, EventArgs e)
        {
            if (!IsPostBack)
            {
                // 首次載入，將 Token 存入 ViewState
                ViewState[AntiXsrfTokenKey] = AntiXsrfTokenValue;
            }
            else
            {
                // PostBack 時比對 Token
                if ((string)ViewState[AntiXsrfTokenKey] != AntiXsrfTokenValue)
                {
                    throw new InvalidOperationException("Anti-XSRF 檢查失敗。");
                }
            }
        }
        protected void Page_Load(object sender, EventArgs e)
        {

        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            Response.Write("XSRF (CSRF) 測試範例！");
        }
    }
}

再次測試

********************************************************************************

ZAP 為何仍出現 XSRF 警告？

因為 ZAP 看到：

代表：

表單缺少隱藏欄位 Token (Anti-CSRF Token)。
僅靠 ViewStateUserKey，ZAP 檢查不到，因為它藏在 __VIEWSTATE，無明顯 Token 存在。

所以：

✅ ViewStateUserKey 減少風險，但不是主動、可見的 CSRF 防護。
❌ 缺少獨立、隱藏欄位 Token，ZAP 視為未防護。

********************************************************************************

再再次修改

Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"

Inherits="WebApplication1.Default" %>

<!DOCTYPE html>

</head>

<body>

<asp:HiddenField ID="AntiCsrfToken" runat="server" />

<asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />

</form>

</body>

</html>

Default.aspx.cs

using System;

namespace WebApplication1
{
    public partial class Default : System.Web.UI.Page
    {
        private const string AntiCsrfKey = "AntiCsrfTokenKey";

        protected void Page_Init(object sender, EventArgs e)
        {
            // ViewStateUserKey 強化 ViewState 防偽造
            if (Context.User.Identity.IsAuthenticated)
            {
                ViewStateUserKey = Session.SessionID;
            }
            else
            {
                ViewStateUserKey = Guid.NewGuid().ToString();
            }

            // 產生 Anti-CSRF Token
            if (Session[AntiCsrfKey] == null)
            {
                Session[AntiCsrfKey] = Guid.NewGuid().ToString("N");
            }

            AntiCsrfToken.Value = Session[AntiCsrfKey].ToString();
        }

        protected void Page_Load(object sender, EventArgs e)
        {
            if (IsPostBack)
            {
                // 驗證 Anti-CSRF Token
                if (AntiCsrfToken.Value != (string)Session[AntiCsrfKey])
                {
                    throw new InvalidOperationException("Anti-CSRF Token 驗證失敗，請重新整理頁面。");
                }
            }
        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            Response.Write("XSRF (CSRF) 測試範例！");
        }
    }
}

再再次測試，防住 XSRF / CSRF 了。

********************************************************************************

(完)

相關

2024年2月26日星期一

[研究]XSRF/CSRF, SSRF, XSS 比較

[研究]XSRF/CSRF, SSRF, XSS 比較

2024-02-27

XSRF/CSRF, SSRF, XSS 比較

ChatGPT

XSRF/CSRF（Cross-Site Request Forgery）、SSRF（Server-Side Request Forgery）和XSS（Cross-Site Scripting）是Web應用程式中常見的安全威脅，它們具有不同的特點和攻擊方式：

XSRF/CSRF（跨站請求偽造）：

攻擊方式：XSRF/CSRF攻擊利用了使用者的已認證會話，在使用者不知情的情況下執行非授權的操作。攻擊者建構惡意請求並誘使受害者在受信任的網站上執行這些請求，從而利用使用者的身分來執行惡意操作。
目標：攻擊目標是執行未經授權的操作，例如更改使用者密碼、發表文章或執行其他敏感操作。
防禦：防禦XSRF/CSRF攻擊的常用方法包括使用XSRF/CSRF令牌、檢查Referer頭、使用雙重認證等。

SSRF（伺服器端請求偽造）：

攻擊方式：SSRF攻擊利用了伺服器端應用程式對外部資源的存取權限，透過操縱伺服器端的請求來發動針對內部網路或其他受信任資源的攻擊。
目標：攻擊目標是利用伺服器的存取權限，例如存取內部系統、執行任意網路請求等。
防禦：防禦SSRF攻擊的方法包括限制伺服器端應用程式的存取權限、白名單驗證輸入URL、檢查使用者提供的URL等。

XSS（跨站腳本攻擊）：

攻擊方式：XSS攻擊利用了網路應用程式對使用者輸入的信任，向受害者傳遞惡意腳本，並在受害者的瀏覽器上執行這些腳本，以竊取資訊、劫持會話或執行其他惡意操作。
目標：攻擊目標是執行惡意腳本，以獲取敏感資訊或執行其他攻擊。
防禦：防禦XSS攻擊的方法包括對使用者輸入進行正確的轉義和過濾、使用HTTPOnly和Secure標誌來設定cookie、採用內容安全策略（Content Security Policy）等。

雖然XSRF/CSRF、SSRF和XSS都是網頁應用程式中的常見攻擊，但它們的目標、攻擊方式和防禦方法各不相同。因此，開發人員和安全專家需要針對每種攻擊類型採取不同的防禦措施來保護應用程式的安全性。

定義	利用使用者的身分在受信任網站上執行未授權操作。	利用伺服器端應用程式對外部資源的存取權限。	向使用者瀏覽器注入惡意腳本，以在使用者端執行。
攻擊目標	利用使用者的身分執行未經授權的操作。	利用伺服器的存取權限執行惡意操作。	竊取使用者資訊、劫持會話或執行其他惡意操作。
攻擊方式	利用受害者在受信任網站上的認證狀態。	利用伺服器端應用程式對外部資源的存取。	向受害者的瀏覽器注入惡意腳本。
防禦方法	使用XSRF/CSRF令牌、檢查Referer頭、雙重認證等。	限制伺服器端應用程式的存取權限、白名單驗證URL等。	轉義和過濾使用者輸入、使用HTTPOnly和Secure標誌、內容安全策略（CSP）等。

********************************************************************************

XSS 分成哪幾種 ?

ChatGPT

XSS（跨站腳本攻擊）可分為以下幾種常見類型：

反射型 XSS（Reflected XSS）：

攻擊方式：惡意腳本作為輸入的一部分傳遞給應用程序，然後在回應中反射回用戶，攻擊者誘使用戶點擊包含惡意腳本的連結或訪問特定的URL。
特點：惡意腳本在用戶每次請求時都會反射回用戶，因此稱為「反射型」。

儲存型 XSS（Stored XSS）：

攻擊方式：惡意腳本被儲存在應用程式的資料庫或檔案系統中，當其他使用者存取包含惡意腳本的頁面時，惡意腳本都會被執行。
特點：惡意腳本在伺服器上永久存儲，因此稱為「儲存型」。

DOM 型 XSS（DOM-based XSS）：

攻擊方式：惡意腳本透過修改頁面的DOM結構來執行攻擊，而不是利用伺服器端的回應。攻擊成功取決於頁面中的客戶端腳本如何處理使用者輸入。
特點：攻擊不會將惡意腳本傳送到伺服器，而是在用戶端中利用DOM操作執行攻擊。

這些不同類型的XSS攻擊方式都有其特徵和攻擊方式。了解它們有助於開發人員和安全專家採取適當的防禦措施來保護網路應用程式免受XSS攻擊的影響。

特點	反射型XSS	儲存型XSS	DOM型XSS
攻擊方式	惡意腳本作為輸入的一部分傳遞給應用程序，然後在回應中反射回使用者。	惡意腳本被儲存在應用程式的資料庫或檔案系統中。	惡意腳本透過修改頁面的DOM結構來執行攻擊。
特點	惡意腳本在使用者每次請求時都會反射回使用者。	惡意腳本在伺服器上永久存儲，可被多個使用者觸發。	攻擊不會將惡意腳本傳送到伺服器，而是在用戶端中利用DOM操作執行。
攻擊目標	誘使使用者點擊包含惡意腳本的連結或造訪特定的URL。	其他使用者造訪包含惡意腳本的頁面時，惡意腳本被執行。	利用DOM操作執行攻擊，而不是利用伺服器端的回應。
防禦方法	對使用者輸入進行正確的轉義和過濾，使用HTTPOnly和Secure標誌，內容安全策略（CSP）等。	對使用者輸入進行正確的轉義和過濾，限制使用者輸入的長度和類型。	對使用者輸入進行正確的轉義和過濾，避免直接在DOM中執行未經驗證的輸入。

********************************************************************************

訂閱：文章 (Atom)

2025年7月18日 星期五

[研究]ASP.NET WebForm網站被 HCL AppScan 10.8報告 __AntiXsrfToken (Cookie)【參數指令注入】弱點

2025年7月8日 星期二

[研究]HCL AppScan報告看到的 v3-ping-169-f4f15c7d-e080-4552-aebf-ca6432bff9b1.adns.appsechcl.com 是甚麼網站 ?

2025年6月24日 星期二

[研究]ASP.NET, WebForm, MasterPage, 跨站請求偽造 XSRF/CSRF（Cross-Site Request Forgery）防護

[研究]ASP.NET, WebForm, 跨站請求偽造 XSRF/CSRF（Cross-Site Request Forgery）防護

2024年2月26日 星期一

[研究]XSRF/CSRF, SSRF, XSS 比較

2025年7月18日星期五

2025年7月8日星期二

2025年6月24日星期二

2024年2月26日星期一