昨晚，一位客户打来电话，因为谷歌已经缓存了私人员工信息的版本。除非您登录，否则无法获取该信息。
他们在Google上搜索了他们的域名，例如：
site:example.com
并注意到Googled已经抓取并缓存了一些内部页面。
自己查看页面的缓存版本：
这是Google https://example.com/(F(NSvQJ0SS3gYRJB4UUcDa1z7JWp7Qy7Kb76XGu8riAA1idys-nfR1mid8Qw7sZH0DYcL64GGiB6FK_TLBy3yr0KnARauyjjDL3Wdf1QcS-ivVwWrq-htW_qIeViQlz6CHtm0faD8qVOmAzdArbgngDfMMSg_N4u45UysZxTnL3d6mCX7pe2Ezj0F21g4w9VP57ZlXQ_6Rf-HhK8kMBxEdtlrEm2gBwBhOCcf_f71GdkI1))/ViewTransaction.aspx?transactionNumber=12345的缓存。它是2013年9月15日00:07:22 GMT上显示的页面快照
我对长网址感到困惑。而不是：
https://example.com/ViewTransaction.aspx?transactionNumber=12345
插入了长字符串：
https://example.com/[...snip...]/ViewTransaction.aspx?transactionNumber=12345
我花了几分钟时间记住：这可能是ASP.net的＆＃34; ＆＃34;无cookie会话＆＃34; 的症状 。如果您的浏览器不支持 Set-Cookie ，则该网站会在网址中嵌入Cookie。
除了我们的网站没有使用它。
即使我们的网站 已经自动检测到无Cookie会话，并且Google设法哄骗网络服务器将其交给网址中的会话，它是如何接管其他用户的？ ＃39;会话？
该网站已被机器人抓取多年。而今年5月29日也没有什么不同。
Google通常会通过检查robots.txt文件（我们没有）来开始抓取。但是没有人被允许在没有首先进行身份验证的情况下在网站上准备任何内容（包括robots.txt），所以它失败了：
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /robots.txt 80 302 ;not authenticated, see /Account/Login.aspx
1:33:04 GET /Account/Login.aspx 80 302 ;use https plesae
1:33:04 GET /Account/Login.aspx 443 200 ;go ahead, try to login
Google一直在寻找robots.txt文件。它永远不会有一个。然后它返回以尝试抓取根目录：
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET / 80 302 ;not authenticated, see /Account/Login.aspx
1:33:04 GET /Account/Login.aspx 80 302 ;use https plesae
1:33:04 GET /Account/Login.aspx 443 200 ;go ahead, try to login
另一张安全网站上的robots.txt检查：
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /robots.txt 443 302 ;not authenticated, see /Account/Login.aspx
1:33:04 GET /Account/Login.aspx 443 200 ;go ahead, try to login
然后登录页面上的样式表：
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /Styles/Site.css 443 200
这就是来自GoogleBot，msnbot和BingBot的每次抓取工作的方式。机器人，登录，安全，登录。永远不会到达任何地方，因为它无法超越 WebForms身份验证。一切都与世界很好。
直到有一天，GoogleBot会出现，会话cookie 在手！
Time Uri Port User Name Status
======== ========================= ==== =================== ======
1:49:21 GET / 443 jatwood@example.com 200 ;they showed up logged in!
1:57:35 GET /ControlPanel.aspx 443 jatwood@example.com 200 ;now they're crawling that user's stuff!
1:57:35 GET /Defautl.aspx 443 jatwood@example.com 200 ;back to the homepage
2:07:21 GET /ViewTransaction.aspx 443 jatwood@example.com 200 ;and here comes the private information
用户jatwood@example.com已超过一天未登录。 （我希望IIS为两个同时访问者提供相同的会话标识符，由应用程序回收分隔）。我们的网站（web.config）未配置为启用无会话Cookie。并且服务器（machine.config）未配置为启用无会话cookie。
所以：
就在10月1日（4天前），GoogleBot 仍然显示，手头有cookie，以此用户身份登录，抓取，缓存和发布，其中一些私人详细信息
Google 是如何绕过 WebForms 身份验证的非恶意网络抓取工具？
IIS7，Windows Server 2008 R2，单服务器。
服务器未配置为发出无cookie会话。但忽略这一事实，Google如何绕过身份验证呢？
jatwood@example.com无Cookie会话网址。这些都不是真正可信的。
如何 Google 非恶意网络抓取工具绕过WebForms身份验证，并劫持用户的现有会话？
我甚至不知道如何一个ASP.net网站，没有配置为发出无cookie会话，可以发出无cookie会话。是否可以将基于cookie的会话ID 反向转换为 基于cookie的会话ID ？我可以引用<sessionState>和web.config的相关machine.config部分，并显示不存在
<sessionState cookieless="true">
网络服务器如何确定浏览器不支持Cookie？我尝试在Chrome中阻止Cookie，但我从未获得过无Cookie会话标识符。我可以模拟不会出现的浏览器吗？支持cookie，以验证我的服务器没有发出无cookie会话？
服务器是否通过 User-Agent 字符串决定无Cookie会话？如果是这样，我可以使用欺骗性UA设置Internet Explorer。
ASP.net中的会话标识是否仅依赖于cookie？来自任何IP的任何人都可以使用cookie-url访问该会话吗？默认情况下，ASP.net是否也考虑到了？
如果ASP.net 确实 将IP地址与会话联系起来，那么这并不意味着会话无法来自员工他们的家用电脑？因为当GoogleBot抓取工具尝试从Google IP使用它时，它会失败吗？
在没有配置的情况下，ASP.net是否有任何实例（除了我链接的那个）发出无cookie会话？是否存在Microsoft Connect问题？
Web表单身份验证是否存在问题，不应用于安全性？
编辑：删除了 Google 这个绕过特权的机器人的名字，因为人们是头部迟钝的裤子;混淆 Google 其他东西的抓取工具名称。我使用 Google 作为抓取工具的名称，提醒您这是一个非恶意网络抓取工具，可以将其抓取到其他用户的WebForm中会话。这是为了与恶意爬虫形成鲜明对比，它试图闯入另一个用户的会话。没有什么能像迂腐一样带来恶化。
答案 0 :(得分：9)
虽然问题主要是引用会话标识符，但标识符的长度让我觉得异常。
至少有两种类型的cookie / cookieless操作可以修改查询字符串以包含ID。
他们完全相互独立（据我所知）。
无Cookie会话允许服务器根据URL中的唯一ID与Cookie中的唯一ID访问会话状态数据。这通常被认为是一种很好的做法，尽管ASP.Net重用会话ID，这使得它更容易进行会话固定尝试（单独的主题，但值得了解）。
ASP.net中的会话标识是否仅依赖于cookie？能够 任何人，从任何IP，与cookie-url，访问该会话？是否 默认情况下，ASP.net也不考虑？
会话ID就是所需要的。
General Session Security Reading
根据示例数据的长度，我猜你的URL实际上包含表单身份验证值，而不是会话ID。源代码表明，无Cookie必须明确启用。
/// <summary>ASP.NET determines whether to use cookies based on
/// <see cref="T:System.Web.HttpBrowserCapabilities" /> setting.
/// If the setting indicates that the browser or device supports cookies,
/// cookies are used; otherwise, an identifier is used in the query string.</summary>
UseDeviceProfile
以下是如何做出决定：
// System.Web.Security.CookielessHelperClass
internal static bool UseCookieless( HttpContext context, bool doRedirect, HttpCookieMode cookieMode )
{
switch( cookieMode )
{
case HttpCookieMode.UseUri:
return true;
case HttpCookieMode.UseCookies:
return false;
case HttpCookieMode.AutoDetect:
{
// omitted for length
return false;
}
case HttpCookieMode.UseDeviceProfile:
if( context == null )
{
context = HttpContext.Current;
}
return context != null && ( !context.Request.Browser.Cookies || !context.Request.Browser.SupportsRedirectWithCookie );
default:
return false;
}
}
猜猜默认是什么？ HttpCookieMode.UseDeviceProfile。 ASP.Net维护一个设备和功能列表。这个清单通常是一件非常糟糕的事情; example, IE11 gives a false positive for being a downlevel browser与Netscape 4相同。
我认为Gene的解释很可能; Google从某些用户操作中找到了该网址，并对其进行了抓取。
完全可以想象Google僵尸程序被视为不支持cookie。但这并不能解释网址的来源，即用户操作导致Google看到其中已包含ID的网址？一个简单的解释可能是浏览器被认为不支持cookie的用户。根据浏览器的不同，其他所有内容对用户来说都很好。
时间，即有效期似乎很长，虽然我不熟悉身份验证票有效期多长以及在什么情况下可以续订。 ASP.Net完全有可能继续重新发布/续订门票，就像它对持续活跃的用户一样。
我在这里做了很多假设，但如果我是对的：
使用HttpCookieMode.UseCookies明确禁用无Cookie行为。
<强>的web.config ：
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx" name=".ASPXFORMSAUTH" timeout="26297438"
cookieless="UseCookies" />
</authentication>
虽然这应解决该问题，但您可以调查扩展表单身份验证HTTP模块并添加其他验证（或至少记录/诊断）。
答案 1 :(得分：7)
你问了想法，所以我会给一些。没有明示或暗示的保证。
放弃您的网站配置不在URI中编码会话信息的想法。它的概率非常高。要么你对配置有误，要么（更有可能）有一个导致它这样做的错误。
这留下了一个核心问题：Google如何获得会话URI？
您没有说客户群。这是一个猜测：
客户以产生会话URI编码的方式登录系统，然后使用gmail帐户通过电子邮件将其发送给其他人。 Google扫描了该电子邮件，并将该URI提供给了抓取工具。
还有其他类似的方式，客户生成URI的客户可能会无意中将其交给Google。 Google云端硬盘文档。 Google Plus发帖。等等。
谷歌可能并不邪恶，但它们无处不在。他们的使用协议允许他们跨产品边界移动链接，在这种情况下邮件（等）搜索。您应该考虑的真正问题是，为什么您的网站不受跨站点请求伪造的保护。 Rails人员explain this pretty nicely。 Rails protect_from_forgery机制会阻止报告的问题。
一个相关的问题是为什么编码的cookie（显然）永不过期。要使会话包含时间戳，应该很容易实现这一点。