0


从后端角度看安全

跨站脚本攻击(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)publicResponseEntity<Resource>download(@RequestParam(value ="url")String url)throwsIOException{String fileName = url.substring(url.lastIndexOf("/")+1);byte[] bytes =IOUtils.toByteArray(newURL(url));ByteArrayResource resource =newByteArrayResource(bytes);HttpHeaders headers =newHttpHeaders();
        headers.add("Content-Disposition",String.format("attachment;filename=\"%s", fileName));returnResponseEntity.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解析,那就说明这个这个脚本不会运行,所以就不算漏洞!!

预防

  1. 文件上传的目录设置为不可执行 在实际业务中文件都放到了独立的存储系统中如OSS,一方面降低的系统的性能的损耗,也杜绝的执行漏洞
  2. 判断文件类型,结合MIME Type和文件后缀等,简单的通过后缀名称来判断文件的类型,是不安全的,
  3. 上传后修改文件名称和路径 文件上传后,黑客想要执行它,就要先能访问到它,这样可以增加攻击成本
  4. 单独设置文件服务器域名 因为同源策略,会导致大部分攻击失效,同源策略(协议相同,端口号相同,域名相同)是指未经允许的情况下,不能够访问其他域下的内容,如果没有同源限制,那么浏览器中的cookie等其他数据可以任意读取,不同域下的DOM任意操作,ajax任意请求其他网站的数据

拒绝服务

分布式拒绝服务

什么是分布式拒绝服务

分布式拒绝服务也就是 大家所熟知的DDOS (Distributed Denial of Service),利用合理的请求,来造成服务过载从而导致服务不可用!

DDOS分为 网络层和应用层

预防

这里的预防是预防应用层的DDOS

  • 使用钞能力,与运营商合作
  • 限制请求频率
  • 修改配置 例如nginx 限制每秒请求数等
  • 性能优化 - 将数据库压力转移到内存中,及时的释放资源- 负载均衡- CDN
  • 验证码 虽然验证码,很影响体验,不过能有效的解决自动重放行为

正则攻击

MD正则写的不好,也会造成资源耗尽,从而拒绝服务。
正则的原理是基于NFA,就是个状态机,有缺陷的正则会消化大量的资源。

我是谁:没有绝对安全的系统

参考:
白帽子讲WEB安全

标签: 安全

本文转载自: https://blog.csdn.net/qq_40495860/article/details/127639659
版权归原作者 TheBlindM 所有, 如有侵权,请联系我们删除。

“从后端角度看安全”的评论:

还没有评论