常见网络攻击

中间人攻击(Man-in-the-Middle (MITM) attack)

中间人攻击是一种常见的攻击手段，攻击者与通讯双方分别创建链接，将双方想要交换的数据进行记录、篡改甚至丢弃。因为Http是明文传输，所以很容易遭受到中间人攻击。

一个通俗的例子

• 假设 Tom 想和 Jerry 交换一些秘密信息，然而 Tom 又不想跑到 Jerry 家里，因而 Tom 叫来了邮递员，给了邮递员一封信。信的内容是但愿 Jerry 给 Tom 一个盒子（这个盒子有两把钥匙）和其中一把钥匙（另外一把在 Jerry 手里）。
• 邮递员在拿到 Tom 给的信件之后，把 Tom 的信拆开看了一遍，了解到 Tom 但愿 Jerry 给 Tom 一个有锁的盒子，又用另外一个信封装了回去，并交给了 Jerry。
• Jerry 在收到 Tom 的信（实际已经被邮递员拆阅过了）以后，给了邮递员一个有锁的盒子和其中一把钥匙。
• 邮递员想知道他们的通讯内容，因而他把 Jerry 给 Tom 的盒子换成了他本身的盒子，并附上了本身盒子中的一把钥匙，并在以后将本身的盒子交给了 Tom。
• Tom 在收到盒子以后，觉得这个盒子是 Jerry 给他的，因而就把秘密的信件放进了盒子里，并把钥匙留下了，以后又交给了邮递员。
• 邮递员在拿到盒子以后，用本身的另外一把钥匙打开盒子，看了里面的信件。以后将信件调换以后放进了 Jerry 给的盒子，交给了 Jerry。
• Jerry 在拿到邮递员给他的盒子以后，并不知道这个盒子里的信件其实已经被邮递员调换过了，因此 Jerry 认为盒子里的信件是来自 Tom 且未被修改过的。以后 Jerry 把回信放进了盒子里，又交给了邮递员。
• 邮递员再次调换盒子里的信件，交给了 Tom。

这是一个典型的中间人攻击的过程，在Http中，Tom是客户端，Jerry是服务端，而邮递员就是客户端跟服务端之间的实体（包括代理服务器，路由器、反向代理服务器等），两把钥匙分别是公钥和私钥。通讯双方并不知道且很难发觉本身其实在和中间人攻击而非对方。在通讯过程当中，Tom和Jerry并无验证对方的身份，这就致使了邮递员能够任意查看、修改或者丢弃双方的通讯内容。

Http如何防范中间人攻击

非对称加密

用私钥对某个文件/某段消息的散列值进行签名就像一我的亲手在信件最后签上本身的名字同样，证实这份文件/这段消息确实来自本身的拥有者（由于公钥是公开的，私钥只有拥有者知道，因此若是能用其公开的公钥解开数字签名，那就证实这条消息确实来自于私钥的拥有者），这就能够确保消息是来自他所声称的那个实体。

不过有个问题，若是中间人在会话创建阶段把双方交换的真实公钥替换成本身的公钥，那么中间人仍是能够篡改消息的内容而双方不知情。为了解决这个问题，须要找一个第三方来为双方确认身份。即数字证书跟CA（数字证书认证机构）。

数字证书就是申请人将一些必要的信息（包括公钥、姓名、电子邮件、有效期）等提供给CA，CA在经过各类手段确认申请人确实是他所声称的人以后，用本身的私钥对申请人所提供信息计算散列值进行加密，造成数字签名，附在证书最后，再将数字证书颁发给申请人，申请人就可使用CA的证书想别人证实本身的身份了。对方收到数字证书以后，只须要用CA的公钥解密证书最后的签名获得加密以前的散列值，同计算数字证书中的信息的散列值，将二者进行对比，只要散列值一致，就证实这张数字证书是有效切且未被篡改。

通讯过程当中的安全性自下而上就是这样保证的：

• 双方通讯的内容的安全性是靠私钥加密，公钥解密来保证的，这一安全性由非对称加密的特性，即由私钥加密的信息只能使用对应的公钥才能解开来保证。因为私钥不会传递，只由拥有者知道，因此安全性就由公钥的正确性来保证。
• 公钥由双方在通讯初始化提供，但这时很容易被中间人替换掉，为了保证公钥的正确性，因此在发送公钥的时候也会提供对应的数字证书，用于验证这个公钥是对方的而不是中间人的。那么安全性就是由数字证书的正确性来保证了。
• 数字证书是由上级CA签发给我的/组织的，上级CA用本身的私钥给我的证书进行签名，保证证书中的公钥不被篡改，而接受者须要用上级CA证书中的公钥来解密我的数字证书中的数字签名来验证证书中的公钥是否正确。那么安全性就是由上级CA证书的正确性保证了。
• 可是上级CA证书也是由其上级CA签发的，这种信任关系一直到根证书。根证书没有上级CA为其签名，而是自签名，也就是他自身为自身签名，保证正确性。因此跟证书就是这个信任练最关键的部分。若是根证书泄露的话，其签名的全部证书及使用其签名的证书索签名的证书的安全性将不复存在。如今，安全性就是靠系统根证书的私钥不被泄露或者其公钥不被篡改来保证的。
• 根证书不该该经过网络分发，由于经过网路分发的话，可能被中间人攻击。通常根证书都经过操做系统或浏览器分发，在操做系统中会内置不少根证书，可是最初的操做系统也不能经过网络分发，由于中间人能够修改系统中的根证书。因此要确保安全只能靠最原始的方法，当面交流。硬件厂商会和证书签发机构合做，在电脑、手机等设备出厂的时候在其操做系统中内置签发机构的根证书，再将这些设备分发出去，这样，这些设备的用户就能够安全地进行信息交换了。因此，安全性就依赖于这些设备在分发到消费者手中以前不会被恶意修改来保证了。

SSLTrip和HSTS

HTTP协议最初的时候是明文的，由于安全问题因此如今不少网站都在逐渐过渡到HTTPS，然而对于大部分使用者来讲，他们并不知道HTTP和HTTPS的以前的区别，在浏览器输入地址的时候都是直接输入www.example.com而非https://www.example.com，在大部分状况下，若是一个网站使用了HTTPS，服务器会将这个请求使用301或者302状态码以及一个Location头部键将请求从80端口重定向至使用HTTPS的443端口，可是，若是中间人劫持了使用者的网络请求，那么中间人能够阻止客户端与服务器创建HTTPS链接，而是一直使用不安全的HTTP链接，而中间人和服务器创建正常的HTTP链接，让客户端觉得本身和真实服务器通讯。这种攻击手法称做SSLTrip。

为了而解决这个问题，IETF（互联网工程任务小组）引入了一个策略，叫作HSTS（HTTP Strict Transport Security，HTTP严格传输安全）。HSTS的做用是强制客户端与服务端创建安全的HTTPS链接，而非不安全的HTTP链接。若是一个站点启用了HSTS策略，那么客户端在第一次与该站点创建链接以后，在为来一段时间内（由一个HTTP头部控制，这个头部为：Strict-Transport-Security），客户端与该站点的全部链接都会直接使用HTTPS，即便客户端访问的是HTTP，也会直接在客户端重定向到HTTPS链接。

若是站点没有启用HSTS,用户能够忽略证书无效（域名对不上、自签名、不在有效期）的警告，继续创建链接，而若是站点启用了 HSTS，那么用户即便想冒风险，浏览器也不会继续访问。

HSTS 能够很大程度上防止 SSLTrip 攻击，不过这样仍是有个问题，那就是要启用 HSTS，浏览器至少要和服务器创建一次 HTTPS 链接，若是中间人一直阻止浏览器与服务器创建 HTTPS 链接，那么 HSTS 就失效了。解决这个问题有个办法，那就是将 HSTS 站点列表内置到浏览器中，这样只要浏览器离线判断该站点启用了 HSTS，就会跳过原先的 HTTP 重定向，直接发起 HTTPS 请求。

本内容摘自：
HTTPS中间人攻击及其防范

拒绝服务攻击(DDoS)

DDoS的攻击方式有不少种，最基本的DDoS攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户没法获得服务的响应。

被DDoS攻击时的现象

• 被攻击主机有大量等待的TCP链接
• 网络中充斥着大量的无用的数据包，源地址为假
• 制造高流量无用数据，形成网络拥塞，是受害主机没法正常和外界通信
• 利用受害主机提供的服务或传输协议上的缺陷，反复高速的发出特定的服务请求，是受害主机没法及时处理全部正常请求
• 严重时会形成系统死机

DDoS攻击实例--SYN Flood攻击

SYN-Flood是目前最流行的攻击手段。

SYN-Flood利用TCP/IP协议的固有漏洞。面向链接的TCP三次握手是SYN-Flood存在的基础。

如上图图，在第一步中，客户端向服务端提出链接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法，须要检查。客户端在TCP报头的序列号区中插入本身的ISN。服务端收到该TCP分段后，在第二步以本身的ISN回应(SYN标志置位)，同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中，客户端确认收到服务端的ISN(ACK标志置位)。到此为止创建完整的TCP链接，开始全双工模式的数据传输过程。

假设一个用户向服务器发送了SYN报文后忽然死机或掉线，那么服务器在发出SYN+ACK应答报文后是没法收到客户端的ACK报文的（第三次握手没法完成），这种状况下服务器端通常会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的链接，这段时间的长度咱们称为SYN Timeout，通常来讲这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常致使服务器的一个线程等待1分钟并非什么很大的问题，但若是有一个恶意的攻击者大量模拟这种状况，服务器端将为了维护一个很是大的半链接列表而消耗很是多的资源—-数以万计的半链接，即便是简单的保存并遍历也会消耗很是多的CPU时间和内存，况且还要不断对这个列表中的IP进行SYN+ACK的重试。实际上若是服务器的TCP/IP栈不够强大，最后的结果每每是堆栈溢出崩溃—即便服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP链接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率很是之小），此时从正常客户的角度看来，服务器失去响应，这种状况咱们称作：服务器端受到了SYN Flood攻击（SYN洪水攻击）。

DDoS的防范

主机上的设置
几乎全部的主机平台都有抵御DDoS的设置，基本的有几种：

• 关闭没必要要的服务
• 限制同时打开的SYN半链接数目
• 缩短SYN半链接的time out时间
• 及时更新系统补丁

网络设备上的设置

• 防火墙

  • 禁止对主机的非开放服务的访问
  • 限制同时打开的SYN最大链接数
  • 限制特定IP地址的访问
  • 启用防火墙的防DDoS属性
  • 严格限制对外开放的服务器的向外访问

本内容摘自：
分布式拒绝服务攻击(DDoS)原理及防范

XSS攻击

SQL注入攻击

SQL注入是一种危害极大的攻击形势，虽然危害很大，可是防护却远没有XSS那么难。

缘由

SQL注入的漏洞存在，就是拼接SQL参数，也就是将用于输入的查询参数，直接拼接在SQL语句中，致使了SQL注入漏洞。

例子

String sql = "SELECT id,no FROM user WHERE id = " + id;

其中id是用户输入的参数，那么若是用户输入2，那么上面查到的是一条数据，若是用户输入的是"2 or 1 = 1"进行SQL注入攻击，那么即将user表的全部记录都查找出来了。

SQL注入的防护

采用预编译和绑定变量

String sql = "SELECT id,no FROM user WHERE id = ?";
    PreparedStatement ps = conn.preparedStatement(sql);
    ps.setInt(1,id);
    ps.executuQuery();

缘由：采用了PrepareStatement，就会将sql语句："SELECT id,no FROM user WHERE id = ?"`预先编译好，也就是SQL引擎预先进行语法分析，产生语法书，声称执行计划，也就是说，后面你输入的参数，不管输入什么，都不会影响该SQL语句的语法结构，后面输入的参数，毫不会被做为sql命令来执行，只会被当作字符串面值参数。

在实际项目中，通常都是采用各类框架，好比ibatis,hibernate，mybatis等，他们通常默认就是sql预编译。对于ibatis/mybatis，若是使用#{name}形式的，那么就是SQL预编译，使用${name}，就不是SQL预编译。

mybatis中的#跟$：
#{}：解析为一个JDBC预编译语句的参数标识符，一个#{}被解析为一个参数标识符。
${}：仅仅做为一个纯粹的String替换，在动态SQL解析阶段进行变量替换。

eg：

-- id = 123
    SELECT id,no FROM user WHERE id = #{id} -- > '123'
    SELECT id,no FROM user WHERE id = ${id} -- >  123

本内容参考：
sql注入防护方法总结
Mybatis 中$与#的区别