token 网络安全 请求密钥

接口的安全性主要围绕token、timestamp和sign三个机制展开设计，保证接口的数据不会被篡改和重复调用，下面具体来看：

 Token授权机制：

用户使用用户名密码登录后服务器给客户端返回一个Token（通常是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。Token是客户端访问服务端的凭证。

 时间戳超时机制：

用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如5分钟），则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。

 签名机制：

将 Token 和 时间戳 加上其他请求参数再用MD5或SHA-1算法（可根据情况加点盐）加密，加密后的数据就是本次请求的签名sign，服务端接收到请求后以同样的算法得到签名，并跟当前的签名进行比对，如果不一样，说明参数被更改过，直接返回错误标识。签名机制保证了数据不会被篡改。

 拒绝重复调用（非必须）：

客户端第一次访问时，将签名sign存放到缓存服务器中，超时时间设定为跟时间戳的超时时间一致，二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次。如果有人使用同一个URL再次访问，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。如果在缓存中的签名失效的情况下，有人使用同一个URL再次访问，则会被时间戳超时机制拦截。这就是为什么要求时间戳的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用（如抓取数据）。

流程如下：

• 客户端通过用户名密码登录服务器并获取Token
• 客户端生成时间戳timestamp，并将timestamp作为其中一个参数。
• 客户端将所有的参数，包括Token和timestamp按照自己的算法进行排序加密得到签名sign
• 将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边（http://api.com/users?token=asdsadasd&timestamp=123&sign=123123123）
• 服务端写一个过滤器对token、timestamp和sign进行验证，只有在token有效、timestamp未超时、缓存服务器中不存在sign三种情况同时满足，本次请求才有效

在以上三中机制的保护下，

如果有人劫持了请求，并对请求中的参数进行了修改，签名就无法通过；

如果有人使用已经劫持的URL进行DOS攻击，服务器则会因为缓存服务器中已经存在签名或时间戳超时而拒绝服务，所以DOS攻击也是不可能的；

如果签名算法和用户名密码都暴露了，那齐天大圣来了估计也不好使吧...

最后说一句，所有的安全措施都用上的话有时候难免太过复杂，在实际项目中需要根据自身情况作出裁剪，比如可以只使用签名机制就可以保证信息不会被篡改，或者定向提供服务的时候只用Token机制就可以了。如何裁剪，全看项目实际情况和对接口安全性的要求~

网络安全学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

需要网络安全学习路线和视频教程的可以在评论区留言哦~

最后

• 如果你确实想自学的话，我可以把我自己整理收藏的这些教程分享给你，里面不仅有web安全，还有渗透测试等等内容，包含电子书、面试题、pdf文档、视频以及相关的课件笔记，我都已经学过了，都可以免费分享给大家！

给小伙伴们的意见是想清楚，自学网络安全没有捷径，相比而言系统的网络安全是最节省成本的方式，因为能够帮你节省大量的时间和精力成本。坚持住，既然已经走到这条路上，虽然前途看似困难重重，只要咬牙坚持，最终会收到你想要的效果。

黑客工具&SRC技术文档&PDF书籍&web安全等（可分享）

结语

网络安全产业就像一个江湖，各色人等聚集。相对于欧美国家基础扎实（懂加密、会防护、能挖洞、擅工程）的众多名门正派，我国的人才更多的属于旁门左道（很多白帽子可能会不服气），因此在未来的人才培养和建设上，需要调整结构，鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”，才能解人才之渴，真正的为社会全面互联网化提供安全保障。

特别声明：
此教程为纯技术分享！本教程的目的决不是为那些怀有不良动机的人提供及技术支持！也不承担因为技术被滥用所产生的连带责任！本教程的目的在于最大限度地唤醒大家对网络安全的重视，并采取相应的安全措施，从而减少由网络安全而带来的经济损失