码迷,mamicode.com
首页 > Web开发 > 详细

web 应用常见安全漏洞

时间:2020-12-09 12:21:20      阅读:10      评论:0      收藏:0      [点我收藏+]

标签:ace   for   http   否则   情况   server   失效   rdp   安全措施   

关注公众号: 微信搜索 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

web 应用常见安全漏洞

标签:ace   for   http   否则   情况   server   失效   rdp   安全措施   

原文地址:https://www.cnblogs.com/ljx20180807/p/14088599.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!