我应该了解哪些常见的网络漏洞利用？
对于Web编程，我还是很环保的，我将大部分时间都花在了客户端应用程序上。因此，我对自己应该在自己的网站中担心/测试的常见漏洞感到好奇。
解决方案
回答
这三个是最重要的：
- 跨站请求伪造
- 跨站脚本
- SQL注入
回答
最常见的可能是数据库注入攻击和跨站点脚本攻击。主要是因为这些是最容易实现的(很可能是因为这些是程序员最懒惰的)。
回答
bool UserCredentialsOK(User user)
{
if (user.Name == "modesty")
return false;
else
// perform other checks
}
回答
我们甚至可以在此站点上看到，我们所要寻找的最具破坏性的事情是将代码注入到应用程序中，因此，XSS(跨站点脚本)和SQL注入(@Patrick的建议)是我们最大的担忧。
基本上，我们将要确保，如果应用程序允许用户注入任何代码，则将对其进行监管和测试，以确保只有我们确定要允许的内容(html链接，图像等) )被传递，则不执行其他任何操作。
回答
这也是Wordpress的核心开发人员之一关于安全性的简短简短演讲。
Wordpress中的安全性
它涵盖了Web应用程序中的所有基本安全问题。
回答
SQL注入。跨站脚本。
回答
SQL注入攻击。它们很容易避免，但是太普遍了。
永远永远永远(我是否提到过"永远"？)信任从表单元素传递给用户信息。如果在将数据传递到应用程序的其他逻辑层之前未进行数据审查，则最好将站点的密钥提供给大街上的陌生人。
我们没有提到我们所使用的平台，但是如果在ASP.NET上，可以先读一下Scott Guthrie和他的文章"技巧/窍门：防范SQL注入攻击"。
之后，我们需要考虑允许用户向数据库中提交并最终从数据库中提交的数据类型。如果我们允许插入HTML并在以后出现，则我们很容易受到跨站点脚本攻击(称为XSS)的攻击。
这些就是我想到的两个，但是我们自己的Jeff Atwood在Coding Horror上有一篇不错的文章，其中回顾了"软件安全的19个致命罪"一书。
回答
使用存储过程和/或者参数化查询对保护我们免受SQL注入大有帮助。也不要让Web应用程序以sa或者dbo身份设置标准用户帐户并设置权限来访问数据库。
XSS的AS(跨站点脚本)ASP.NET具有一些内置的保护。最好的办法是使用验证控件和Regex过滤输入。
回答
OWASP保留了要注意的十大Web攻击列表，以及用于Web开发的大量其他有用的安全信息。
回答
我不是专家，但是据我到目前为止所学，黄金法则是不信任任何用户数据(GET，POST，COOKIE)。常见的攻击类型以及如何保存自己：
- SQL注入攻击：使用准备好的查询
- 跨站点脚本：没有先过滤/转义，就不会将用户数据发送到浏览器。这也包括存储在数据库中的用户数据，这些数据最初来自用户。
回答
这里的大多数人都提到了SQL Injection和XSS，这是正确的，但是作为Web开发人员，我们需要担心的最重要的事情就是INPUT VALIDATION，这是XSS和SQL Injection的起源。
例如，如果我们有一个只接受整数的表单字段，请确保在客户端和服务器端都实现某种操作以清理数据。
检查并仔细检查所有输入数据，特别是如果这些输入数据最终要在SQL查询中结束时。我建议构建一个逃逸器函数，并将其包装到查询中。例如：
$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";
同样，如果我们要将任何用户输入的信息显示到网页上，请确保已剥离任何<script>标记或者可能导致Javascript执行的其他所有内容(例如onLoad = onMouseOver =等)。 )。
回答
我在这里发布OWASP Top 2007的缩写列表，这样人们就不必浏览另一个链接，以防源丢失。
跨站点脚本(XSS)
- 每当应用程序获取用户提供的数据并将其发送到Web浏览器而未首先验证或者编码该内容时，就会发生XSS漏洞。 XSS允许攻击者在受害者的浏览器中执行脚本，该脚本可能劫持用户会话，破坏网站，可能引入蠕虫等。
注射缺陷
- 注入缺陷，特别是SQL注入，在Web应用程序中很常见。当用户提供的数据作为命令或者查询的一部分发送到解释器时，就会发生注入。攻击者的敌对数据会诱使解释器执行意外的命令或者更改数据。
恶意文件执行
- 容易受到远程文件包含(RFI)攻击的代码使攻击者能够包含敌对代码和数据，从而造成破坏性攻击，例如全面破坏服务器。恶意文件执行攻击会影响PHP，XML和任何接受用户名或者文件的框架。
不安全的直接对象参考
- 当开发人员将对内部实现对象(例如文件，目录，数据库记录或者键)的引用作为URL或者表单参数公开时，就会发生直接对象引用。攻击者可以未经授权而操纵这些引用来访问其他对象。
跨站请求伪造(CSRF)
- CSRF攻击会强制已登录的受害者的浏览器向经过攻击的Web应用程序发送经过预先身份验证的请求，然后，该应用程序会迫使受害者的浏览器执行敌对行动，从而使攻击者受益。 CSRF可以与其攻击的Web应用程序一样强大。
信息泄漏和错误处理
- 应用程序可能会无意间泄漏有关其配置，内部工作情况的信息，或者由于各种应用程序问题而侵犯隐私。攻击者利用此漏洞来窃取敏感数据，或者进行更严重的攻击。
身份验证和会话管理中断
- 帐户凭据和会话令牌通常没有得到适当的保护。攻击者会破坏密码，密钥或者身份验证令牌，以假定其他用户的身份。
不安全的密码存储
- Web应用程序很少正确使用加密功能来保护数据和凭据。攻击者使用受保护程度较弱的数据来进行身份盗用和其他犯罪，例如信用卡欺诈。
不安全的通讯
- 当必须保护敏感通信时，应用程序经常无法加密网络流量。
无法限制URL访问
- 通常，应用程序仅通过防止向未经授权的用户显示链接或者URL来保护敏感功能。攻击者可以利用此漏洞通过直接访问这些URL来访问和执行未经授权的操作。
开放式Web应用程序安全性项目
-亚当
回答
每个人都会说" SQL注入"，因为它是听起来最可怕的漏洞，也是最容易引起人们注意的漏洞。跨站点脚本(XSS)将排在第二位，因为它也很容易理解。 "输入验证欠佳"不是漏洞，而是对安全最佳实践的评估。
让我们从不同的角度尝试一下。当在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的数据。
