WEB安全 ｜ 青训营笔记

给我一杯泰绿魔法药水
195 阅读7分钟

这是我参与「第四届青训营 」笔记创作活动的第6天

攻击

XSS（cross-site script）跨站脚本攻击

攻击者将恶意脚本注入

XSS=开发者盲户信任用户提交的内容+用户输入的字符串string转化为Dom

//例如以下API
document.write
element.innerHTML=anyString;
SSR(user_data)//伪代码

特点

  • 通常难以从UI上感知(暗地执行脚本)

  • 窃取用户信息(cookie/token)

  • 绘制UI(例如弹窗),诱骗用户点击/填写表单

举个例子

提交和读取操作没有对用户提交的内容进行过滤，导致用户可以输入时提交恶意脚本

image.png

Stored XSS

恶意脚本被存在数据库中

访问页面→读数据===被攻击

危害最大,对全部用户可见

reflected xss

  • 不涉及数据库

  • 从URL上攻击

host/path/?param=<script>alert('123')</script>

image.png

Dom-based xss

  • 不需要服务器的参与

  • 恶意攻击的发起+执行,全在浏览器完成

reflected xss VS dom-based xss攻击

image.png

Mutation-based xss

  • 利用了浏览器宣染DOM的特性(独特优化)

  • 不同浏览器,会有区别(按浏览器进行攻击)

  • 最难防御

cross-site requeset forgery（CSRF）

  • 在用户不知情的前提下

  • 利用用户权限(cookie)

  • 构造指定HTTP请求,窃取或修改用户敏感信息

image.png

csrf-get

get请求

//链接
<a href="https://bank.com/transfer?to=hacker&amount=10e">点我抽奖</a><!--确实中奖了-->

 //图片一加载酒完成一次csrf请求
 <img style="display:none;" src="https://bank.com/transfer?toshacker&amount=100”/>

csrf-beyond get

 //伪造表单
 <form action="https://bank/transfer_tons_of_money" method="POST"> <input name="amount" value="1000000000000" type="hidden"
 <input name="to" value="hacker" type="hidden"
 </form>

Injection

SQL Injection

流程：一个http请求，是恶意注入的sql参数，服务器得到sql请求，得到一个sql语句，代码被执行恶意注入后，导致攻击者可以恶意注入篡改数据

image.png

image.png

①读取请求字段

②直接以字符串的形式拼接SQL 语句

image.png

  • CLI

  • OS command

  • Server-Side Request Forgery(SSRF),服务端伪造请求

  • 严格而言, SSRF 不是injection,但是原理类似

通过执行命令，暴露重要文件（流程）

  • 流量转发到真实第三方
  • 第三方打不住新增流量
  • 第三方服务挂掉
  • 您的竞争对手已下线

SSRF

  • 请求【用户自定义】 的callback URL
  • web server 通常有内网访问权限

Denial of Service(Dos)

通过某种方式(构造特定请求),导致服务器资源被显著消耗,来不及响应更多请求,导致请求挤压,进而雪崩效应。

重复匹配时「?」vs 「no?」:满足“一个“即可vs尽量多

const greedyRegExp = /a+/; 有多少匹配多少 //贪婪模式 const nonGreedyRegExp = /a+?/; 有一个就行 const str = "aaaaaa"; console.log(str.match(greedyRegExp)[0]); // "aaaaaa " console. log(str.match(nonGreedyRegExp) [0]); // "a"

ReDoS:基于正则表达式的Dos

贪婪匹配ab 重复模式

贪婪：n次不行？ n-1次试试——回溯

image.png

导致结果：响应时间增加 接口吞吐量下降

DDOS

短时间内,来自大量僵尸设备的请求流量,服务器不能及时完成全部请求,导致请求堆积,进而雪崩效应,无法响应新请求。

特点

  • 直接访问IP

  • 任意API

  • 消耗大量带宽(耗尽)

洪泛攻击

SYN Flood（半开放攻击）是一种拒绝服务（DDoS）攻击，其目的是通过消耗所有可用的服务器资源使服务器不可用于合法流量。通过重复发送初始连接请求（SYN）数据包，攻击者能够压倒目标服务器机器上的所有可用端口，导致目标设备根本不响应合法流量。

三次握手没有完成 链接数不能被释放 服务器达到最大链接次数，新请求不能被响应——完成一次洪水攻击

传输层

中间人攻击

中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）是指攻击者与通讯的两端（浏览器和服务器中间）分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。中间人攻击是一个（缺乏）相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。

利用以下三点

①明文传输

②信息算改不可知

③对方身份未验证

防御

xss

  • 永远不信任用户的提交内容

  • 不要将用户提交内容直接转换成DOM

  • 应该当成string字符串

现成工具

前端

  • 主流框架默认防御XSS

  • google-closure-library

服务端(Node)

  • DOMPurify

注意

  • string生成dom

     new DOMParser();
 //需要注意对string进行转译

  • 上传svg

    • 因为svg之中可以插入script标签，所以需要对svg文件进行扫描

  • 尽量不要做自定义跳转链接

  • 注意用户自定义样式

    • 可能会被指定get请求 注意设置背景图片等地方留意

same-origin policy 同源策略

同源：两个url上协议、域名、端口号完全相等称为同源

对于http请求，同源策略是没问题的，跨域请求是不可行的（查看服务器配置）

//服务器的响应头部 
Content-Security-Policy: script-src 'self 同源
 //脚本必须是同源的，非同源就不允许执行
 Content-Security-Policy: script-src 'self' https://domain.com

content security policy (csp-内容安全策略)

  • 哪些源(域名)被认为是安全的
  • 来自安全源的脚本可以执行,否则直接抛错
  • 对eval + inline script 直接拒绝
 <meta http-equiv="Content-Security-Policy" content="script-src self">
//从域名的角度

csrf的防御

if 伪造请求===异常来源

then限制请求来源 →限制伪造请求

  • 请求头部：

    • Origin

      • 同源请求中, GET + HEAD不发送origin字段
    • Referer（更广泛）

  • token

    • if (请求来自合法页面)
    • then (服务器接收过页面请求)
    • then (服务器可以标识)

Csrf--iframe攻击

攻击者构造页面，有buttom标签，标签会构造一个iframe（合法页面），用户点击css后到iframe,iframe受到http请求，iframe是同源请求，对应的攻击完成。

利用iframe完成csrf攻击

措施：在服务器对x-fram-opitons:Deny/sameorigin进行头部设置，deny就是当前页面不能作为iframe加载，设定只有同源的页面可以加载，规避csrf

Csrf- anti-pattern

Get !==get+post

//将 更新+获取 還辑放到同一个 GET 接口
 public async getAndUpdate(ctx) {
 
 }
 const {update, id } = ctx.query;
 if (update) {await this.update(update);
 }
 ctx.body = await this.get(id);}
 //如果被csrf攻击，用户数据容易被篡改
 //避免把get和post一起写
 //get请求和post请求一定要区分开

samesite cookie

我页面的cookie只能本页面使用，限制cookie domain和页面域名

依赖Cookie的第三方服务怎么办?

 Set-Cookie: SameSite=None; Secure;
//要标注是secure确保安全

Samesite vs cors

SameSite

  • Cookie 发送
  • domain vs页面域名 （是否一致）
  • "我跟你说个事儿,出这屋我可就不认了" （是否是当前页面）

CORS

  • 资源读写(HTTP 请求)
  • 资源域名vs页面域名
  • 白名单

防御csrf

  • node

    • 生成中间件 防御csrf

Injection

  • 找到项目中查询SQL的地方

  • 使用 prepared statement（将sql语句提前编译）

     PREPARE q FROM 'SELECT user FROM users WHERE gender = ?'; SET @gender = 'female';
 EXECUTE q USING @gender;
 DEALLOCATE PREPARE q;
​

  • 最小权限原则

    • 所有命令都不给予sudo或者root权限

  • 建立允许名单+过滤

    • rm（不允许这种命令）

  • 对URL类型参数进行协议、域名、ip等限制

    • 避免访问内网

Regex Dos

  • 完善代码review 避免写出贪婪匹配
  • 代码扫描+正则性能测试
  • 不允许用户提供的使用正则

ddos

  • 流量治理

    • 负载均衡（*进行流量识别过滤）
    • API网关（*进行流量识别过滤）
    • CDN（抗量）

  • 快速自动扩容（抗量）

    • 流量激增有方案承载

  • 非核心服务降级（抗量）

    • 关闭服务保留计算资源

HTTPS的一些特性

  • 可靠性:加密（避免明文传输）
  • 完整性: MAC验证（防篡改）
  • 不可抵赖性:数字签名（确保双方身份）

Subresource integrity (SRI)

cdn托管的资源被劫持怎么办

SRI 解决->对比hash

Feature policy

一个页面下开发者可以使用哪些功能？

限制一些敏感的功能

如果通过iframe加载 有一个allow属性

avatar
文章
阅读
粉丝