可怕的互联网攻击

在未知的地方，也许有一只眼睛正盯着我们

Posted by cuihongpeng on March 4, 2017

让人又爱又恨的互联网

互联网在极大提高人类获取与处理信息能力的同时，同时也生存在严峻的环境下，因为互联网攻击从未停止过。

在线上和线下之间的界限越来越模糊的今天，我们的人生和财产安全随时随地都可能受到伤害。

大家都听过的惨案

  1. CSDN被“脱裤”，造成600余万注册用户信息被泄露，让曾经风头正盛的CSDN一蹶不振。

  2. 网易邮箱数据失窃，当时大家打招呼的方式都变成了你的iphone被锁了吗？

  3. 著名社区草榴遭攻击，有网友戏称“CSDN脱裤我可以当作没看见，小米脱裤我也无所谓，10086泄密我都不怕，这次我真的怕了……”。

  4. 我们也被攻击过（验证码，requestsmscode接口），虽然不严重，但是可以知道的是随着我们的崛起，被盯上是早晚的事。

常见的互联网攻击方式

网络攻击方式无数，黑客大神们掌握的技能更是让人瞠目结舌，大家可以去乌云感受一下，什么是一切皆有可能，不过总是有那么几种常用的和大家一起分享一下。

一、DOS，DDOS

DOS（Denial of Service）拒绝服务攻击。
DDOS（Distributed Denial of Service）是分布式拒绝服务攻击。

DOS攻击的基本原理

设法使被攻击服务器充斥大量要求回复的信息，消耗网络带宽或系统资源导致网络或系统不胜负荷以至于瘫痪而停止提供正常的网络服务。

  • 最简单粗暴的就是海量请求，挺不住就死。
  • SYN洪水攻击，面向连接的TCP三次握手是SYN洪水攻击存在的基础。一台机器在网络中通讯时首先需要建立TCP握手，标准的TCP握手需要三次包交换来建立。服务器一旦接收到客户机的SYN包后必须回应一个SYN/ACK包，然后等待该客户机回应给它一个ACK包来确认，才真正建立连接。然而，如果只发送初始化的SYN包，而不发送确认服务器的ACK包会导致服务器一直等待ACK包。由于服务器在有限的时间内只能响应有限数量的连接，这就会导致服务器一直等待回应而无法响应其他机器进行的连接请求。

DOS和DDOS的区别是什么呢？

DOS是利用自己的计算机攻击目标，也是一对一的关系，俗话里的单挑，这种攻击方式很传统，在当下的环境下不太适用，因为随着带宽，系统资源的极大提升，如果不计代价的攻击，很可能在把对手拖死之前，自己的机器先废掉了。

当然，正所谓道高一尺魔高一丈，DOS不好使了，坏人们就得研究点新办法，DDOS是DoS攻击基础之上产生的一种新的攻击方式,利用控制成百上千台肉鸡，组成一个DDOS攻击群，同一时刻对目标发起攻击。

如何识别DDOS攻击

以下是一些DDOS的特证，我们可以据此特征来抵抗DDOS（包括但不限于）：

  • 攻击经常来源于一些相对固定的IP或IP段，每个IP都有远大于真实用户的连接数和请求数。

  • 因为攻击是由木马发出且目的是使服务器超负荷，请求的频率会远远超过正常人的请求。

  • User-Agent通常是一个非标准的值

  • Referer有时是一个容易联想到攻击的值

如何应对DDOS攻击

目前看DOS和DDOS是无法被阻止的，但是可以预防和应对。

  • 限制请求速度，设置Nginx的连接请求在一个真实用户请求的合理范围内。比如，如果你觉得一个正常用户每两秒可以请求一次登录页面，你就可以设置Nginx每两秒钟接收一个客户端IP的请求（大约等同于每分钟30个请求）。

  • 限制连接数量，设置Nginx的连接数在一个真实用户请求的合理范围内。比如，你可以设置每个客户端IP连接数不可以超过10个。

  • 关闭慢连接，有一些DDOS攻击，比如Slowlris，是通过建立大量的连接并周期性的发送一些数据包保持会话来达到攻击目的，这种周期通常会低于正常的请求。这种情况我们可以通过关闭慢连接来抵御攻击。

  • 设置IP黑名单

  • 设置IP白名单

  • 使用缓存进行流量削峰

  • 屏蔽特定的请求

  • 限制到后端服务器的连接数，一个Nginx实例可以处理比后端服务器多的多的并发请求。当请求数大于后端的处理能力时，我们只处理能处理的。

二、xss（跨站脚本攻击）和 sql注入

什么是XSS？

恶意攻击者往Web页面里插入恶意代码，当用户浏览该页之时，嵌入其中Web里面的代码会被执行，从而达到恶意攻击用户的目的。

XSS的类型

XSS漏洞分为两种，一种是DOM Based XSS漏洞，另一种是Stored XSS漏洞。

理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script。

DOM Based XSS，这种XSS只影响当前页面的用户，但是如果被高手搞成传播性漏洞，危害性还是很强的。

比如

http://www.yunlaiwu.com/?abc=aa"}');alert(document.cookie);//

Stored XSS漏洞，存储型XSS，影响的人很多

这种漏洞一般通过form表单的提交，存在数据库里，每个打开相关页面的人都会触发相关代码。

如何应对XSS攻击

  • 完善的过滤体系，永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。

  • 确保输出到HTML页面的数据以HTML的方式被转义，对特殊的html进行编码处理。< 转成 &lt，> 转成 &gt，& 转成 &amp，” 转成 "，’ 转成 &#39

  • 对于重要的cookie要设置成HttpOnly

sql注入

sql注入和xss很像，都是利用用户输入进行攻击，不过sql注入针对的是数据库

一个简单地示例

select * from user where username = $username

用户输入

username ='test' or 1='1'

如果我们不对输入数据进行处理，那么执行的sql语句将是

select * from user where username = 'test' or 1='1'，大门就这么轻易的打开了。

危害性

sql注入攻击的危害性还是比较严重的，对于一个有经验的SQL注入攻击者，如果网站存在SQL注入的漏洞，攻击者利用一些恶意的字符串可以进行一些数据表的查询甚至更改和删除，也就是说，这个安全漏洞会把数据表及其结构显示在攻击者的面前，攻击者甚至可以利用一些手段来进行其他更严重的攻击等。

三、CSRF（Cross-site request forgery）跨站请求伪造

CSRF是一个已经有些过气的攻击方法，但是一旦和其他攻击方法进行组合，还是有威力的

CSRF的原理

攻击者盗用受害人的身份，以受害人的名义发送恶意请求

用一个例子来解释CSRF能干什么

有这样一个场景，用户A登录了一个银行B，然后他在一个兴趣群里随手打开了一个网址，几天后A重新登上自己网上银行B，突然发现自己的银行账户少了好多钱。

一般来说，这是遭遇了CSRF攻击。

发生了什么？

假设（实际上没有那么傻）银行网站B，它以GET请求来完成银行转账的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

而银行网站B的身份认证是通过cookie来完成的。

危险网站B，它里面有一段HTML的代码如下：

<img src="http://www.mybank.com/Transfer.php?toBankId=11&money=1000">

悲哀的是此时我们本地关于银行B的cookie还没有过期，这个请求是被准确的。

ok，用户A向银行B报告了这件事，经过前面惨痛的教训，银行B决定转账请求必须只支持post请求，get见鬼去吧，哈哈。

结果呢？坏人C嘿嘿一笑，把网站代码简单改了一下。

<html>
    <head>
    	<script type="text/javascript">
    		function steal() {
    			iframe = document.frames["steal"];
    			iframe.document.Submit("transfer");
    		}
    	</script>
　　</head>
　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

又是一千块钱就这么没了，欲哭无泪啊！

CSRF的充分必要条件

那么这是怎么回事呢？我们来复盘一下用户A做了什么。

  • 登录受信任网站A，并在本地生成Cookie。

  • 在不登出A的情况下，访问危险网站B。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

  • 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

  • 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。

如何应对CSRF呢？

增加更加严格的验证方法比如判断refer，增加伪随机数等方法。

我觉得更加简单残暴有效的方法就是强校验，比如银行常用的（U盾，电子token等等），并且所有支付都需要密码