编者注:本文由我们的编辑团队于2022年12月8日更新. 它已被修改，以包括最近的来源，并与我们目前的编辑标准保持一致.

对于太多的公司来说，直到 after a security breach 网络安全最佳实践是否已经成为优先事项. 在我从事IT安全专业工作的这些年里, 我一次又一次地看到，web开发安全问题的世界对我的许多人来说是多么模糊 fellow programmers.

根据定义，应对网络安全威胁的有效方法必须是主动和防御的. Toward that end, 我们的目标是激发一种安全思维，给读者注入一剂健康的偏执.

In particular, 本指南的重点是培养对10个常见和重要的网络安全缺陷的认识并减轻这些缺陷.

身份验证与授权:网络安全入门

程序员和IT专业人员经常对授权和身份验证之间的区别表示困惑. 缩写的用法 auth 因为这两个词都增加了它们周围的朦胧.

让我们来定义和澄清它们的区别:

• Authentication: 验证用户是(或至少看起来是)他们所说的那个人.
• Authorization: 授予用户对特定资源的访问权限或执行特定操作的权限.

Stated another way, authentication 知道一个实体是谁，而 authorization 是一个给定的实体能做什么. 考虑到这一点，让我们来探索10个常见的互联网漏洞问题.

Injection Flaws

注入缺陷源于过滤不可信输入的典型失败. 当我们将未经过滤的数据传递给SQL服务器(SQL注入)时，可能会发生注入缺陷。, to the browser (via Cross Site Scripting)、到LDAP服务器(LDAP注入)或其他任何地方. 这里的问题是攻击者可以注入命令来劫持客户端的浏览器, resulting in loss of data.

应用程序从不受信任的源接收的任何内容都必须进行过滤, 最好是根据白名单. 由于配置困难，不建议使用黑名单. 黑名单也被认为很容易被黑客绕过. 杀毒软件产品通常会提供黑名单失败的典型例子. 模式匹配不起作用.

Prevention: 防止注入“简单地”就是过滤我们的输入并考虑哪些发送者是可信的. 过滤是一项相当艰巨的任务，因为我们需要处理所有输入，除非它毫无疑问是可信的.

如果我们在一个有1的系统中过滤999个输入,000 inputs, 我们仍然有一个领域可以成为阿喀琉斯之踵，摧毁我们的系统.

Using 二级SQL注入 将一个SQL查询结果注入另一个SQL查询结果也被认为是危险的. 这似乎是个好主意，因为数据库是可信的. 但如果边界不在，我们的输入可能间接来自恶意来源.

因为过滤是很难做到正确的, 我们建议使用框架的过滤函数. 它们被证明是有效的，并经过了彻底的审查. 如果您还没有使用框架，请考虑使用框架对服务器安全性的好处. .

Broken Authentication

在身份验证失败期间可能发生的问题不一定源于相同的根本原因. 不建议滚动您自己的身份验证代码，因为很难做到正确. 有无数可能的陷阱，这里有几个:

1. URL可能包含会话ID，并在引用头中泄漏它.
2. 密码在存储和/或传输过程中可能未加密.
3. 会话id可能是可预测的，因此很容易获得未经授权的访问.
4. 会话固定是可能的.
5. 如果没有正确实现超时，可能会发生会话劫持, 或者如果使用HTTP(没有SSL安全), etc.

Prevention: 避免与身份验证失败相关的web安全漏洞的最直接方法是实现框架. If you roll your own code, 要极度偏执，对可能出现的潜在问题进行自我教育.

跨站点脚本(XSS)

攻击者向您的web应用程序发送输入JavaScript标记. 当这个输入未经过处理返回给用户时，用户的浏览器将执行它. 这是一个相当普遍的输入消毒失败，本质上是一个子类 injection flaws). CSS可以像制作一个链接并说服用户点击它一样简单, 也可能是更邪恶的东西. 例如，在页面加载时，脚本将运行并被用来将您的cookie发送给攻击者.

Prevention: 简单地说，不要向客户机返回HTML标记. 这也可以保护您免受HTML注入, 当攻击者注入纯HTML内容(如图像或响亮但不可见的flash播放器). 要实现此解决方案，请转换所有 HTML entities to return something else. For example, convert