微软在 .NET 生态系统中集成了大量安全机制，从身份验证集成到默认禁用调试信息，几乎所有关键环节都有覆盖。这种对安全的高度重视，确实促使许多开发者在软件开发过程中重新审视安全保障的重要性。但理想与现实之间总存在差距——根据 SPI Dynamics 的客户服务记录，.NET 开发人员反复栽在几个常见陷阱上，以下六条尤为突出。
1、在开发过程中没有考虑安全
如果从编码第一天起就将安全融入代码，开发周期和成本都能降到最低。安全实践还能让应用更稳定、更少出现故障。反之，如果等到 QA 测试甚至用户验收阶段才想起安全问题，那么返工、延期、预算超支几乎不可避免——代价往往远超预期。
2、SQL注入
简单来说，SQL 注入就是攻击者向应用注入一段恶意 SQL 代码，目的通常不单纯。如果 Web 应用过滤不严，这段代码就会被传递到数据库，而数据库不会区分恶意与否，只会执行。例如，当开发人员未对单引号等非法输入进行防护时，攻击者就能拼凑出恶意 SQL 字符串，直接暴露系统与应用的访问权限。
3、跨站脚本攻击
跨站脚本（XSS）通常从用户输入进入，再回到用户浏览器。动态页面如果未对输入进行验证，攻击者就能在生成的页面中插入恶意 Ja vaScript，任何访问者都会中招。攻击者可借此窃取机密信息、操控 Cookie，甚至伪造用户请求、在终端上执行恶意代码。
4、使用用户输入作为文件名
不少开发人员喜欢用一个参数来决定显示哪个文件，例如 myPageGenerator.aspx?Template=Welcome.html。这种用法本身没问题，但关键是要确保请求的文件位于正确的文件夹内。攻击者很容易修改查询字符串，访问到本应隐藏的文件，比如 myPageGenerator.aspx?Template=../../../../../../boot.ini。
5、不当地使用Cookie和隐藏参数
Cookie 和隐藏参数是开发人员惯用的“小仓库”，从会话令牌到各种关键信息都往里面存。常见的陷阱包括将产品定价、信用卡号、账户信息等敏感数据也塞进去。别忘了——攻击者修改 Cookie 几乎不费吹灰之力。
6、在Web.config文件中开启调试选项
Web.config 中有专门设置控制 .NET 应用如何处理错误。正常做法是向用户显示一句“友好”提示，比如“网站遇到技术困难，正在处理中”，而不应暴露任何技术细节。攻击者能从错误信息中挖掘出大量有用情报——在 ASP.NET 中开启详细错误消息，几乎是所有安全漏洞中最大的那个。
下面是有效的设置（描述摘自 Visual Studio .Net 默认生成的 Web.config 文件）：
（这里原表位置，请保留原数据）
总结
无论安全漏洞是否被公开，攻击者能接触到你的敏感数据，这才是实实在在的风险。它值得公司、股东，尤其是你的客户，认真对待。SPI Dynamics 发现，大多数公司一提到自家应用安全就谨慎得像在谈论什么机密——看来应用程序安全问题在未来很长一段时间，仍然是攻击者的首选目标。
