浅谈Http API验证

0x01

首先我们得知道，目前web应用主要面临的安全问题：

1.数据篡改

2.数据窃取

3.重放攻击

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

0x02

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

0x03

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

key：

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

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

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

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

参数：

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

时间戳 ：

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

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

如：hmac(key+params + ts)

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

0x04

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

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

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

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

小弟不才，文字功底不行，还有上面内容可能有不对的地方，还望大神们指出！！