web 应用常见安全漏洞

关注公众号： 微信搜索 前端工具人 ; 收货更多的干货

摘抄自（本人博客）https://laijinxian.github.io/2019/03/04/Web-应用常见安全漏洞详解/#

作为Web端开发，不了解些攻击及漏洞有点说不过去，今天就来总结下常见的漏洞

1、SQL 注入

  • SQL 注入就是通过给 web 应用接口传入一些特殊字符，达到欺骗服务器执行恶意的 SQL 命令。
  • SQL 注入漏洞属于后端的范畴，但前端也可做体验上的优化。

原因

当使用外部不可信任的数据作为参数进行数据库的增、删、改、查时，如果未对外部数据进行过滤，就会产生 SQL 注入漏洞。
比如：

name = "外部输入名称"
sql = "select * from users where name="+ name;

上面的 SQL 语句目的是通过用户输入的用户名查找用户信息，因为由于 SQL 语句是直接拼接的，也没有进行过滤
所以，当用户输入''or'1'='1'时，这个语句的功能就是搜索users全表的记录。

select* from users where name=''or'1'='1';

解决方案

  • 具体的解决方案很多，但大部分都是基于一点：不信任任何外部输入。
  • 所以，对任何外部输入都进行过滤，然后再进行数据库的增、删、改、查。
  • 此外，适当的权限控制、不曝露必要的安全信息和日志也有助于预防 SQL 注入漏洞。
  • 参考《Web 安全漏洞之 SQL 注入 - 防御方法》(https://juejin.im/post/5bd5b820e51d456f72531fa8#heading-2) 了解具体的解决方案。

推荐参考

2、XSS 攻击

XSS 攻击全称跨站脚本攻击（Cross-Site Scripting），简单的说就是攻击者通过在目标网站上注入恶意脚本并运行，获取用户的敏感信息如 Cookie、SessionID 等

简单来说就是攻击者通过某种方式向浏览器页面注入了恶意代码，并且浏览器执行了这些代码；影响网站与用户数据安全。

这类攻击通常包含了HTML以及用户端脚本语言XSS 攻击更偏向前端的范畴，但后端在保存数据的时候也需要对数据进行安全过滤。

  1. 存储型
  2. 反射型
  3. DOM型

攻击原理

  • 存储型的XSS一般是指恶意代码注入后保存在后端数据库内，浏览器渲染时如果没有进行过滤和转义，则会执行其中的恶意代码，例如某个网站的用户个性签名，如果某个用户在个性签名内填入，
<script>alert(document.cookie)</script>

如果后端或者前端没有对此数据进行过滤转义处理，则会出现每个人访问该用户主页都会弹出他们浏览器的cookie，如果把这段代码换成将cookie值发送到攻击者的第三方服务器上，攻击者就可以轻易获得用户的敏感信息。

  • 反射型的XSS一般是指服务端返回恶意脚本，在客户端触发执行的攻击
http://xxx.com/index.php?s=<script>alert(document.cookie)</script>

服务器上并没有这样的内容，攻击者构造恶意URL，欺骗用户点击，触发XSS攻击。

  • DOM型的XSS一般是指代码部分本身有漏洞存在，例如在开发者在JS部分使用了location来调用URL上的数据处理部分逻辑，引发了反射型的URL恶意构造的隐患。

比如：

在一个文章应用中（如微信文章），攻击者在文章编辑后台通过注入script标签及js代码，后端未加过滤就保存到数据库，
前端渲染文章详情的时候也未加过滤，这就会让这段js代码执行，引起 XSS 攻击。

解决方案

  • SS` 主要是指恶意注入代码，所以不要相信任何用户的输入，确保用户输入的安全性，对输入输出数据进行转义编码过滤。
  • 基本的思路是渲染前端页面（不管是客户端渲染还是服务器端渲染）或者动态插入 HTML 片段时，任何数据都不可信任，都要先做 HTML 过滤，然后再渲染。
  • 《前端安全系列（一）：如何防止XSS攻击？ - 攻击的预防》(https://segmentfault.com/a/1190000016551188#articleHeader7) 了解具体的解决方案。

其他安全措施

  1. 页面使用Https
  2. 如果不能保证参数的可控性，慎用eval();
  3. 部分cookie可以设置httpOnly
  4. Html5 iframe标签的安全新特性，sandbox属性

推荐参考

3、CSRF 攻击

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF

  • 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
  • 跟跨網站指令碼（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

攻击原理 一个典型的 CSRF 攻击有着如下的流程：

1.用户A登陆某一网站（例如豆瓣），登陆成功后该用户浏览器客户端存留Cookie记录.
2.该网站有条删除用户日记的接口地址：http://www.douban.com/del/article/1
3.攻击者利用各种手段（微信发短网址链接等等）引诱用户A进入恶意网址。 恶意网址的Html内容如下：。

<img src="http:www.douban.com/del/article/1"/>

用户A在毫不知情的情况下请求了http:www.douban.com/del/article/1这个接口，由于他不久前登陆过豆瓣，客户端存留登陆成功的Cookie，就这样莫名的删除了自己的一篇日记，CSRF利用的就是这点，浏览器只能识别是否是该用户访问，却不能识别是否是该用户 本人意愿访问。

解决方案

  • 1.后端处理 (REFERER) （基本的思路是能正确识别是否是用户发起的请求）
    客户端向服务器发送请求时，Http请求头内存在一个Referer属性，属性值就是发起该次请求的域名。
    后端在代码里关键操作部分进行判断，如果Referer的值等于已知的域名（自家域名）则放行继续操作，否则打回。
    这种办法有局限性，因为不同浏览器对Referer这个实现可能会有差异，也不排除有攻击者直接攻击浏览器篡改Referer的可能。

  • 2.前后端配合处理（Token）

  • 后端在用户登陆成功时分配给该用户一个随机生成的Token值，存在session内，同时把这个Token值返回给前端，- - 前端可以把这个值存到cookie内或者其他本地存储，

  • 每次向服务器发起请求时把Token值作为参数一起传给后端，后端判断传过来的token是否和session中的token一致，一致则放行，否则打回。

  • 由于CSRF攻击者只能伪造用户的Cookie来骗过浏览器，但是他并不能得到Cookie中的具体值（例如Token值），

  • 所以这样的恶意请求会被后端打回，有效的防止了CSRF攻击。

推荐参考

4、DDoS 攻击

DoS 攻击全称拒绝服务（Denial of Service），简单的说就是让一个公开网站无法访问，而 DDoS 攻击（分布式拒绝服务 Distributed Denial of Service）是 DoS 的升级版。

这个就完全属于后端的范畴了。

原因

  • 攻击者不断地提出服务请求，让合法用户的请求无法及时处理，这就是 DoS 攻击。
  • 攻击者使用多台计算机或者计算机集群进行 DoS 攻击，就是 DDoS 攻击。

解决方案

推荐参考

5. XXE 漏洞

XXE 漏洞全称 XML 外部实体漏洞（XML External Entity），当应用程序解析 XML 输入时，如果没有禁止外部实体的加载，导致可加载恶意外部文件和代码，就会造成任意文件读取、命令执行、内网端口扫描、攻击内网网站等攻击。

这个只在能够接收 XML 格式参数的接口才会出现。

解决方案

推荐参考

6、JSON 劫持

JSON 劫持（JSON Hijacking）是用于获取敏感数据的一种攻击方式，属于 CSRF 攻击的范畴。

原因

  • 一些 Web 应用会把一些敏感数据以 json 的形式返回到前端，如果仅仅通过 Cookie 来判断请求是否合法
  • 那么就可以利用类似 CSRF 的手段，向目标服务器发送请求，以获得敏感数据。
  • 比如下面的链接在已登录的情况下会返回 json 格式的用户信息：
http://www.test.com/userinfo

攻击者可以在自己的虚假页面中，加入如下标签：

<script src = "http://www.test.com/userinfo"></script>

如果当前浏览器已经登录了www.test.com，并且 Cookie 未过期，然后访问了攻击者的虚假页面，那么该页面就可以拿到 json 形式的用户敏感信息，因为script标签会自动解析 json 数据，生成对应的 js 对象。然后再通过：

Object.prototype.__defineSetter__

这个函数来触发自己的恶意代码。
但是这个函数在当前的新版本 Chrome 和 Firefox 中都已经失效了。
注：上面的过程摘自《JSON和JSONP劫持以及解决方法》(https://blog.csdn.net/yjclsx/article/details/80353754)

解决方案

  • 1、X-Requested-With 标识
  • 2、浏览器 JSON 数据识别
  • 3、禁止 Javascript 执行 JSON 数据

推荐参考

7、暴力破解

这个一般针对密码而言，弱密码（Weak Password）很容易被别人（对你很了解的人等）猜到或被破解工具暴力破解。

解决方案

  • 1、密码复杂度要足够大，也要足够隐蔽
  • 2、限制尝试次数

8、HTTP 报头追踪漏洞

HTTP/1.1（RFC2616）规范定义了 HTTP TRACE 方法，主要是用于客户端通过向 Web 服务器提交 TRACE 请求来进行测试或获得诊断信息。
当 Web 服务器启用 TRACE 时，提交的请求头会在服务器响应的内容（Body）中完整的返回，其中 HTTP 头很可能包括 Session Token、Cookies 或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。

解决方案

禁用 HTTP TRACE 方法。

9、信息泄露

由于 Web 服务器或应用程序没有正确处理一些特殊请求，泄露 Web 服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。

需注意：

    1. 应用程序报错时，不对外产生调试信息
    1. 过滤用户提交的数据与特殊字符
    1. 保证源代码、服务器配置的安全

10、目录遍历漏洞

攻击者向 Web 服务器发送请求，通过在 URL 中或在有特殊意义的目录中附加../、或者附加../的一些变形（如..或..//甚至其编码），导致攻击者能够访问未授权的目录，以及在 Web 服务器的根目录以外执行命令。

11、命令执行漏洞

命令执行漏洞是通过 URL 发起请求，在 Web 服务器端执行未授权的命令，获取系统信息、篡改系统配置、控制整个系统、使系统瘫痪等。

12、文件上传漏洞

如果对文件上传路径变量过滤不严，并且对用户上传的文件后缀以及文件类型限制不严，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网站服务器。

需注意：

在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件
限制相关目录的执行权限，防范 webshell 攻击

13、其他漏洞

  • 1、SSLStrip 攻击
  • 2、OpenSSL Heartbleed 安全漏洞
  • 3、CCS 注入漏洞
  • 4、证书有效性验证漏洞

14、业务漏洞

一般业务漏洞是跟具体的应用程序相关，比如参数篡改（连续编号 ID / 订单、1 元支付）、重放攻击（伪装支付）、权限控制（越权操作）等。

另外可以参考：6种常见web漏洞坑(https://blog.csdn.net/xueshao110/article/details/78912988)。

15、框架或应用漏洞

  1. WordPress 4.7 / 4.7.1：REST API 内容注入漏洞
  2. Drupal Module RESTWS 7.x：Remote PHP Code Execution
  3. SugarCRM 6.5.23：REST PHP Object Injection Exploit
  4. Apache Struts：REST Plugin With Dynamic Method Invocation Remote Code Execution
  5. Oracle GlassFish Server：REST CSRF
  6. QQ Browser 9.6：API 权限控制问题导致泄露隐私模式
  7. Hacking Docker：Registry API 未授权访问

参考链接

  1. https://segmentfault.com/a/1190000018004657 作者： 深予之
  2. https://blog.shijukun.com/2018/09/25/soft/ 作者： Shiju
posted @ 2020-12-05 10:15  会写代码的赖先生  阅读(583)  评论(0)  编辑  收藏  举报