ASP.NET 会员提供商受到威胁?

发布于 2024-07-15 19:14:28 字数 1140 浏览 6 评论 0原文

我正在使用标准的开箱即用的 aspnet 会员资格提供程序,并且我在 web.config 中有以下设置:

<anonymousIdentification enabled="false"/>
<authentication mode="Forms">
    <forms cookieless="AutoDetect" loginUrl="~/XXXX.aspx" name="XXXXAuth" slidingExpiration="true" timeout="432000"/>
</authentication>
...
<membership defaultProvider="XXXMembershipProvider">
    <providers>
        <add name="XXXMembershipProvider" type="System.Web.Security.SqlMembershipProvider" applicationName="XXX" connectionStringName="XXX" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" minRequiredPasswordLength="5" minRequiredNonalphanumericCharacters="0" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" passwordAttemptWindow="10" passwordStrengthRegularExpression=""/>
    </providers>
</membership>

今天我遇到了一个问题,用户报告说他们登录并注意到该网站说他们已经登录......作为一个完全不同的用户。 联系这两个用户后,发现他们都没有从共享计算机访问该网站。 这两个帐户的数据在数据库中都没有显示出任何被“黑客攻击”的迹象。

它托管在负载均衡器后面的两个 Web 服务器上。 数据库架构是一台用于读取的服务器,一台用于写入的服务器,并通过复制使它们保持同步。

有谁知道可能发生了什么导致这种情况?

I'm using the standard out-of-the-box aspnet membership provider, and I have the following settings in the web.config:

<anonymousIdentification enabled="false"/>
<authentication mode="Forms">
    <forms cookieless="AutoDetect" loginUrl="~/XXXX.aspx" name="XXXXAuth" slidingExpiration="true" timeout="432000"/>
</authentication>
...
<membership defaultProvider="XXXMembershipProvider">
    <providers>
        <add name="XXXMembershipProvider" type="System.Web.Security.SqlMembershipProvider" applicationName="XXX" connectionStringName="XXX" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" minRequiredPasswordLength="5" minRequiredNonalphanumericCharacters="0" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" passwordAttemptWindow="10" passwordStrengthRegularExpression=""/>
    </providers>
</membership>

Today I have had an issue where a user has reported that they went to log-in and noticed that the site was saying they were already logged-in.... as a completely different user. After contacting both users, it turns out neither accesses the site from a shared computer. Neither account's data shows any sign of being "hacked" in the database.

The is hosted on two web servers behind a load balancer. The database architecture is one server for reads, one for writes with replication keeping them in sync.

Does anyone know what might have occured to cause this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

错々过的事 2024-07-22 19:14:28

可以实现此目的的一个选项是 cookieless=AutoDetect。 如果用户的浏览器不支持 cookie,asp.net 将在 url 中嵌入加密的身份验证票证。 如果用户碰巧与他人共享链接,或者不太直接地将链接发布到论坛上,则他(她)会无意中访问他(她)的帐户。

An option that can make this happen is the cookieless=AutoDetect. If one user's browser doesn't support cookies, asp.net will embed the encrypted authentication ticket in the url. If the user happened to either share a link with the other, or less directly posted it on a forum, (s)he is giving unintended access to his(her) account.

一城柳絮吹成雪 2024-07-22 19:14:28

我想知道负载均衡器有多智能,以及它是否也缓存页面。

会员 cookie 被完全锁定了,所以非常怀疑它是否已被泄露。 如果负载均衡器也在缓存,它很可能不会传递请求。

I'm wondering how smart the load balancer is, and if it's caching pages as well.

The membership cookie is pretty damned locked down, so it's very very doubtful it's been compromised. If the load balancer is also caching it may well not be passing the request on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文