XSS: 跨站脚本攻击
- 典型实例为:
当用户在表达输入一段数据后, 提交给服务端进行持久化. 如果此用户输入的是一段脚本语言, 而服务端
用户输入的数据没有经过转码, 校验等就存入了数据库, 在其他页面需要展示此数据时, 就会执行此用户输入的语言. 简单来说, JS 的强大不用我来解释吧
- 推荐防御措施:
对用户输入的信息进行转义, 例如<>'等等特殊字符. 当然, 其实很多前端框架也支持这么做, 快查一查你使用的框架支持么.
CRSF: 跨站请求伪造
- 典型实例为:
如果 A 银行存在 CRSF 漏洞, 有用户在登陆完 A 银行后没有退出, A 银行的 cookie 信息保存在浏览器. 然后呢, 用户不小心进入了恶意网站,
此网站识别出了用户客户端存在 A 银行的信息, 那么恶意网站就可以根据此 cookie 去请求 A 银行的转账接口, 那么 A 银行会误认为是用户进行操作从而使恶意网站得逞.
- 推荐防御措施:
假如我们的网站是 A 银行, 为了防止用户信息泄露, 我们应该做这三件事:
将 cookie 设置为 HttpOnly, 让恶意网站无法通过脚本获取到 cookie
所有增删改以及需要验证权限的请求都应该携带 token
Http 头中有一个 Referer 属性, 此属性表示请求 Url 地址, 验证每一个请求的 Referer 是不是由自己系统发起的
SQL 注入
- 典型实例为:
用户输入的信息带有 delete ,drop 等危害性十足的 sql, 就像用户登录时输入了用户名 "aaa;drop table user", 那么在我们没有任何防御措施的情况下就会变为 "select * from user where username='aaa';drop table user". 然后呢, 表就没了, 你说尴不尴尬?
- 推荐防御措施:
使用原生 jdbc 时要使用 PreparedStatement 而不要使用 Statement,
使用 orm 框架, 像 MyBatis,Hibernate 等框架都对 sql 注入进行了很好的预防
密码任何时候都不要使用明文存放, 避免攻击者直接获取用户信息
后台发生错误时不要直接返回异常信息, 避免对服务器信息的泄露. 建议对异常进行封装, 返回可控的异常信息.
文件上传漏洞
- 典型实例为:
没有对用户上传的文件做校验, 恶意用户长时间上传超大文件占用系统资源, 上传可执行脚本获取获取服务器信息
- 推荐防御措施:
对用户上传做限流, 每个用户每天最多上传多少内容.
对文件类型进行判断, 不能通过后缀名判断, 而要通过判断魔数 (文件起始的几个字节) 来判断, 很多文件类型的魔数是不变的.
DDOS: 分布式拒绝服务攻击
- 典型实例为:
1. 攻击者提前控制大量计算机, 并在某一时刻指挥大量计算机同时对某一服务器进行访问来达到瘫痪主机的目的.
2. 相信大家都知道 TCP 三次握手的机制,(如不了解请参考文章底部补充)攻击者利用此机制对服务器返回的 ACK 确认包不回应, 这样服务器就会存在大量的等待列表, 不断重试, 等待队列满了以后不再接受 TCP 连接, 从而阻挡了正常用户的使用
3. 攻击者向 DNS 服务器发送海量的域名解析请求, DNS 首先查缓存, 如果缓存不存在的话会去递归调用上级服务器查询, 直到查询到全球 13 台根服务器为止, 当解析请求过多时正常用户访问就会出现 DNS 解析超时问题
- 推荐防御措施:
使用缓存, 当缓存中存在时就直接取出, 不要频繁的连接数据库.
缩短 SYN Timeout 时间, 即缩短从接受到 SYN 报文到确定这个报文无效并丢弃该连接的时间.
限制源 ip 每秒发起的 DNS 请求等
补充: TCP 三次握手机制
首先, 请求端 (客户端) 发送一个包含 SYN 标志的 TCP 报文, SYN 即同步(Synchronize), 同步报文会指明客户端使用的端口以及 TCP 连接的初始序号;
第二步, 服务器在收到客户端的 SYN 报文, 将返回一个 SYN+ACK 的报文, 表示客户端的请求被接受, 同时 TCP 序号被加一, ACK 即确认(Acknowledgment).
第三步, 客户端也返回一个确认报文 ACK 给服务器端, 同样 TCP 序列号被加一, 到此一个 TCP 连接完成.
结语
写这篇文章的目的呢, 其实不是说让大家通过这篇文章成为一个安全高手或者怎么的, 只是想让大家了解一下这些常见的攻击手段. 当你知道了这些攻击手段后看一下你手中的项目是否需要预防一下, 毕竟未雨绸缪总是比临阵磨枪好的多, 不是吗?
来源: https://www.cnblogs.com/zhixiang-org-cn/p/9270831.html