阅读数:236 评论数:0

1.注入

注入攻击漏洞，例如SQL、OS、LDAP注入。这些攻击发生在当不可信的数据作为命令或查询语句的一部分，被发送给解释器的时候，攻击者发送的恶意数据可以欺骗解释器，以执行计划外的命令或未授权的查询。

（1）SQL注入的解决方案

造成 SQL injection 攻击的根本原因在于攻击者可以改变 SQL 查询的上下文，使程序员原本要作为数据解析的数值，被篡改为命令了。当构造一个 SQL 查询时，程序员应当清楚，哪些输入的数据将会成为命令的一部分，而哪些仅仅是作为数据。参数化 SQL 指令可以防止直接窜改上下文，避免几乎所有的SQL injection 攻击。参数化 SQL 指令是用常规的 SQL 字符串构造的，但是当需要加入用户输入的数据时，它们就会创建捆绑参数，这些捆绑参数是一些占位符，用来存放随后插入的数据。捆绑参数可以使程序员清楚地分辨数据库中的数据，即其中有哪些输入可以看作命令的一部分，哪些输入可以看作数据。这样，当程序准备执行某个指令时，它可以详细地告知数据库，每一个捆绑参数所使用的运行时的值，而不会将数据解析成命令。

2.失效的身份认证和会话管理

与身份认证和会话管理相关的应用程序功能往往得不到正确的实现，这就导致了攻击者破坏密码、秘钥、会话令牌或攻击其他的漏洞去冒充其他用户的身份。

3.XSS跨站脚本

当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下，就将它发送给一个网页浏览器，这就会产生XSS，XSS允许攻击者在浏览器上执行脚本，从而劫持用户会话、危害网站、或者将用户转向恶意网站。

解决方法：

对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、REFER、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。尽量采用POST 而非GET 提交表单；对”<”，”>”,”;”,”’”，“javascript”，“jscript”，“vbscript”等字符做过滤；任何内容输出到页面之前都必须加以encode，避免不小心把html tag 弄出来。

4.不安全的直接对象引用

当开发人员暴露一个内部实现对象的引用时，就会产生一个不安全的直接对象引用，在没有访问控制检测或其他保护时，攻击者会操控这些相用去访问未授权数据。

5.安全配置错误

好的安全需要对应用程序、框架、应用程序服务器、web服务器、数据库服务器和平台定义和执行安全配置。由于许设置的默认值并不是安全的，因此，必须定义、实施和维护这些设置。这包含了对所有的软件保持及时更新，包括所有应用程序的库文件。

6.敏感信息泄露

许多web应用程序没有正确包含敏感数据，敏感数据需要额外的保护。

7.功能级访问控制缺失

8.CSRF跨站请求伪造。

会在以下情况下发生：

（1）. Web 应用程序使用会话 cookie。

（2）应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

假设有一个 Web 应用程序，它允许管理员通过提交此表单来创建新帐户：

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

攻击者可能会使用以下内容来建立一个网站：

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

如果 example.com 网站的管理员在网站上具有活动会话时访问了此恶意页面，则她会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

解决方案

（1）使用会话 cookie 的应用程序必须在每个表单发布中包含几条信息，以便后端代码可以用来验证请求的来源。其中一种方法是包含随机请求标识符或 nonce，如下所示：

RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
body = addToPost(body, request_id);
rb.sendRequest(body, new NewAccountCallback(callback));

这样，后端逻辑可先验证请求标识符，然后再处理其他表单数据。如果可能，每个服务器请求的请求标识符都应该是唯一的，而不是在特定会话的各个请求之间共享。对于会话标识符而言，攻击者越难猜出请求标识符，则越难成功进行 CSRF 攻击。标记不应能够轻松猜出，它应以保护会话标记相同的方法得到保护，例如使用 SSLv3。

（2）框架保护：大多数现代化的 Web 应用框架都嵌入了 CSRF 保护，它们将自动包含并验证 CSRF 标记。

（3）使用质询-响应控制：强制客户响应由服务器发送的质询是应对 CSRF 的强有力防御方法。可以用于此目的的一些质询如下：CAPTCHA、密码重新身份认证和一次性标记。

（4）检查 HTTP Referer/原始标题：攻击者在执行 CSRF 攻击时无法冒仿这些标题。这使这些标题可以用于预防CSRF 攻击。

（5）再次提交会话 Cookie：除了实际的会话 ID Cookie 外，将会话 ID Cookie 作为隐藏表单值发送是预防 CSRF 攻击的有效防护方法。服务器在处理其余表单数据之前，会先检查这些值，以确保它们完全相同。如果攻击者代表用户提交表单，他将无法根据同源策略修改会话 ID Cookie 值。

（6）限制会话的有效期：当通过 CSRF 攻击访问受保护的资源时，只有当作为攻击一部分发送的会话 ID 在服务器上仍然有效时，攻击才会生效。限制会话的有效期将降低攻击成功的可能性。

9.使用包含已知漏洞的组件。

10.未验证的重定向和转发。