XSS攻击
Cross Site Scripting 跨站脚本攻击,是代码注入攻击的一种
把用户在此网站的cookie窃取到
如何防范:
- 像Thymeleaf等html模板引擎,都会做编码的
- server端程序使用commons-lang3#StringEscapeUtils,做转义
CSRF攻击
cross-site request forgery:跨站请求伪造
攻击方式1:
-
假设你经常使用bank.example.com进行网上转账,在你提交转账请求时bank.example.com的前端代码会提交一个HTTP请求,所以这个浏览器中已经包含了相关的cookie,这个cookie是非常重要的
POST /transfer HTTP/1.1 Host: bank.example.com cookie: JsessionID=randomid; Domain=bank.example.com; Secure;HttpOnly Content-Type: application/x-www-form-urlencoded amount=100.00&routingNumber=1234&account=9876
-
你图方便没有登出bank.example.com,随后又访问了一个恶意网站,如attacker.com,其提供了一个html页面,用户无法分辨出这是一个真实的站点,还是一个伪造的站点。
<form action="https://bank.example.com/transfer" method="post"> <input type="hidden" name="amount" value="100.00"/> <input type="hidden" name="routingNumber" value="evilsRoutingNumber"/> <input type="hidden" name="account" value="evilsAccountNumber"/> <input type="submit" value="点击就送!"/> </form>
-
你被“点击就送”吸引了,当你点了提交按钮时你已经向攻击者的账号转了100元。现实中的攻击可能更隐蔽,恶意网站的页面可能使用Javascript自动完成提交。尽管恶意网站没有办法盗取你的session cookie(从而假冒你的身份),但恶意网站向bank.example.com发起请求时,你的cookie会被自动发送过去。而用户点击按钮就是一个表单提交,表单提交为了可用性考虑,浏览器同源策略不做限制。
-
浏览器允许提交,并携带了cookie
攻击方式2:
攻击者试图去欺骗用户,使得用户以为访问的是银行站点(钓鱼网站)
如何防范?
就是当浏览器GET请求mybank转账表单的时候,银行站点响应会添加一个有时效性的token=yyy(hidden),提交时会自动携带。
而攻击者伪造的转账表单中是不含有这个token的(同源策略也让攻击者不能读取bank.com转账表单的dom树),这样在服务器端就可以防护了
使用JWT token可以对CSRF攻击进行防护吗?
有些人认为前端代码将JWT通过HTTP header发送给服务端(而不是通过cookie自动发送)可以有效防护CSRF。在这种方案中,服务端代码在完成认证后,会在HTTP response的header中返回JWT,前端代码将该JWT存放到Local Storage里待用,或是服务端直接在cookie中保存HttpOnly=false的JWT。
在向服务端发起请求时,用Javascript取出JWT(否则前端Javascript代码无权从cookie中获取数据),再通过header发送回服务端通过认证。由于恶意网站的代码无法获取bank.example.com的cookie/Local Storage中的JWT,这种方式确实能防护CSRF,但将JWT保存在cookie/Local Storage中可能会给另一种攻击可乘之机,跨站脚本攻击——XSS,比如我通过留言等方式在此页面放了一个链接,点击链接之后,此页面就可以获取到存储在cookie/local storage中的jwt了,可以通过表单提交等方式写入到攻击者的系统中,从而获取jwt令牌
针对oauth2的CSRF攻击
前提:我们使用豆瓣app,通过支付宝,支付宝直接以code的方式返回授权码,并且在将用户从第三方client导向支付宝的时候,支付宝并不需要state参数
攻击者李四视角:
李四在自己支付宝联合登录点击”同意授权“之后,截获支付宝服务器返回的含有Authorization code
参数的HTTP响应
李四精心构造一个链接,它会触发豆瓣app向支付宝发起令牌申请的请求,而这个请求中的Authorization Code
参数正是上一步截获到的code
受害者张三的视角:
其登录了豆瓣app,张三通过站内信给李四发送了构造的链接,李四不小心点击了张三构造的链接。点击之后什么也没有发生。但是他不知道的是,其在后台已经把李四的支付宝联合登录与张三在豆瓣app网站上的用户绑定了。
令牌申请流程在张三的浏览器里被顺利触发
于是李四如果登录豆瓣app,那么其看到的是自己的信息。
李四如果通过支付宝联合登录豆瓣app,那么其看到的是张三的信息。
而张三根本不知道自己已经可以支付宝联合登录了,而且其通过自己的支付宝联合登录,并不能登录上去。
防范方法:
oauth中state的作用。state能防止的原因,就在于点击链接后续流程,并不是张三触发的,所以没有生成state。李四是无法伪造state的(与银行转账表单带有失效性token原理相同)
syn flood攻击
比如一些攻击者,不使用操作系统内核的tcp协议栈,而是自己构造出SYN帧,发给server之后却不发送ACK,使得服务器大量的连接都处理SYN-RECV状态,将操作系统内核中的SYN队列快速占满。这就是一种SYN攻击
如何防范:
采用syn cookie技术:TCP服务器接收到TCP SYN包并返回TCP SYN + ACK包时,不分配一个专门的数据区,而是根据这个SYN包计算出一个cookie值。这个cookie作为将要返回的SYN ACK包的初始序列号。当客户端返回一个ACK包时,根据包头信息计算cookie,与返回的确认序列号(初始序列号 + 1)进行对比,如果相同,则是一个正常连接,然后,分配资源,建立连接。
DNS劫持
访问了一个假的DNS Server,返回了一个错误的ip地址
运营商弹出一些广告,就是运营商的一些DNS Server把一些广告地址返回给我们,于是访问到这些
ARP欺骗
在一个本地网络中,alice和bob要进行通讯,正常情况下,各自的本地缓存中应该存着对方的ip-mac对应关系。
现在有一个攻击方charlie,其主动回答alice和bob的arp报文,这样,alice和bob发送的报文就全部都发送到charlie这里了。
其正向应用:比如在一个酒店里面,希望大家上网的时候都进行登录,也可以使用这种方式。
代理缓存污染
比如websocket中客户端发送的帧必须基于掩码编码,这是因为有一种攻击方式是针对代理服务器的缓存污染攻击
首先是有一个代理服务器,它实现是不当的,其不认识websocket协议,而只能透传http协议。在这种情况下,有一个黑客搭建了一个恶意服务器,这个服务器还提供了一个恶意页面。这个恶意页面中会使用javascript来建立一个websocket连接,攻击方式是这样的:
- 通过javascript代码发起websocket握手
- 这个代理服务器就按照正常的http头部,将其代理到恶意服务器了
- websocket建立好之后,后续传递的都是基于frame帧的数据,这个帧已经不是http格式了,但这个恶意页面通过javascript代码伪造出类似HTTP GET请求的帧数据,这个HTTP GET请求的Host是一个被攻击的服务器
- 由于代理服务器不认识websocket,所以其将这个请求直接透传给了恶意服务器
- 恶意服务器伪造被攻击服务的响应,这个响应是用来攻击 被攻击服务器 的
- 这个响应就被代理服务器做了缓存
- 代理服务器给恶意页面发送返回
- 当 被攻击服务器 的用户通过正常浏览器访问资源
- 在代理服务器中发现缓存,返回伪造的响应
- 从而向正常浏览器的用户返回伪造的信息
如何防范:
强制浏览器执行以下方法:
- 生成随机的 32 位 frame-masking-key,不能让 JS 代码猜出(否则可以反向构造)
- 对传输的包体按照 frame-masking-key 执行可对称解密的 XOR 异或操作,使代理服务器不识别,这样也就不会解析为http get请求了
DDoS攻击
当多个系统淹没目标系统(通常是一个或多个Web服务器)的带宽或资源时,就会发生拒绝服务(DDoS)攻击。 DDoS攻击使用多个唯一的IP地址或计算机,通常来自数千个感染了恶意软件的主机。