更为重要的是，应确保只有经过授权的用户才能够执行可能具有严重后果的操作，如删除表。这要求认真仔细地设计应用程序的中间层。好的技巧（不光是为了安全性）应把焦点集中在角色上。应当将用户分组为各种角色，并为各个角色定义一个包含一组最少的权限的帐户。
几周前，wintellect Web 站点受到一种很复杂的 SQL 注入的攻击。那位黑客试图创建并启动一个 FTP 脚本来下载一个可能是恶意的可执行程序。幸运的是，这次攻击失败了。或者，其实是强用户验证，使用存储过程和使用 SQL Server 权限，导致了攻击未能成功？
总而言之，您应当遵循这些指南，以避免被注入有害的 SQL 代码：
| • | 使用尽可能少的权限运行，永远不以“sa”身份执行代码。 |
| • | 将访问限制给内置的存储过程。 |
| • | 首选使用 SQL 参数化查询。 |
| • | 不通过字符串串连来生成语句，不回显数据库错误。 |
返回页首在传统的 ASP 中，隐藏域是唯一一种在请求之间保持数据的方法。您需要在下一个请求中检索的任何数据都被打包到隐藏的 <input> 域中，并执行回程。如果有人在客户端上修改了该域中存储的值，会怎样？只要文本是明文的，服务器端环境就无法测知这一情况。ASP.NET 中，页和各个控件的 viewstate 属性有两个用途。一方面，viewstate 是跨请求保持状态的方法;另一方面，viewstate 使您能够在受保护的、不易篡改的隐藏域中存储自定义值。
如图 2 所示，视图状态被附加了一个哈希值，对于每条请求，都会检查该值，以检测是否发生了篡改。除少数几种情况外，没有任何理由要在 ASP.NET 中使用隐藏域。视图状态能够以安全得多的方式实现相同的功能。前面开门见山地讲到过，在明文的隐藏域中存储敏感的值（如价格或信用卡详细信息），相当于对黑客张开大门;视图状态甚至能够使这种不好的做法比以前更为安全，因为视图状态具有数据保护机制。但是，请牢记，视图状态可以防止篡改，但是并不能保证保密性，除非使用加密 — 存储在视图状态中的信用卡详细信息无论如何都有风险。
在 ASP.NET 中，哪些情况下使用隐藏域是可接受的？当您生成需要将数据发送回服务器的自定义控件时。例如，假定您要创建一个支持重派列顺序的新 datagrid 控件。您需要在回发中将新的顺序发送回服务器。如果不将这些信息存储到隐藏域中，又可以存储到哪里？
如果隐藏域为读/写域，即预期客户端会写入它，没什么办法能够完全制止黑客攻击。您可以尝试哈希或者加密该文本，但这并不能让您合理地确信不会遭受黑客攻击。此时，最好的防御就是让隐藏域包含惰性和无害的信息。
此外，应当注意 ASP.NET 公开了一个鲜为人知的类，可用于编码和哈希任何序列化的对象.该类为 losformatter，viewstate 实现用于创建回程到客户端的编码文本正是同一个类。
private string EncodeText(string text) { StringWriter writer = new StringWriter(); LosFormatter formatter = new LosFormatter(); formatter.Serialize(writer, text); return writer.ToString();}前面的代码片段演示了如何使用 losformatter 来创建类似视图状态的内容，对其编码并进行哈希。
返回页首在本文结尾，请让我指出，最常见的攻击中至少有两种（经典的 XSS 和一次单击）通常是通过诱使不抱怀疑的受害者单击诱惑性和欺骗性的链接来发起的。很多时候我们都可以在自己的收件箱中发现这样的链接，虽然有反垃圾邮件过滤器。几美元就可以买到大量电子邮件地址。用来生成这种列表的其中一种主要的技巧就是扫描 Web 站点上的公共页，查找并获取所有看上去像电子邮件的内容。
如果页上显示了电子邮件地址，很可能或早或晚这个地址都会被自动 Web 程序捕获。真的吗？当然，这要看该电子邮件