可以在其他网站上进行身份验证吗?

发布于 2024-08-25 03:51:22 字数 241 浏览 6 评论 0原文

如果我在 website#1 上,我在 website#1 上的登录页面上输入 website#2 的用户名/密码,而 website#1 在幕后向 website#2 发出 httpweb 请求并发布到登录页面。如果我随后导航到网站#2,我应该登录吗?

website#2 使用 formsauthentication,我调用 website#2 上的 httpHandler 并通过查询字符串向其传递用户名/密码。

这应该有效吗?

If I am on a website#1, and I enter my username/pwd for website#2 on a login page that is on website#1, and website#1, behind the scenes, makes a httpwebrequest to website#2 and posts to the login page. If I then navigate to website#2, should I be logged in?

website#2 uses formsauthentication and I call a httpHandler that is on website#2 and pass it the username/password via the querystring.

Should this work?

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

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

发布评论

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

评论(6

淤浪 2024-09-01 03:51:22

您尝试执行的操作称为单点登录。您这样做的方式(将值从一个站点发布到另一个站点)可能行不通,因为您使用的技术与黑客可能用来诱骗用户共享其登录信息的技术相同。这称为跨站点请求伪造攻击。 IIS 配置为不允许这样做。

通常,您需要一个中央身份验证系统,两个站点都使用该系统来共享登录信息。这可以通过多种方式完成,包括基于共享数据库的登录系统。谷歌“asp.net 单点登录”以获得更多想法。

What you're trying to do is called Single Signon. The way you're doing it, posting values from one site to another, probably won't work because you're using the same technique a hacker might use to trick user into sharing their login information. It's called a cross-site request forgery attack. IIS is configured not to allow that.

Generally, you need a central authentication system that both sites use to share login information. This can be done in several ways, including a shared database-based login system. Google "asp.net single sign on" for more ideas.

誰ツ都不明白 2024-09-01 03:51:22

站点#1 和#2 是否希望其用户进行单点登录?
如果是这样,请阅读单点登录。这是一个比这里可以解决的更大的项目。 Wrox 有一本关于这方面的好书:
http://www.amazon.com/Professional-ASP-NET-Security-Membership- Management/dp/0764596985/ref=cm_lmf_tit_10

还是我们在想象一些险恶的东西?
如果我们想象一些险恶的事情,那么邪恶站点 #1 就会收集凭据,然后在服务器端自动运行浏览器来开始检查站点 #2 是否使用相同的密码和用户组合。然后服务器将有一个经过身份验证的会话。这不会为访问站点 #1 的用户提供身份验证 cookie,服务器上的 HttpWebRequest 对象将获取身份验证 cookie。站点 #2 无法真正采取任何措施来阻止这种情况,因为来自一台计算机的浏览器请求看起来与来自另一台计算机的浏览器请求非常相似。精心设计的攻击会欺骗浏览器请求的所有元素,使其看起来像是来自浏览器而不是原始的 HttpWebRequest 对象,后者甚至可能不会设置用户代理。

站点 #2 应该停止使用密码和用户 ID,或者如果他们担心这个问题,则应使用 2 因素 ID,或者执行需要 javascript 进行登录的操作,因为欺骗正在执行 javascript 的浏览器比欺骗仅发送和接收 http 的浏览器更困难请求和响应。

Do site #1 and #2 want their users to have single sign on?
If so, read up on single sign on. It's a bigger project than can be addressed here. There is a good book on it though from Wrox :
http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10

Or are we imagining something sinister?
If we are imagining something sinister, then evil site #1 would collect the credentials, then automate a browser on the server side to start checking to see if site #2 uses the same password and user combination. Then the server would have an authenticated session. This wouldn't give the user who accessed site #1 an auth cookie, the HttpWebRequest object on the server would get the auth cookie. Site #2 couldn't really do anything to prevent this because a browser request from one computer looks much alike a browser request from another. A well crafted attack would spoof all elements of the browser's request so that it looks like it came from a browser instead of a primitative HttpWebRequest object, which may not even set the user-agent.

Site #2 should stop using passwords and user Id or use 2 factor ID if they are concerned abut this, or do something that requires javascript for logon because spoofing a browser that is executing javascript is harder than spoofing a browser that just sends and receives http requests and responses.

情痴 2024-09-01 03:51:22

尝试在站点之间进行自动身份验证存在太多安全问题。两个站点都需要有一个中央安全提供商,以便安全地完成切换。

我们使用 CA 的 Siteminder 进行跨站点身份验证。实际上,web 1 在 siteminder 服务器上创建一个唯一的会话 ID,并将所有凭据和信息传递给它。 Siteminder 调用 web2 并通过会话变量传递信息。 Web 2 从会话中检索数据并使用它。还有很多事情正在发生,但仅此而已。

为了做到这样的事情,我强烈考虑使用开箱即用的解决方案,因为通常编写自定义安全性通常会达不到

There are too many security issues trying to auto-authenticate between sites. There needs to be a central security provider that both sites belong to so that hand off is completed securely.

We use CA's Siteminder for cross site authentication. Effectively, web 1 creates a unique session id on the siteminder server and passes any credentials and info to it. Siteminder invokes web2 and passes the information by means of session variables. Web 2 retrieves the data from the session and uses it. There's much more going on there but that's the just of it.

To do something like this, I would strongly consider using an out of the box solution as generally coding up custom security generally falls short.

樱娆 2024-09-01 03:51:22

虽然在某些情况下可以以带有 POST 参数的 HTTP 请求的形式完成此操作,但一旦您浏览到站点 #2,您将不会通过身份验证。

这是因为,通常这些网站会在您的终端存储一个 cookie,并且这些网站是基于域的,这意味着即使您从网站 #1 获取并存储它,cookie 名称也不会与网站 #2 匹配。

此外,站点 #2 可能不容易进行身份验证,这通常是开发人员意识到的安全问题。这也可以被视为 XSS 的尝试。

如果您只是为自己做这件事,我建议您使用 LastPass 并节省大部分费用里面有你的信息。

请重新考虑你的目标以及如何实现它们,这不是方法。

编辑:链接文本。

While this can be done on some cases, in the form of an HTTP request with POST parameters, you will not be authenticated once you browse to site #2.

This is because, generally, these sites store a cookie on your end and these are domain-based, which means that even if you grabbed that and stored it yourself from site #1, the cookie name would not match site #2.

Additionally, site #2 may not be easy to authenticate against and this is usually a security concern that developers are aware of. This can be considered an attempt of XSS as well.

In case you're simply doing this for yourself, I'd recommend LastPass and save most of your info in it.

Please reconsider your goals and how to achieve them, this is not the way.

Edit: Link text.

浊酒尽余欢 2024-09-01 03:51:22

这可能会起作用,具体取决于网站 #2 上采取的安全措施。对于安全网站来说,这会失败。

我纯粹基于良好的安全性和良好的编码/设计实践而建议不要这样做。

如果您不清楚哪些安全措施可以阻止此问题,您可能应该进行自我教育,以便可以防止在您自己的网站上出现相同的问题。请参阅http://www.owasp.org/index.php/Top_10_2007

This could work, depending on the security measures in place on website #2. For a secure website, this would fail.

I would recommend against this purely on the basis of good security and good coding/design practices.

If you are unclear what security measures stop this, you should probably educate yourself so you can prevent the same issues on your own site. See http://www.owasp.org/index.php/Top_10_2007

凉城已无爱 2024-09-01 03:51:22

由于您的两个站点都使用 FormsAuthentication,您可以轻松地将它们配置为共享 FormsAuthentication 加密方案。

这将允许您自动执行跨应用程序身份验证:)

Since both your sites are using FormsAuthentication you can easily configure both of them to share FormsAuthentication encryption schemes.

This will allow you to do Cross Application Authentication automatically :)

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