聊聊Web安全：如何抵御常见的网络攻击？

Web安全是一个大课题，在网络安全事件中，针对Web的攻击是最多的。

从一些html标签，到JS代码安全问题，然后到接口、数据库，以及流量攻击、模拟请求、自动化攻击等等，很多很多。

本文简单的聊聊常见的网络攻击防御方式。

DDOS最常见，也是最难防御。目前还没有人敢说能彻底防御DDOS。

DDoS就是流量攻击。

由于DDoS攻击往往采取合法的数据请求技术，再加上傀儡机器，造成DDoS攻击成为最难防御的网络攻击之一。

1，对频繁请求的ip和接口进行限流，熔断处理，超过多少次必须输入图形验证码。

进行验证处理可，减轻服务器数据库处理压力。

其实现在很多大公司都是把一下接口放在一个项目里面进行rpc远程调用处理。通过分布式缓存，分布式一致性问题，分布式事务来解决这些问题。

2，使用黑名单和白名单机制，防御攻击（OAuth2.0协议）这个推荐使用。

这个黑名单白名单就是现在很多代理网站来给你处理网站的安全性，也算是给你防御网站吧。

3，选择高防数据中心：

国内数据中心一般都会有防火墙防御，我们今天把防火墙情况分为两种：

（1）集群防御，单线机房防御一般在：10G-32G的集群防御，BGP多线机房一般为：10G以内集群防火墙。

（2）独立防御，独立防御都是出现在单线机房，或者是多线多ip机房，机房防御能力一般为：10G-200G不等，这种机房是实现的单机防御能力，随着数据中心的防御能力提高还有就是竞争压力比较大，高防的价格也在不断的创造新低。

4、CDN内容分发：

通过CDN防御的方式：CDN技术的初衷是提高互联网用户对网站的访问速度，但是由于分布式多节点的特点，又能够对分布式拒绝攻击流量产生稀释的效果。所以目前CDN防御的方式不但能够起到防御的作用，而且用户的访问请求是到最近的缓存节点，所以也对加速起到了很好的作用。

CDN防御的最重要的原理：通过智能DNS的方式将来自不同位置的流量分配到对应的位置上的节点上，这样就让区域内的节点成为流量的接收中心，从而将流量稀释的效果，在流量被稀释到各个节点后，就可以在每个节点进行流量清洗。从而起到防御作用。

目前针对DDOS流量攻击的防护方法中CDN防御也分为自建CDN防御，这种情况防御能力较好，但是成本较高，需要部署多节点，租用各个节点服务器，如果应用较少的话，造成资源浪费。另外就是租用别人现成的CDN防御，可以极大的节省成本，并且防御能力很少非常好。

CSRF即：Cross Site Request Forgery（跨站域请求伪造）它在 2007 年曾被列为互联网 20 大安全隐患之一,也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用也就是人们所知道的钓鱼网站。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。

XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行，因此对其进行防范的资源也相当稀少，所以被认为比XSS更具危险性。

也就是通俗一点来说就是，大量请求你的接口，通过抓包工具请求分析，伪造token访问你的接口，攻击服务器降低服务器数据库性能。

模拟请求这里还是要说到分布式，毕竟真的要用到分布式，缓存集群。解决限流，服务容错，熔断的问题。

后端防御：

1、MVCC方案

多版本并发控制，该策略主要使用 update with condition（更新带条件来防止）来保证多次外部请求调用对系统的影响是一致的。在系统设计的过程中，合理的使用乐观锁，通过 version 或者 updateTime（timestamp）等其他条件，来做乐观锁的判断条件，这样保证更新操作即使在并发的情况下，也不会有太大的问题。

2、去重表

在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。

3、悲观锁

select for update，整个执行过程中锁定该订单对应的记录。注意：这种在 DB 读大于写的情况下尽量少用。

4、Token机制,防止页面重复提交

把token放在redis 里面通过限流方式，每个token只能使用一次，网络延迟或者重试机制解决这个问题。

5，MQ消息中间件也可以解决这个问题，可以通过发布订阅的方式来消息通知处理。

6，nginx服务器对域名网关拦截处理，只能通过域名访问，不能获取到你的ip，所以的前台文件通过分离来实现。

7，分布式校验

在大型网站中，使用Session存储CSRF Token会带来很大的压力。访问单台服务器session是同一个。但是现在的大型网站中，我们的服务器通常不止一台，可能是几十台甚至几百台之多，甚至多个机房都可能在不同的省份，用户发起的HTTP请求通常要经过像Ngnix之类的负载均衡器之后，再路由到具体的服务器上，由于Session默认存储在单机服务器内存中，因此在分布式环境下同一个用户发送的多次HTTP请求可能会先后落到不同的服务器上，导致后面发起的HTTP请求无法拿到之前的HTTP请求存储在服务器中的Session数据，从而使得Session机制在分布式环境下失效，因此在分布式集群中CSRF Token需要存储在Redis之类的公共存储空间。

由于使用Session存储，读取和验证CSRF Token会引起比较大的复杂度和性能问题，目前很多网站采用Encrypted Token Pattern方式。这种方法的Token是一个计算出来的结果，而非随机生成的字符串。这样在校验时无需再去读取存储的Token，只用再次计算一次即可。

这种Token的值通常是使用UserID、时间戳和随机数，通过加密的方法生成。这样既可以保证分布式服务的Token一致，又能保证Token不容易被破解。

在token解密成功之后，服务器可以访问解析值，Token中包含的UserID和时间戳将会被拿来被验证有效性，将UserID与当前登录的UserID进行比较，并将时间戳与当前时间进行比较。

前台防御：

1.CSRF监控

对于一个比较复杂的网站系统，某些项目、页面、接口漏掉了CSRF防护措施是很可能的。

一旦发生了CSRF攻击，我们如何及时的发现这些攻击呢？（这里其实nginx也可以处理）

CSRF攻击有着比较明显的特征：

• 跨域请求。
• GET类型请求Header的MIME类型大概率为图片，而实际返回Header的MIME类型为Text、JSON、HTML。

2，通过对称非对称算法，前台网站访问先访问后台获取到应签，然后在把前台请求的参数拿到后台去检验。一般网络上面接口支付都是重定向啦。这样一般都比较麻烦。但是这样安全性能很高的，其实ssl证书比域名都贵滴。

3，用双重Cookie防御CSRF的

优点：

• 无需使用Session，适用面更广，易于实施。
• Token储存于客户端中，不会给服务器带来压力。
• 相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。

缺点：

• Cookie中增加了额外的字段。
• 如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
• 难以做到子域名的隔离。
• 为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

SQL注入：利用现有应用程序，将恶意的SQL命令注入到后台数据库执行一些恶意的操作。造成SQL注入的原因是因为程序没有有效过滤用户的输入，使攻击者成功的向服务器提交恶意的SQL查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。

SQL注入漏洞可能会影响使用SQL数据库（如MySQL，Oracle，SQL Server或其他）的任何网站或Web应用程序。犯罪分子可能会利用它来未经授权访问用户的敏感数据：客户信息，个人数据，商业机密，知识产权等。SQL注入攻击是最古老，最流行，最危险的Web应用程序漏洞之一。

SQL注入攻击的类型

SQL注入攻击可以通过多种方式执行。在选择特定攻击方法之前，攻击者可能会观察系统的行为。

带内注入

这是典型的攻击，攻击者可以通过相同的通信通道发起攻击并获得结果。这是通过两种带内技术完成的：

●　基于错误的SQL注入：从显示的错误消息中获取有关数据库的信息

●　基于联合的SQL注入：依赖于攻击者能够将UNION ALL被盗信息的结果与合法结果连接起来。

这两种技术都依赖于攻击者修改应用程序发送的SQL，以及浏览器中显示的错误和返回的信息。如果应用程序开发人员或数据库开发人员无法正确地参数化他们在查询中使用的值，那么它会成功。两者都是试错法，可以检测到错误。

盲注入

也称为推理SQL注入，盲注入攻击不会直接从目标数据库中显示数据；相反，攻击者会仔细检查行为中的间接线索。HTTP响应中的详细信息，某些用户输入的空白网页以及数据库响应某些用户输入需要多长时间，这些都可以是线索，具体取决于攻击者的目标。他们还可以指向攻击者尝试的另一个SQLi攻击途径。

带外注入

这种攻击有点复杂，当攻击者无法在单个直接查询 - 响应攻击中实现其目标时，攻击者可能会使用此攻击。通常，攻击者会制作SQL语句，这些语句在呈现给数据库时会触发数据库系统创建与攻击者控制的外部服务器的连接。以这种方式，攻击者可以收集数据或可能控制数据库的行为。

二阶注入就是一种带外注入攻击。在这种情况下，攻击者将提供SQL注入，该注入将由数据库系统的单独行为存储和执行。当二级系统行为发生时（它可能类似于基于时间的作业或由其他典型管理员或用户使用数据库触发的某些事情）并且执行攻击者的SQL注入，那就是当“伸出”到系统时攻击者控制发生了。

1、规范sql 写的方式不要写拼接sql,、最好使用预编译方式

在mybatis编写sql语句的时候，最好使用?传参数方式，不要使用#传参数，因为#传参数方式，可能会受到sql语句攻击。

#{}: 解析为一个 JDBC 预编译语句（prepared statement）的参数标记符，一个 #{ } 被解析为一个参数占位符,可以防止SQL注入问题。

${}: 仅仅为一个纯碎的 string 替换，在动态 SQL 解析阶段将会进行变量替换。

2、限制数据库权限和特权

将数据库用户的功能设置为最低要求；这将限制攻击者在设法获取访问权限时可以执行的操作。

避免直接向用户显示数据库错误

攻击者可以使用这些错误消息来获取有关数据库的信息。

对访问数据库的Web应用程序使用Web应用程序防火墙（WAF），其实，不止是SQL注入，本文所讲的这些攻击，几乎全都可以用WAF进行防护。WAF有多种，比如硬件、软件、云，有很贵的商业WAF硬件，也有免费+商业的WAF软件（比如：ShareWAF，很不错。）。

这为面向Web的应用程序提供了保护，它可以帮助识别SQL注入尝试；根据设置，它还可以帮助防止SQL注入尝试到达应用程序（以及数据库）。

3、定期测试与数据库交互的Web应用程序

这样做可以帮助捕获可能允许SQL注入的新错误或回归。

将数据库更新为最新的可用修补程序

这可以防止攻击者利用旧版本中存在的已知弱点/错误。

4.后台日志分析sql 可以使用AOP拦截写入sql性能

防盗链就是A网站有一张图片，B网站要引用过来使用到自己网站，引用图片和样式，js等等。

如何防御？

1，写一个过滤器判断http请求头Referer域中的记录来源的值，如果和当前访问的域名不一致的情况下，说明该图片可能被其他服务器盗用。

2，通过动静分离或者前后端分离。通过nginx配置。

3，可以通过shiro权限判断链接重定向。

Xss就是javascript 脚本攻击，就是在表单提交的时候提交一个小脚本，因为浏览器默认是支持脚本的，所以写个小脚本不做处理的话问题就很大。不处理网页直接挂掉。

如何防御？

1，通过后台编写一个过滤器拦截所有getParameter参数 重写httpservletwrapp方法。

2，通过工具类将参数特殊字符转换成html源代码保存。

3，通过js检验

过滤用户输入的 检查用户输入的内容中是否有非法内容。如<>（尖括号）、”（引号）、 ‘（单引号）、%（百分比符号）、;（分号）、()（括号）、&（& 符号）、+（加号）等。、严格控制输出

什么是文件上传漏洞？

上传漏洞这个顾名思义，就是攻击者通过上传木马文件，直接得到WEBSHELL，危害等级超级高，现在的入侵中上传漏洞也是常见的漏洞。 导致该漏洞的原因在于代码作者没有对访客提交的数据进行检验或者过滤不严，可以直接提交修改过的数据绕过扩展名的检验。

大家经常在网上下载文件什么东西，比如一个软件，默认几十M但是下下来为啥只有几百Kb很多网站都是钓鱼网站，你下载下来的文件是后缀为.exe文件，这是系统运行文件，文件下载也有这个问题，所以网上很多不靠谱滴，不要乱下载文件。

如何解决防御？

1 对文件格式限制，只允许某些格式上传

2 对文件格式进行校验，前端跟服务器都要进行校验（前端校验扩展名，服务器校验扩展名、Content_Type等）

3 将上传目录防止到项目工程目录之外，当做静态资源文件路径，并且对文件的权限进行设定，禁止文件下的执行权限。

4 通过文件流解析判断文件类型。

我在这里分析一个常见的qq漏洞，现在很多都还有人家盗用别人密码，然后通过qq发送消息，找你借钱或者转账到某个地方，黑客就是通过 抓包分析暴力破解密码（写一个程序破解验证码，如果是4位纯数字可想而知），然后盗取你的短信验证码登录，如果发生了这样的情况，如果是qq的话你就一直发短信验证码，联系客户还得一段时间。因为大家都知道qq验证码都是4位所以别人很好破解，我这里说的都是真实案例，因为我以前也被别人这样操作过，但是我就一直频繁发短信验证码后面就找回来啦。

如何防御：

1，忘记密码验证码最好在6-8位 最好是加字符，字母组合。

2 一旦频繁调用接口验证时，应该使用图形验证码拦截，防止机器模拟。

3，使用黑名单和白名单机制，防御攻击（OAuth2.0协议）。
【来源：今日头条】