HTTP固然足够好，但是在安全方面有着很大隐患：
1、与服务器进行通信使用的是明文，内容可能会被窃听（HTTP协议本身并不具备加密功能，所以无法对请求和响应的内容进行加密）
2、使用HTTP协议的服务器与客户端都不会验证通信方的身份，可能遭遇伪装。（所谓不验证通信方身份的意思是，比如说服务端，在服务端接收到请求的时候，只要请求的信息正确，服务器并不会去验证，这个请求是否由其对应的客户端发出。并且，服务器会对请求立即做出一次响应，返回相应的数据）
3、使用HTTP协议的服务器与客户端都无法验证报文的完整性，所以在通信过程中，报文有可能会被篡改
基于这样的安全问题，衍生出各种加密技术，对于HTTP协议来说，加密的对象有以下两个：
1、对通信的加密：
& & HTTP中没有加密功能，但是可以通过和SSL(Secure Socket Layer，安***接层)组合使用，加密通信内容。使用SSL建立安全通信线路后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure，超文本传输安全协议）。
2、对通信内容本身进行加密
& & 即对HTTP报文里所包含的内容进行加密。这样，首先客户端要先对报文进行加密，然后再发给服务器。服务器在接受到请求时，需要对报文进行解密，再处理报文。该方式不同于SSL将整个通信线路进行加密处理，所以内容仍然有被篡改的风险。
A、任何人都可以发起请求
& & HTTP协议中，并未有确认通信方这一步骤，所以，任何人都可以发送请求，而服务器在接受到任何请求时，都会做出相应的响应。（仅限于发送端的ip地址和端口号没有被服务器限制访问）
1、无法确认请求发送到目标服务器（按照真实意图返回响应的那台服务器），这里可能在通信中途被伪装的服务器返回响应。
2、无法确认响应返回的客户端是目标客户端（按照真实意图接受响应的那台客户端），可能是伪装的客户端。
3、无法判断请求来自何方、出自谁手。
4、即使是无意义的请求也会都接受（无法阻止海量请求下的DoS（拒绝服务攻击）攻击）。
解决方案：
& & 查明对手的***
& & 虽然HTTP不能确认通信方，但SSL是可以的。SSL不仅提供了加密处理，还使用了"***"的手段，可用于确认通信方。***是由值得信赖的第三方机构颁布，可用于确定证明服务器和客户端是实际存在的。所以，只要能确认通信方持有的***，即可判断通信方的真实意图。
B、无法判断报文是否完整（报文可能已遭篡改）
& & HTTP协议无法判断报文是否被篡改，在请求或者响应发出后，在对方接收之前，即使请求或者响应遭到篡改是无法得知的。
& & 防止篡改：
& & 常用的，确定报文完整性方法：MD5、SHA-1 等 散列值校验方法，以及用来确认文件的数字签名方法。但是，使用这些方法，也无法百分百确保结果正确，因为MD5本身被修改的话，用户是没办法意识到得。
& & 为了有效防止这些弊端，可以采用HTTPS。
& &在iOS开发中，我所遇到的加密技术，一般是使用MD5加盐对密码进行加密，这是每个项目必须的。然后就是，有一家公司，采用的是对HTTP报文内容在前端通过加密算法进行加密、解密（也就是我们发送请求给服务器的时候，把model转化为字符串，然后对字符串进行MD5\AES等方法加密，发送给服务器。然后拿到服务器响应报文中的model字符串，经过解密后，转化为model）。
阅读(...) 评论()