CSRF，XSS，SYN攻击，中间人，点击劫持

ph24
268 阅读10分钟

1.XSS

跨站脚本攻击

XSS的本质：恶意代码未经过滤，与网站正常的代码混在一起，浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行

XSS的危害
  • 挂马（向网站中注入木马程序）
  • 盗取用户Cookie
  • DDOS（拒绝服务）客户端浏览器
  • 钓鱼攻击
  • 删除目标文章，恶意篡改数据，嫁祸
  • 劫持用户web行为，甚至进一步渗透内网
  • 爆发Web2.0蠕虫
  • 蠕虫式的DDOS攻击
XSS的种类
  • 反射型
  • 存储型
  • DOM-Based型

反射型（非持久性）：服务端返回脚本，客户端执行

  • 譬如URL注入非法脚本，然后发送给受害用户（一般浏览器都有基本的防御措施，自带拦截过滤）
  • 譬如服务端返回的富文本中包含非法脚本，被直接展示

【攻击步骤】

  • 攻击者构造出特殊的URL，其中包含恶意代码
  • 用户打开带有恶意的URL时，网站服务端将恶意代码从URL中取出，拼接在HTML中返回给浏览器
  • 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行
  • 恶意代码窃取用户数据并发送到攻击者网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作

这种攻击通过URL传递参数的功能，比如网站搜索，跳转等

存储型（持久性）：后台存储了非法脚本，并且前端直接展示

  • 譬如发帖中包含恶意代码的内容，其他用户访问到该内容后，满足特定的条件即触发
  • 需要后台不过滤信息，并且前端展示时也不过滤信息

【攻击步骤】

  • 攻击者将恶意代码提交到目标网站的数据库中
  • 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在HTML中返回给浏览器
  • 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行
  • 恶意代码窃取用户数据并发送到攻击者网站，或者冒充用户的行为，调用目标网站的接口执行攻击者指定的操作

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖，商品评论，用户私信等

DOM-Based型：基于DOM或本地的XSS攻击

  • 譬如wifi流量劫持，DNS接持，并且直接返回钓鱼页面
  • 本质是需要更改DOM，严格来说某些反射型的攻击也能造成这个后果-通过url控制DOM
  • eval(),setTimeout(),setInterval(),Function(),innerHTML,document.write()

XSS有哪些注入方法

  • 在HTML中内嵌的文本中，恶意内容以script标签形成注入
  • 在内联的js中，拼接的数据突破了原本的限制（字符串，变量，方法名等）
  • 在标签属性中，而已恶意内容包含引导，从而突破属性值的限制，注入其他属性或标签
  • 在标签的href。src等属性中，包含js等可执行代码
  • 在onload，onerror，onclick等事件中，注入不受控制代码
  • 在style属性和标签中，包含类似background-image：url（‘javascript：...）的代码（新版浏览器已经可以防范）
  • 在style属性和标签中，包含类似expression（...）的CSS表达式代码（新版浏览器已经可以防范）
XSS的防范
  • 输入（和URL参数）进行过滤
  • 输出编码
  • Cookie设置http-only
  • CSP（Content Security Policy）
  • 验证码（防止脚本冒充用户提交危险操作）

CSP

  • 禁止加载外域代码，防止复杂的攻击逻辑
  • 禁止外域提交，网站被攻击后，用户的数据不会泄漏到外域
  • 禁止内联脚本执行（规则交严格）
  • 禁止未授权的脚本执行
  • 核里使用上报可以及时发现XSS，利于尽快修复问题

输入处理：包括用户输入，URL参数，post请求参数，Ajax

  • 黑名单过滤：将特定的标签进行替换成空的处理 比如<script>alert(1)</script>处理之后显示为alert(1)
  • 白名单过滤：特定输入规则才可以作为输入发送给服务器，比如表单验证，用户名输入要满足特定的规则，只要不满足就是非法的

输出处理：将动态的代码进行编码和转译

<script>alert(1)</script>

< : $lt;

> : &rt;

& : &amp;

" : &quot;

' : &#39;

\ : \\

/ : /

cookie设置为http-only

限制js脚本读取cookie，攻击者完成XSS注入后也无法窃取此Cookie

XSS的检测
  • 手动检测
  • 使用自动扫描工具寻找XSS漏洞，如，Arachni，Mozilla HTTP，Observatory，w3af

2.CSRF

跨站请求伪造，利用了服务端验证不足

  • 用户登录了A网站，有了cookie，没有退出登录，去访问了B网站，B网站又给A网站某个接口发送请求，这时候就会带上A的cookie，形成攻击

【cookie不是只有在同域名的情况下才会自动携带cookie吗？为什么B网站向A网站的某个接口发送请求，会带上cookie？】

cookie中有一个SameSite属性可以限制跨域请求中不能携带cookie，但是在这个属性是在Chrome 51（16年）才开始有的，所以在此之前攻击者可以在跨域请求中携带cookie

SameSite

Cookie的SameSite属性用来限制第三方Cookie，从而减少安全风险

【可以设置三个值】

  • Strict
  • Lax
  • None

Strict

最为严格，完全禁止第三方Cookie，跨站点时，任何情况下都不会发送Cookie，也就是说，只有当前网页的URL与请求目标一致时，才会带上Cookie

Set-Cookie:CookieName=CookieValue;SameSite=Strict

【缺点】这个规则过于严格，可能会造成非常不好的用户体验，比如，当前网页有一个GitHub连接，用户点击跳转就不会带有Github的cookie，跳转过去就总是未登录的状态

Lax

Lax稍微没有那么严格，大多数情况也是不发送第三方cookie，但是导航到目标网址的Get请求除外

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

设置Strict或者Lax以后，基本就杜绝了CSRF攻击，当然前提是用户浏览器支持SameSite属性

None

chrome计划将Lax设置为默认值，这个时候网站可以通过SameSite属性，将其设置为None，但是前提是必须同时设置Secure属性（Cookie只能通过HTTPS协议发送），否则无效，设置为None也就说允许跨域请求携带cookie

Set-Cookie: widget_session=abc123; SameSite=None; Secure

www.ruanyifeng.com/blog/2019/0…

防御

  • 加入验证码（保证是用户触发的行为）
  • 验证referer（限制发送的请求源）
  • 使用token（验证用户身份）
  • 自定义header（和token一个就道理，可说可不说）
  • 将Cookie的SameSite属性设置为lax/strict（但是不能保证所有的都可以防御）

【token验证机制】

  • 用户在登录的时候，输入用户名和密码，进行登录
  • 服务器对登录用户进行认证，如果认证通过，根据用户的信息和JWT的生成规则生成JWT Token
  • 服务器将该token字符串返回
  • 客户端得到token信息，将token存储在localStorage中
  • 当用户请求服务器API时，在请求Header中加入Authorization：Token
  • 服务端对Token进行校验，如果合法就解析其中内容，根据其拥有的业务逻辑和自己的业务逻辑给出响应结果，如果不通过返回HTTP 401，提示用户权限，通过就执行前端回调进入系统

3.中间人攻击

  • 中间人攻击时攻击方同时与服务端和客户端建立起了连接，并让对方认为连接是安全的，但是实际上整个通信过程都被控制了，攻击者不仅能获得双方的通信信息，还能修改通信信息

  • 通常来说不建议使用公共的WIFI，因为很有可能会发生中间人攻击的情况，如果你在通信的过程中涉及到了某些铭感信息，就完全暴露给攻击方

  • 当然防御中间人攻击其实并不难，只需要增加一个安全通道来传输信息，HTTPS就可以用来防御中间人攻击，但是并不是使用lHTTPS就可以高枕无忧了，因为如果你没有完全关闭HTP访问的话，攻击方就可以用过某些方式将HTTPS降级为HTTP从而实现中间人攻击

4.点击劫持

点击劫持是一种视觉欺骗手段，攻击者将需要攻击的网站通过iframe嵌套的方式嵌入自己的网页中，并将ifarme设置为透明，在页面中透出一个按钮诱导用户点击

X-FRAME-OPTIONS

这是一个HTTP响应头，在现代浏览器有一个很好的支持，这个HTTP响应头和就是为了防御用ifame嵌套的点击劫持攻击

这个响应头有三个值可以选

  • DENY：表示页面不允许通过iframe的方式展示
  • SAMEORIGIN，表示页面可以在相同域名下通过iframe的方式展示
  • ALLOW-FROM，表示页面可以在指定源的iframe中展示

5.SYN攻击

TCP连接建立需要三次握手，假设攻击者短时间伪造不同IP地址的SYN报文，服务端每接收到一个SYN报文，就进入SYN_RCVD状态，但服务端发送出去的ACK+SYN报文，无法的到未知主机的ACK应答，久而久之就会**占满服务端的SYN接收队列（未连接队列），使服务器不能为正常用户服务

常见的防御SYN攻击的方法

  • 缩短超时时间（SYN Timeout时间）
  • 增加最大半连接数
  • 过滤网关防护
  • SYN cookies技术
避免SYN攻击方式一

通过修改Linux内核参数，控制队列大小和当队列满时应该做什么处理

  • 当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包

    net.core.netdev_max_backlog
//控制该队列的最大值

  • SYN_RCVD状态连接的最大个数

    net.ipv4.tcp_max_syn_backlog

  • 超出处理时，对新的SYN直接回报RST，丢弃连接

    net.ipv4.tcp_abort_on_overflow
避免SYN攻击方式二

Linux内核的SYN（未完成连接建立）队列与Accept（已完成连接建立）队列如何工作？

  • 当服务端接收到客户端的SYN报文时，会将器加入到内核SYN队列
  • 接着发送SYN+ACK给客户端，等待客户端回应ACK报文
  • 服务端接收到ACK报文后，从SYN队列移除放入Accept队列
  • 应用通过调用accept（） socket接口，从Accept队列取出连接

【如果应用程序过慢，就会导致Accept队列被占满】

【如果不断受到SYN攻击，就会导致SYN队列被占满】

解决SYN攻击方法

net.ipv4.tcp_syncookies=1
  • 当SYN队列满之后，后续服务器收到SYN包，不进入SYN队列
  • 计算出一个cookie值，再以SYN+ACK中的序列号返回客户端
  • 服务端接收到客户端的应答报文时，服务器会检查这个ACK包的合法性，如果合法直接放入到Accept队列
  • 最后应用通过调用accept（） socket接口，从Accept队列取出的连接
avatar
文章
阅读
粉丝