标签：信息   底部   安全   red   字节   ref   解释   ken   域名   

XSS：跨站脚本攻击

-典型实例为：

当用户在表达输入一段数据后，提交给服务端进行持久化。如果此用户输入的是一段脚本语言，而服务端

用户输入的数据没有经过转码、校验等就存入了数据库，在其他页面需要展示此数据时，就会执行此用户输入的语言。简单来说，JS的强大不用我来解释吧

-推荐防御措施：

对用户输入的信息进行转义，例如<>‘等等特殊字符。当然，其实很多前端框架也支持这么做，快查一查你使用的框架支持么。

CRSF：跨站请求伪造

-典型实例为：

如果A银行存在CRSF漏洞，有用户在登陆完A银行后没有退出，A银行的cookie信息保存在浏览器。然后呢，用户不小心进入了恶意网站，

此网站识别出了用户客户端存在A银行的信息，那么恶意网站就可以根据此cookie去请求A银行的转账接口，那么A银行会误认为是用户进行操作从而使恶意网站得逞。

-推荐防御措施：

假如我们的网站是A银行，为了防止用户信息泄露，我们应该做这三件事：

1. 将cookie设置为HttpOnly，让恶意网站无法通过脚本获取到cookie
2. 所有增删改以及需要验证权限的请求都应该携带token
3. Http头中有一个Referer属性，此属性表示请求Url地址，验证每一个请求的Referer是不是由自己系统发起的

SQL注入

-典型实例为：

用户输入的信息带有 delete 、drop等危害性十足的sql，就像用户登录时输入了用户名 “aaa;drop table user”,那么在我们没有任何防御措施的情况下就会变为“select * from user where username=‘aaa‘;drop table user”。然后呢，表就没了，你说尴不尴尬？

-推荐防御措施：

1. 使用原生jdbc时要使用PreparedStatement 而不要使用Statement，
2. 使用orm框架，像MyBatis、Hibernate等框架都对sql注入进行了很好的预防
3. 密码任何时候都不要使用明文存放，避免攻击者直接获取用户信息
4. 后台发生错误时不要直接返回异常信息，避免对服务器信息的泄露。建议对异常进行封装，返回可控的异常信息。

文件上传漏洞

-典型实例为：

没有对用户上传的文件做校验，恶意用户长时间上传超大文件占用系统资源，上传可执行脚本获取获取服务器信息

-推荐防御措施：

1. 对用户上传做限流，每个用户每天最多上传多少内容。
2. 对文件类型进行判断，不能通过后缀名判断，而要通过判断魔数（文件起始的几个字节）来判断，很多文件类型的魔数是不变的。

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://zhixiang.org.cn/#/blog/read/132e85fd-c3bf-4e78-acfd-0c73523f95a3,转载请保留。

常见的web攻击手段

标签：信息   底部   安全   red   字节   ref   解释   ken   域名   

原文地址：https://www.cnblogs.com/zhixiang-org-cn/p/9270831.html