这是我参加青训营的第六天。
Web安全主要有如下几大分类
- XSS
- CSRF(跨站请求伪造)
- SQL注入
- 命令行注入
- DDos注入
- 流量劫持
攻击
跨站脚本攻击(XSS)
xss主要攻击方式是想方设法的把恶意的脚本语言放进我们的页面中
-
主要利用的是我们盲目的新人用户提交的内容
-
二是我们直接把字符串读出来生成dom结构
特点
- 通常很难从UI上感知（暗地执行脚本）
- 窃取用户信息（cookie/token）
- 绘制UI（例如弹窗），诱骗用户点击/填写表单
存储型XSS （Stored XSS）
- 恶意脚本被存在数据库中
- 访问页面-> 读取数据 == 被攻击
- 危害最大，对全部用户可见
反射型XSS（Reflected XSS）
攻击者通过给别人发送带有恶意脚本代码参数的URL，当URL地址被打开时，特有的恶意代码参数被HTML解析、执行，从而达到攻击目的（获取用户信息，侵犯隐私）
- 不涉及数据库
- 从URL上攻击
基于DOM的XSS攻击方式(DOM-based XSS)
大部分浏览器都专门针对XSS进行转义处理，但也有很多方式可以绕过转义规则，比如web页面字符集不固定，用户输入非字符集字符，有时会绕过转义过滤规则。
- 不需要服务器的参与
- 恶意攻击的发起+执行，全在浏览器完成
跨站伪造请求(CSRF)
用户登录了某网站A，并在本地记录了cookie,在没有退出该网站时（cookie有效的时间内），攻击者发送引诱网站B，B要求访问A，从而达到获取用户隐私。
- 在用户不知情的前提下
- 利用用户权限
- 构造指定HTTP请求，窃取或修改用户敏感信息
构造get请求（CSRF-GET）
<img src=http://xxxxxxxxxx />
在访问含有这个img的页面后，成功向http://xxxxxxxxxx 发出了一次HTTP请求。所以，如果将该网址替换为存在GET型CSRF的地址，就能完成攻击了。
构造post请求（CSRF-beyond GET）
<form action = "https://xxxxxxxxxxxxxx" method="POST">
<input name="amount" value="10000000000" type="hidden">
<input name="to" value="hacker" type="hidden">
</form>
攻击者可以伪造form表单发送post请求，从post发送任何自己想要发送的数据
SQL注入
程序没有有效的转义过滤用户的输入，使得攻击者成功向服务器提交恶意的SQL查询代码，使得程序将攻击者的输入作为查询语句一部分执行。
服务拒绝(DDOs攻击)
短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。
- 直接访问IP
- 任意API
- 消耗大量带宽（耗尽）
插播：正则表达式 -- 贪婪模式
贪婪模式就是在重复匹配时会不会用到问号，有问号就是匹配一个就行，没有问号就是全部匹配 [?] vs [no?] : 满足“一个”即可 vs 尽量多
基于正则的DoS ReDoS
贪婪：n次不行？ n-1次再试试？ 回溯
Distributed DDoS
短时间内，来自大量的将是设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应心情求
中间人攻击
中间人攻击，顾名思义就是攻击者在客户端和服务端担当了第三者的角色，服务端以为自己在和客户端沟通，其实是蒙着脸的中间人，客户端以为自己发请求返回的是服务端，其实也是中间人。
- 信息明文传输
- 信息篡改不可知
- 对方身份未验证
防御
跨站脚本攻击(XSS)
xss的防御方法核心理念就是永远不信任用户提交的内容
存储型XSS （Stored XSS）
- 后端入库前不要相信前端任何数据，统一将所有字符转义
- 后端将数据输出给前段时统一进行转义
- 前端进行渲染时，将从后端请求过来的数据统一转义处理
反射型XSS（Reflected XSS）
-
Web页面渲染所有内容或渲染的数据必须来源于服务器
-
不要从 URL,document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染
-
尽量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()window.setTimeout()，innerHTML，document.creteElement() 等可执行字符串的方法
基于DOM的XSS攻击方式(DOM-based XSS)
- 指定 ，用utf-8，而且标签闭合
跨站伪造请求(CSRF)
我们知道，CSRF是通过伪造请求，那么我们可以通过限制请求来进行防御，伪造请求就判定为异常来源
-
正确使用get(只用于查看，列举，展示等不需要改变资源属性的时候) post（用于form表单提交，改变一个资源的属性或做一些其他事情，如数据库增删改）和cookie
-
非GET请求中，为每个用户生产一个cookie token
-
POST请求的时候使用验证码
-
渲染表单的时候，为每个表单加一个 csrfToken，然后在后端做 csrfToken验证
-
校验请求来源
-
设置cookie samesite
SQL注入
-
严格限制web应用的数据库操作权限，给此用户提供仅仅能够满足其工作的最低权限
-
后端代码检查输入数据是否符合预期，严格限制变量的类型，比如使用正则表达式进行匹配
-
对进入数据库的特殊字符（’，"，，<，>，&，*）进行转义处理
-
应用上线前建议使用专业的SQL注入检测
