从后端角度看安全
跨站脚本攻击（XSS）
什么是XSS
跨站脚本工具，全程是Cross Site Script，为了和CSS 区分，所以叫XSS。
XSS 攻击，通常指黑客通过HTML注入，来纂改了网页，插入恶意脚本。
人话就是把用户的数据当成了html代码的一部分来运行了
在线练习
反射型XSS
反射型XSS又称非持久型XSS，只是简单把用户输入的数据反射给浏览器
存储型XSS
存储型XSS又称持久型XSS
为什么注入了就能运行
url?name=<script>alert(1)</script>
<h2 align="center">欢迎用户:{{name}}</h2>
在jsp或者asp这类后端渲染的会出现xss
因为 后端会把值直接渲染，返回给浏览器
<h2 align="center">欢迎用户:<script>alert(1)</script></h2>
为什么现在vue或者现代化的前端框架中xss会很困难？
<h2 align="center">欢迎用户:{{name}}</h2>
在vue中插值相当于v-text也就是js中的outerText，只会当成文本处理
危害
你就 想象一下你的网站，别人在里面添加js代码，是不是内裤都给看穿了
- 代理转发流经被攻击者的所有 Web 流量，即实施中间人攻击。
- 窃取或篡改应用 cookie 用于会话劫持。
- 钓鱼
危害很多只简单列几个
防御
1.输入检查
过滤<>等特殊字符，但是可能会改变程序的语义。
2.输出检查
使用安全的编码函数
html ->HemlEncode
javascript ->JavascriptEncode
3.使用现代化的前端框架
4.设置Http only
这样通过js脚本将无法读取到cookie信息，这样能有效的防止关于会话的XSS攻击。
CSRF
跨站点请求伪造（Cross Site Request Forgery）
什么是CSRF
我现在写了一个页面，页面里的逻辑是 请求B站注销账户，然后我把链接发给了你，你点开后，如果你最近登录了B站，那么你的账号就被注销了，这就是跨站点请求伪造
危害
CSRF一般都是产生写数据操作的url，因为CSRF过程中，攻击者是无法获得返回的数据的，所以读的操作对他没有意义。
危害显而易见，直接内库被看穿！
顺便说一下SSRF
预防
- token
因为token 不会被自动提交，前端在登录成功后在本地缓存token，然后在请求时在请求头中带上token，
所以CSRF时并不会自动带上token
SSRF
服务端请求伪造（Server Site Request Forgery）
什么是SSRF
当我们服务端提供了从其它服务器应用获取数据的时候，坏银恶意使用该接口来代理攻击
危害
坏银使用恶意的url来访问本来访问不到的内网服务
例如:
公司的一个老接口，现在已被弃用！
@ApiOperation(value = "图片-下载代理，解决跨越问题")
@RequestMapping(path = "/download", method = RequestMethod.GET)
public ResponseEntity<Resource> download(@RequestParam(value = "url") String url) throws IOException {
String fileName = url.substring(url.lastIndexOf("/") + 1);
byte[] bytes = IOUtils.toByteArray(new URL(url));
ByteArrayResource resource = new ByteArrayResource(bytes);
HttpHeaders headers = new HttpHeaders();
headers.add("Content-Disposition", String.format("attachment;filename=\"%s", fileName));
return ResponseEntity.ok()
.headers(headers)
.contentLength(bytes.length)
.contentType(MediaType.APPLICATION_OCTET_STREAM)
.body(resource);
}
当我本地启动了一个服务时，使用postman请求
直接内裤被打穿！！
预防
- 内网开启鉴权
- 过滤内网服务ip
- 只允许http和https协议访问
SQL注入
对于后端来说SQL 注入可以说非常熟悉了。
盲注
服务端关闭异常显示，攻击者通过注入条件语句来验证是否存在sql注入漏洞
荔枝：
http://path.com/item?id=1
后端sql： select * from user where id= 1
注入：
http://path.com/item?id=1 and 1=1
http://path.com/item?id=1 and 1=2
通过验证上述sql注入返回结果，来判断是否存在sql注入
（定时攻击）Timing Attack
有时 id 是比较复杂的如uuid，这时你就不能通过上面的梨子来盲注了
在mysql 中 BENCHMARK(count,expr) 用来测试函数执行count次，来查看耗时
因此 通过注入BENCHMARK来判断耗时是否有增加来判断是否存在SQL注入
预防
1.预编译
2.存储过程
存储过程中尽量不要使用动态SQL
3.检查数据类型
在使用数据库时应该严格 遵守最小权限原则。
XML注入
与HTML注入相似，解决方案也是类似，对用户输入中的保留字符进行转义即可
文件上传漏洞
什么是文件上传漏洞
文件上传漏洞是指用户上传了一个可执行的脚本文件。
触发条件：
- 上传的文件能被web容器解析
- 用户能访问到该文件
如果文件上传了，不能被用户访问到或者不能被web解析，那就说明这个这个脚本不会运行，所以就不算漏洞！！
预防
-
文件上传的目录设置为不可执行
在实际业务中文件都放到了独立的存储系统中如OSS，一方面降低的系统的性能的损耗，也杜绝的执行漏洞 -
判断文件类型，结合MIME Type和文件后缀等，简单的通过后缀名称来判断文件的类型，是不安全的，
-
上传后修改文件名称和路径
文件上传后，黑客想要执行它，就要先能访问到它，这样可以增加攻击成本 -
单独设置文件服务器域名
因为同源策略，会导致大部分攻击失效，同源策略（协议相同，端口号相同，域名相同）是指未经允许的情况下，不能够访问其他域下的内容，如果没有同源限制，那么浏览器中的cookie等其他数据可以任意读取，不同域下的DOM任意操作，ajax任意请求其他网站的数据
拒绝服务
分布式拒绝服务
什么是分布式拒绝服务
分布式拒绝服务也就是 大家所熟知的DDOS (Distributed Denial of Service)，利用合理的请求，来造成服务过载从而导致服务不可用！
DDOS分为 网络层和应用层
预防
这里的预防是预防应用层的DDOS
- 使用钞能力，与运营商合作
- 限制请求频率
- 修改配置
例如nginx 限制每秒请求数等 - 性能优化
- 将数据库压力转移到内存中，及时的释放资源
- 负载均衡
- CDN
- 验证码
虽然验证码，很影响体验，不过能有效的解决自动重放行为
正则攻击
MD正则写的不好，也会造成资源耗尽，从而拒绝服务。
正则的原理是基于NFA，就是个状态机，有缺陷的正则会消化大量的资源。
我是谁：没有绝对安全的系统
参考：
白帽子讲WEB安全