浅谈Http API验证

### 前言

目前web应用主要面临的安全问题：

1. 数据篡改

2. 数据窃取

3. 重放攻击

4. 非法参数提交 （SQL注入,XSS等）.

### 防范

  好了既然问题那么多，我们怎么其防范呢？经常在网上下东西的人可能会碰到这样的情况，就是你下载的资源会对应一个checksum.用这个校验码来确定本次你下载的东西，在下载过程中没有被人篡改，这个就叫数字签名。可能有人要问了，我们说的是HTTP验证的东西，跟这个有半毛钱的关系呀？聪明的朋友可能想到了，假如我们把每个HTTP请求都加上一个数字签名，那么数据篡改的问题是不是就可以避免的呢？答案是肯定可以的，因为HTTP请求验证方式中，有一种方式就是数字签名（http digest auth）。亚马逊很多校验请求用的就是这个方式。这种方式简单的说，就是客户端和服务端通过一些随机数+请求参数+URL+头部+时间戳等信息通过hash算法生成一个checksum，发送给接收端，接受端同样采用相同的算法，计算checksum是否一致来确定本次请求过程中数据有没有被篡改，从而保证了请求的合法性。

### 实施

上面说的这个原理中主要包含几个要素： 

- key：

  这个key只能是客户端和服务端知道，否则无法保证请求的合法性验证了。key的生成方式可以根据应用来区分：

  传统web应用：服务器可以根据客户端浏览器的信息，结合请求的IP，User-Agent等信息产生一个key。

  移动APP应用：可以通过事先约定key的方式（前提不能被反编译），或者通过一些非对称加密来生成一个key

  总的一点就是：这个key很重要，不能泄漏出去，上面的两个方法可以用来参考，如果看官们又更好的方法，欢迎讨论。

- Header:

  比如请求方法呀，请求路径之类的.

- 参数：

  构成本次合法请求的参数。

- 时间戳 ：

  其实这个时间戳主要是用来防止重放攻击的。服务器端和客户端可以约定一个请求时间范围。超过这个时间段属于是非法请求。

接着我们将上面的三个元素通过一些不可逆的算法生成一个checksum，

如：hmac(key + header + params + ts + ...)

然后连同参数（URL，表单信息，sessionid等）信息一同传递给接收端，接收端根据相同的规则对数据进行验证。

### 展开思路

  因为每个请求都有唯一的checksum,那么我们可以在这个基础上加上鉴权功能，如某个Appid只能访问某个path

### 总结

上面方法中能保证的安全有两部分： 1,数据防篡改 2,重放攻击

要需要防止数据窃取，还是需要将https加入进来。

关于非法数据引起的一些问题，想必开发们也都碰到过，如果是防止sql注入最好在前端做一次参数检查，后端参数检查，用sql参数化的方式。xss攻击也是需要在各个点进行参数检查。

总的来说知道各种安全问题，才能写出健壮的程序来。