对于api安全性的思考

　　目前的状况下api被不少地方应用，随之而来的是api的安全性问题。

　　我所认识到的安全性问题有如下几个方面：
　　一、DDoS(拒绝服务攻击)，接口被恶意调用，使真实的用户没法享受到正常畅通的服务。
    　　这个比较单纯，也比较容易处理，经过IP限制来作，而且辅以一些硬件设备应该就没问题了，同时服务器供应商也能够提供相应的服务。

　　二、传输过程当中数据被截获，http数据包是能够被截获到的，这一点咱们没法防止，能作的只有使被截获到的数据对截获者来讲无心义。
    　　这个问题要分红两种状况来讲明，第一种状况，api站点采用了https，那么在网络中传输的数据就是被加密过的数据，这种数据截获者很难把他解密出来，因此能够保证数据的安全性。第二状况，api站点没有采用https，而是使用的普通的http，若是不加任何处理其实传输的数据是在裸奔，固然有些数据就是给截获者截获到也没有什么影响，但对于敏感的信息咱们仍是要想办法来处理下的，要么协商一种相同的加密方法，这样起到加密做用。另外请求时使用token不直接传以明文密码暴露的机会，同时最好是在传输前就把信息MD5一下，这样对用户的在网站上的安全性是有好处的。总的来讲不使用https的传输是不安全的，有意义的敏感信息有可能会被截获到，建议在登陆相关的接口有条件时必定使用https，若是使用http登陆也必定要处理一下敏感信息，好比这样MD5(变形(MD5(原文)))，这样即便被截获也能够保证截获人不能获得原文，也就保证了用户在其余网站上账号的安全。

　　三、伪造请求，在上一种状况的基础上，截获者能够利用截获到的数据发起伪造的请求，固然https不会有这个问题。
    　　解决这个问题的一个方法是，让请求成为一次性的或者说只能在短期内有效，能够在参数中再加入一个签名（sign），签名是由时间戳加参数MD5构成的，这样能够在服务端验证其有效性与时效性，这个方法在他人不知道签名生成规则时是有效的。可是若是程序被反编译就能够比较容易的知道生成规则。更靠谱一点的话就在生成sign时增长key值（不过这对app并非太适用，由于若是key改变就要更新app），不过这样仍是躲不过反编译，因而防止反编译也是重要的一环了。另外的一个途径是保证数据确实是从真实的客户端发出来的，这个就要从token上想办法了，例如对比IP，但这种途径显得比较苍白无力同时有局限性（如第一次登陆，同时IP在实际状况下发生变化也不该该被认为不合法）。还有能够在重要的操做时应用二次受权，这样能够下降风险。

 

附：

一、 传输中加上签名sign不是为了防止被截获，而是为了防止被篡改或发出伪造请求。

二、 数字签名是对所传输数据的散列后的摘要使用私钥加密获得的结果，
　　数字签名使得接收方能够确认信息是可靠的，由于只有指定私钥加密的内容接收方才能够解密出来。
　　对于指定的MD5结果，能够有方法找到多个文本与之对应。即单次单纯的MD5是不够安全的，能够经过MD5(变形(MD5(原文)))来解决这个问题。
三、 数字证书是由权威机构用本身的私钥加密服用提供方的公钥并搭载其余相关信息组成的。

四、 使用token是为了惟一标识用户，应该在数据库中维护这些数据，它应有的关联属性（用户ID、IP、到期时间、是否有效）