这个问题之所以存在,是因为它确实存在 具有历史意义,但事实并非如此 被认为是一个很好的主题问题 因为是本网站,所以请不要使用 作为证据,你可以问类似的问题 这里的问题。 更多信息:https://stackoverflow.com/faq


总有一些功能在边缘场景中很有用,但正是因为这个原因,大多数人都不知道它们。我要求的是课本上通常没有教过的特性。

你知道的是什么?


当前回答

我曾经开发过一个asp.net应用程序,它通过了一家领先的安全公司的安全审计,我学会了这个简单的技巧来防止一个不太为人所知但很重要的安全漏洞。

以下解释来自: http://www.guidanceshare.com/wiki/ASP.NET_2.0_Security_Guidelines_-_Parameter_Manipulation#Consider_Using_Page.ViewStateUserKey_to_Counter_One-Click_Attacks

考虑使用Page。ViewStateUserKey用于对抗一键式攻击。如果您对调用者进行身份验证并使用ViewState,请设置Page。Page_Init事件处理程序中的ViewStateUserKey属性,以防止一键式攻击。

void Page_Init (object sender, EventArgs e) {
  ViewStateUserKey = Session.SessionID;
}

将属性设置为您知道对每个用户都是唯一的值,例如会话ID、用户名或用户标识符。

A one-click attack occurs when an attacker creates a Web page (.htm or .aspx) that contains a hidden form field named __VIEWSTATE that is already filled with ViewState data. The ViewState can be generated from a page that the attacker had previously created, such as a shopping cart page with 100 items. The attacker lures an unsuspecting user into browsing to the page, and then the attacker causes the page to be sent to the server where the ViewState is valid. The server has no way of knowing that the ViewState originated from the attacker. ViewState validation and HMACs do not counter this attack because the ViewState is valid and the page is executed under the security context of the user.

通过设置ViewStateUserKey属性,当攻击者浏览到一个页面以创建ViewState时,该属性将初始化为攻击者的名字。当合法用户向服务器提交页面时,将使用攻击者的名称对页面进行初始化。结果,ViewState HMAC检查失败并生成异常。

其他回答

在网站发布并部署到生产服务器后,如果我们需要对服务器端按钮进行一些更改,则单击事件。我们可以在aspx页面本身中使用new关键字来覆盖现有的click事件。

例子

代码背后方法

 Protected void button_click(sender object, e System.EventArgs) 
  {
     Response.Write("Look Ma', I Am code behind code!")  
  }

覆盖方法:

<script runat="server">   
   Protected void new button_click(sender object, e System.EventArgs) 
  {
     Response.Write("Look Ma', I am overrided method!")  
  }

</script

通过这种方式,我们可以轻松地修复生产服务器错误,而无需重新部署。

包含在ASP中。Net 3.5 sp1:

customErrors现在支持“redirectMode”属性,值为“ResponseRewrite”。显示错误页面而不改变URL。 表单标记现在识别操作属性。非常适合在使用URL重写时使用

很多人提到了如何在重新编译时优化代码。最近我发现我可以在aspx页面中完成大部分的开发(后台代码),完全跳过构建步骤。只需保存文件并刷新页面。你所要做的就是把你的代码包装在下面的标签中:

<script runat="server">

   Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
     Response.Write("Look Ma', I didn't even had to build!")
   End Sub

</script>

一旦你完成了,只要移动到代码背后,构建,测试一切工作,瞧!

-D

在ASP。NET v3.5添加了一些路由,你可以创建自己的友好url,只需在页面管道的早期编写HTTPModule并重写请求(如BeginRequest事件)。

像http://servername/page/Param1/SomeParams1/Param2/SomeParams2这样的url将被映射到如下所示的另一个页面(通常使用正则表达式)。

HttpContext.RewritePath("PageHandler.aspx?Param1=SomeParms1&Param2=SomeParams2");

DotNetNuke有一个非常好的HttpModule来为他们的友好url做这个。对于不能部署. net v3.5的机器仍然有用。

使用configSource拆分配置文件。

你可以在web中使用configSource属性。将配置元素推送到其他.config文件,例如: 而不是:

    <appSettings>
        <add key="webServiceURL" value="https://some/ws.url" />
        <!-- some more keys -->
    </appSettings>

...您可以将整个appSettings部分存储在另一个配置文件中。这是新的网络。配置:

    <appSettings configSource="myAppSettings.config" />

myAppSettings。配置文件:

    <appSettings>        
        <add key="webServiceURL" value="https://some/ws.url" />
        <!-- some more keys -->
    </appSettings>

这对于您向客户部署应用程序并且不希望他们干扰web的场景非常有用。配置文件本身,只是希望他们能够改变只是几个设置。

裁判:http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx