浅谈Http验证

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攻击也是需要在各个点进行参数检查。

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

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