关于安全性：我应该了解哪些常见的Web漏洞？

在进行Web编程时，我还是很环保的，我将大部分时间都花在了客户端应用程序上。因此，我对自己应该在自己的网站中担心/测试的常见漏洞感到好奇。

我将在此处发布OWASP Top 2007的缩写列表，这样人们就不必浏览另一个链接，以防源丢失。

跨站点脚本(XSS)

• 每当应用程序获取用户提供的数据并将其发送到Web浏览器而未首先验证或编码该内容时，就会发生XSS漏洞。 XSS允许攻击者在受害者的浏览器中执行脚本，该脚本可能劫持用户会话，破坏网站，可能引入蠕虫等。

注射缺陷

• 注入缺陷，特别是SQL注入，在Web应用程序中很常见。当用户提供的数据作为命令或查询的一部分发送到解释器时，就会发生注入。攻击者的敌对数据会诱使解释器执行意外的命令或更改数据。

恶意文件执行

• 容易受到远程文件包含(RFI)攻击的代码使攻击者能够包含恶意代码和数据，从而造成破坏性攻击，例如全面破坏服务器。恶意文件执行攻击会影响PHP，XML和任何接受用户名或文件的框架。

不安全的直接对象参考

• 当开发人员将对内部实现对象(例如文件，目录，数据库记录或键)的引用作为URL或表单参数公开时，就会发生直接对象引用。攻击者可以未经授权而操纵这些引用来访问其他对象。

跨站请求伪造(CSRF)

• CSRF攻击会强制已登录的受害者的浏览器向经过攻击的Web应用程序发送经过预先身份验证的请求，然后，该应用程序会迫使受害者的浏览器执行恶意操作，以使攻击者受益。 CSRF可以与其攻击的Web应用程序一样强大。

信息泄漏和错误处理

• 应用程序可能会无意间泄漏有关其配置，内部工作情况的信息，或者由于各种应用程序问题而侵犯隐私。攻击者利用此漏洞来窃取敏感数据或进行更严重的攻击。

身份验证和会话管理中断

• 帐户凭据和会话令牌通常没有得到适当的保护。攻击者会破坏密码，密钥或身份验证令牌，以假定其他用户的身份。

不安全的密码存储

• Web应用程序很少正确使用加密功能来保护数据和凭据。攻击者使用受保护程度较低的数据来进行身份盗用和其他犯罪，例如信用卡欺诈。

不安全的通讯

• 当需要保护敏感通信时，应用程序经常无法加密网络流量。

无法限制URL访问

• 通常，应用程序仅通过防止向未经授权的用户显示链接或URL来保护敏感功能。攻击者可以通过直接访问这些URL来利用此漏洞来访问和执行未经授权的操作。

开放Web应用程序安全性项目

-亚当

OWASP保留了要注意的十大Web攻击列表，以及用于Web开发的大量其他有用的安全信息。

这三个是最重要的：

• 跨站请求伪造
• 跨站脚本
• SQL注入

每个人都会说" SQL注入"，因为它是听起来最可怕的漏洞，也是最容易引起人们注意的漏洞。跨站点脚本(XSS)将排在第二位，因为它也很容易理解。"输入验证欠佳"不是漏洞，而是对安全性最佳做法的评估。

让我们从另一个angular尝试一下。当在Web应用程序中实现以下功能时，这些功能可能会使您感到困惑：

• 动态SQL(例如，UI查询生成器)。到目前为止，您可能已经知道，在Web应用程序中使用SQL的唯一可靠的方法是使用参数化查询，在该方法中，您可以将查询中的每个参数显式绑定到变量。当恶意输入不是明显的参数(例如名称)而是查询属性时，我最常看到Web应用程序违反此规则的地方。一个明显的例子是在搜索网站上看到的类似iTunes的"智能播放列表"查询生成器，其中诸如子句运算符之类的内容直接传递到后端。另一个需要克服的难题是表列排序，您将在其中看到HTTP参数中公开的DESC之类的信息。

• 文件上传。文件上传使人们感到困惑，因为文件路径名看起来像URL路径名一样可疑，并且因为Web服务器仅通过将URL指向文件系统上的目录就可以轻松实现"下载"部分。在我们测试的10个上传处理程序中，有7个允许攻击者访问服务器上的任意文件，因为应用程序开发人员假定对文件系统" open()"调用的权限与对查询的权限相同。

• 密码存储。如果您的应用程序在我丢失原始密码后可以将我的原始密码邮寄给我，则您将失败。密码存储只有一个安全可靠的答案，即bcrypt；如果您使用的是PHP，则可能需要PHPpass。

• 随机数生成。对Web应用程序的经典攻击：重置另一个用户的密码，并且由于该应用程序正在使用系统的" rand()"功能(该功能不是强密码)，因此密码是可以预测的。这也适用于您进行加密的任何地方。顺便说一句，您不应该这样做：如果您在任何地方都依赖加密，那么您很容易受到攻击。

• 动态输出。人们对输入验证过于信任。清理所有可能的元字符的用户输入的机会很小，尤其是在现实世界中，元字符是用户输入的必要组成部分。更好的方法是采用一致的机制来过滤数据库输出并将其转换为HTML实体，例如quot，gt和lt。 Rails会自动为您执行此操作。

• 电子邮件。许多应用程序都实现了某种出站邮件功能，使攻击者可以创建一个匿名帐户或完全不使用任何帐户来将攻击者控制的电子邮件发送到任意电子邮件地址。

除了这些功能之外，您在应用程序中可能犯的#1错误是在某个地方公开了数据库行ID，以便用户X只需将数字从" 5"更改为" 6"即可看到用户Y的数据。"。

这里的大多数人都提到了SQL Injection和XSS，这是正确的，但不要被愚弄-作为Web开发人员，您需要担心的最重要的事情是INPUT VALIDATION，这是XSS和SQL Injection的所在源于。

例如，如果您有一个仅接受整数的表单字段，请确保在客户端和服务器端都实现某种操作以清理数据。

检查并仔细检查所有输入数据，特别是如果这些输入数据最终将出现在SQL查询中时。我建议构建一个逃逸器函数，并将其包装到查询中。例如：

同样，如果您要将任何用户输入的信息显示到网页上，请确保已剥离所有标签或可能导致Javascript执行的其他所有内容(例如onLoad = onMouseOver =等)。 )。

SQL注入攻击。它们很容易避免，但是太普遍了。

从不永远永远(我是否提到过"永远"？)信任从表单元素传递给您的用户信息。如果在将数据传递到应用程序的其他逻辑层之前未对其进行审核，则不妨将您站点的密钥提供给大街上的陌生人。

您没有提到您所使用的平台，但是如果在ASP.NET上，请先了解一下Scott Guthrie及其文章"技巧/窍门：防范SQL注入攻击"。

此后，您需要考虑允许用户向数据库中提交并最终从数据库中提交的数据类型。如果您允许插入HTML并在以后出现，则您很容易受到跨站点脚本攻击(称为XSS)的攻击。<??pb>

这是我想到的两个，但是我们自己的杰夫·阿特伍德(Jeff Atwood)在Coding Horror上有一篇不错的文章，其中回顾了《软件安全的19个致命罪》一书。

这也是wordpress的核心开发人员之一关于安全性的简短简短演讲。

wordpress中的安全性

它涵盖了Web应用程序中的所有基本安全问题。

我不是专家，但是到目前为止，我所学到的黄金法则是不信任任何用户数据(GET，POST，COOKIE)。常见的攻击类型以及如何保存自己：

使用存储过程和/或参数化查询对保护您免受sql注入大有帮助。另外，不要让您的Web应用程序以sa或dbo身份访问数据库-设置一个标准用户帐户并设置权限。

Xpa的

AS(跨站点脚本)ASP.NET具有一些内置保护。最好的办法是使用验证控件和Regex过滤输入。

SQL注入。跨站脚本。

您甚至可以在此站点上看到，您所要寻找的最具破坏性的事情涉及到将代码注入到您的应用程序中，因此XSS(跨站点脚本)和SQL注入(@Patrick的建议)是您最大的担忧。
基本上，您将要确保，如果您的应用程序允许用户注入任何代码，则将对其进行监管和测试，以确保只有您确定要允许的内容(html链接，图像等) )被传递，并且不执行其他任何操作。

最常见的可能是数据库注入攻击和跨站点脚本攻击；主要是因为这些是最容易实现的(很可能是因为这些是程序员最懒惰的)。