5

使用 Acunetix 扫描我的 Web 应用程序后,结果显示“在重定向页面中找到 HTML 表单”的 9 个实例。重现测试攻击的 HTTP 标头如下:

Request
GET /entities/add HTTP/1.1
Pragma: no-cache
Referer: https://test.mysite.com/entities/view
Acunetix-Aspect: enabled
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect-Queries: filelist;aspectalerts
Cookie: __AntiXsrfToken=97c0a6bb164d4121b07327df405f9db4; mysitecookie=
Host: test.mysite.com
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Acunetix-Product: WVS/8.0 (Acunetix Web Vulnerability Scanner - NORMAL)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm
Accept: */*

Response
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /login
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
Set-Cookie: mysitecookie=; expires=Mon, 11-Oct-1999 22:00:00 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 24 Sep 2013 10:38:12 GMT
Content-Length: 9447

响应部分让Location: /login我相信,如果我在将用户重定向到登录页面后结束响应,漏洞就会被堵塞。所以我改变了这段代码的所有实例:

protected void Page_Load(object sender, EventArgs e)
{
    if (!HttpContext.Current.User.Identity.IsAuthenticated)
    {
        Response.Redirect("/login");
    }
    else
    {
        // etc
    }
}

至:

protected void Page_Load(object sender, EventArgs e)
{
    if (!HttpContext.Current.User.Identity.IsAuthenticated)
    {
        Response.Redirect("/login", true);
    }
    else
    {
        // etc
    }
}

它仍然表现出脆弱的原因可能是什么?

4

3 回答 3

1

由于页面中有一个 HTML 表单,以及响应标头中的重定向,因此引发了该标志。我认为这是一个漏洞,因为它可以让未经身份验证的用户深入了解您的应用程序是如何工作的。您可以做的就是在重定向之前清除您的响应以防止出现此标志。

尝试以下操作:

protected void Page_Load(object sender, EventArgs e)
{
    if (!HttpContext.Current.User.Identity.IsAuthenticated)
    {
        Response.Clear();
        Response.Redirect("/login", true); // btw true is the default...
    }
    else
    {
        // etc
    }
}

如果您正在设置会话变量、cookie 等,那么您需要稍微调整一下,以确保所有内容都进入响应,例如使用 endResponse=false, Response.End(); 返回; 等等

http://msdn.microsoft.com/en-us/library/system.web.httpresponse.clear.aspx

于 2013-09-24T15:42:02.630 回答
0

Response.Redirect向客户端发送额外的往返行程(响应代码 302)。这意味着客户端将不得不调用“新”URL。这通常是您不想做的事情。

在 .Net 中,您还可以直接在服务器上进行重定向,这意味着无需额外的往返。

而不是Response.Redirect您想调用 Server.Transfer 或Server.TransferRequest(这是需要集成应用程序池的新方法)。

http://msdn.microsoft.com/en-us/library/system.web.httpserverutility.transferrequest.aspx

如果Server在您的上下文中不可用,您还会找到HttpServerUtilityin的一个实例HttpContext.Current

于 2013-09-24T14:20:48.020 回答
0

好吧,我不能说Acunetix计算漏洞的标准是什么,但我可以建议你使用response.redirect("url",false)超载 -检查这里

如果为 endResponse 参数指定 true,则此方法会为原始请求调用 End 方法,该方法在完成时会引发 ThreadAbortException 异常。此异常对 Web 应用程序性能有不利影响,这就是为什么建议为 endResponse 参数传递 false 的原因。

protected void Page_Load(object sender, EventArgs e)
{
    if (!HttpContext.Current.User.Identity.IsAuthenticated)
    {
        Response.Clear();
        Response.Redirect("/login", false);
        Context.ApplicationInstance.CompleteRequest();
    }
    else
    {
        // etc
    }
}

Context.ApplicationInstance.CompleteRequest(); 使 ASP.NET 绕过 HTTP 执行管道链中的所有事件和过滤,直接执行 EndRequest 事件。它绕过导致ThreadAbortException.

于 2013-09-24T15:34:50.827 回答