传递查询字符串时绕过表单身份验证
在 ASP.Net 中,如果传入特定的查询字符串参数,是否有人知道绕过表单身份验证的方法?
例如:
mydomain.com/myprotectedpage.aspx
...我希望受到表单身份验证的保护(因此,重定向到登录页面)
mydomain.com/myprotectedpage.aspx?myBypassParameter=me
...我希望页面正常呈现
这是否可能?
In ASP.Net, is anyone aware of a way to bypass Forms Authentication if a specific query string parameter is passed in?
Such as:
mydomain.com/myprotectedpage.aspx
...I would like to be protected by Forms Authentication (and so, redirected to login page)
mydomain.com/myprotectedpage.aspx?myBypassParameter=me
...I would like the page to render as normal
Is this at all possible?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
实际上并不是任何“官方”的做法。
你可以做我所做的,就是有一个基页而不是 system.web.ui.page ,如下所示:
End Class
Not really any "official" way of doing it.
You could do what I do, is have a base page instead of system.web.ui.page like so:
End Class
在后面的代码中,您可以简单地使用
Request.QueryString["myBypassParameter"]
并检查其值。如果它是无效值,则使用 FormsAuthentication.RedirectToLoginPage 或自定义重定向将用户带回到登录页面。 但是,这似乎不是一种保护页面的安全方法。如果有人掌握了特定参数并设法访问您的受保护页面怎么办?另外,您需要确保 QueryString 值有效(可能通过正则表达式),以确保用户没有传递恶意代码,然后您的应用程序将读取该恶意代码。In your code behind, you could simply use
Request.QueryString["myBypassParameter"]
and check its value. If it's an invalid value, then useFormsAuthentication.RedirectToLoginPage
or a custom redirect to put the user back at the log in page. However, this doesn't seem like a secure method of protecting a page. What if someone got hold of the specific parameter and managed to gain access to your protected page? Also, you want to make sure that the QueryString value is valid (maybe by a regular expression) to ensure the user hasn't passed malicious code which will then be read by your application.您也许可以将一些快速代码塞入 Application_AuthenticateRequest 事件中。然后,您可以测试该参数并根据需要调整 User.Identity 以允许该页面。您还必须进行页面检查,以确保它不允许在所有受限制的页面上出现此行为。
但我不推荐这种设计作为一种方法。如果您需要以匿名方式访问受保护区域,最好将所有功能放入 UserControl 中,然后使用父页面的受保护/不受保护版本。这将使您能够控制发出的内容和时间。
You might be able to jam some quick code into the Application_AuthenticateRequest event. You could then test for the parameter and adjust the User.Identity as necessary to allow the page. You'd have to put in a page check as well to make sure it didn't allow this behavior on all restricted pages.
I wouldn't recommend this design as an approach though. If you need to have a protected area accessed in an anonymous fashion, it'd be better to put all of your functionality into a UserControl and then use a protected/unprotected version of a parent page. This would allow you to control what goes out and when.