代码之家  ›  专栏  ›  技术社区  ›  TruMan1

自动编码文本输入的策略?

  •  1
  • TruMan1  · 技术社区  · 14 年前

    为了防止应用程序因错误“检测到潜在的危险请求。表单值…”而崩溃,我刚刚关闭了页面验证。我想重新审视并正确解决这个问题。

    有好的策略吗?如果人们正在输入“<”和“>”,我认为保存数据的唯一方法是通过Javascript对其进行编码。我试着在代码后面找到它,但已经太晚了。我正在考虑继承文本框并用客户端脚本自动编码/解码输入。我还必须考虑所有已经保存在数据库中的尖括号。

    有什么建议或经验吗?

    4 回复  |  直到 14 年前
        1
  •  0
  •   Genius    14 年前

    在发布数据之前,您可以避开危险的字符。这样地:

    string = escape(string);
    

    然后在服务器端:

    var stringVal = Server.UrlDecode(Request["string"]);
    

    差不多吧。

        2
  •  1
  •   Gideon    14 年前

    我从你的回答中得知,你不想让你的客户给你发送“危险”的内容,所以最好把页面验证打开,作为最后一道防线,而不是关闭它并使用 Server.HtmlEncode 对每个用户输入值(可能会丢失一个值,这是一项繁重的工作)。

    我会使用javascript解决方案,例如,您可以使用jQuery之类的库,并钩住表单的提交事件,在提交之前整理输入。比创建自己的派生文本框更干净。

    对于没有javascript的用户,或者那些试图“破解”你的小脚本的用户,sc#!他们会到达你的最后一道防线,然后犯错误。

        3
  •  1
  •   Jon Hanna    14 年前

    最好将内置页面验证视为一种安全设备,它不适用于所有情况。有不止几次,当它完全不可能做某事时,它打开。在这些情况下,我们会关闭它,自己处理验证。

    最明显的情况是,有时我们确实希望向服务器发送大块的HTML。当然,这样做仍然需要确保安全,但是“哦,那看起来像是一大块HTML!引发安全异常!”显然不是正确的方法。

    因此,在这些情况下,关闭页面验证并添加自己的服务器端是非常明智的。这确实意味着,您必须考虑如何在比以前更仔细的检查下使用此输入。沿着每个数据输入的路径(不仅仅是那些你希望看到的字符 < ,并确保它永远不会被不加掩饰地发送回客户,或者确保它经过彻底检查以确保安全。

        4
  •  0
  •   Community CDub    8 年前

    你有没有考虑过使用,

    Server.HtmlEncode(input) 
    

    没有必要在客户端使用javascript。使用上述技术,您可以在服务器端轻松地执行此操作。

    可能是 this 问题 /BB公司