近日接到一个需求,要求一台资源服务器不仅在可以暴露在公网环境下的同时,还要保证只接受并处理可信的http访问请求。
需求场景如图:
为了访问资源文件,用户需要首先访问某一台Frontend Server进行用户身份认证———所有的用户信息均由Frontend Server保存,Frontend Server认证通过后返回真实的重定向地址,用户再根据重定向地址访问Resource Server获取资源文件。
具体的使用场景正如上面所述,下面是我的思考过程...
为了保证资源服务器收到的是一个可信的重定向地址,在安全性上有三点考虑:
- 重定向地址必须是可信的,即不可以被伪造,必须是由某一台Frontend Server返回的重定向地址。
- 为了防止盗链或资源被采集,每个Frontend Server返回的重定向地址应具有时效性。这个可以通过在链接地址上增加时间戳实现,但前提是该时间戳不可以被伪造。
- 最后,在必要的情况下,还可以不去响应某一台Frontend Server返回的重定向地址,即认为某一台Frontend Server的重定向地址不可信、该Frontend Server不可信。这要求Resource Server能够及时标示一台Frontend Server为不可信服务器,并且该Frontend Sever服务器还不可伪造剩余可信服务器返回的重定向地址。
以上三点也可以总结为:防止公网用户伪造URL地址,防止不可信Frontend Server伪造地址,防止过期URL地址访问。
由于Resource Server需要允许所有的公网用户访问,所以不能对Ip进行限制,并且一般情况下Resouce Server也不会与Frontend Server直接通信,因此只能通过URL的验证方式。Frontend Server在生成每个URL的过程中中应包括Resource Server为每一个Frontend Server分配的账户fsId、密钥fsKey以及记录当前URL生成时间的时间戳fstime。fsid必须明文传输,fsKey做为加密运算的一个常量不可以明文传输。
可以想到的有如下三种:
1.使用自定的加密函数生成加密签名字符串。
加密函数将所有需要明文传输的参数以及当前Frontend Server使用的密钥fsKey做为参数并通过MD5转换后生成加密签名字符串,md5(encode(params,fsid, fskey, fstime))。
重定向地址链接:
http://res.com/fsid=***&fstime=***¶ms=***&signmsg=md5(encode(params,fsid,fskey, fstime))
Resource Server收到该请求后
- 根据fstime判断该请求是否过期,过期请求直接返回。
- 根据fsid判断该Frontend Server是否可信,如可信再根据fsid获得服务器端保存的fskey。
- 使用相同的参数加密签名过程,Resource Server根据params,fsid, fskey, fstime生成签名字符串。
- 比较重定向地址传来的签名字符串signmsg与本地生成的签名字符串是否相同,相同则认为是可信请求,否则为非法请求。
2.使用对称加密算法保证HTTP通信可信。
Resource Server为每一台Frontend Server分配不同的Des密钥(fskey),Frontend Server使用对称加密算法对拼接后的传递参数进行加密des(params|fstime)
重定向地址链接:
http://res.com/fsid=***&desmsg= des(params|fstime)
Resource Server收到该请求后
- 首先根据fsid判断该Frontend Server是否可信,如可信再根据fsid获得每个Frontend Server使用的Des密钥fskey。
- 使用密钥对desmsg信息解密,解密失败直接返回。
- 根据解密后的fstime判断是否过期,过期直接返回。
3.同时使用非对称,对称加密算法保证HTTP通信可信。
Frontend Server随机生成key做为对称加密算法的公钥des(params|fskey|fstime),并使用Resource Server提供的公钥对key进行非对称加密rsa(key)
重定向地址链接:
http://res.com/fsid=***&rsamsg=rsa(key)&desmsg= des(params|fskey|fstime)
Resource Server收到该请求后
- 首先根据fsid判断该Frontend Server是否可信,如可信再根据服务器端保存的非对称加密私钥解密rsa(key)。
- 根据key解密des(params|fskey|fstime)。
- 通过fsid获得服务器端保存的fskey,对比解密后的fskey,如果不相同则认为是Frontend Server伪造的非法请求。
- 根据fstime判断是否过期,过期直接返回。
以上三种方法第一种会暴露所有的明文传递参数,第二种貌似最方便但却有被攻破的危险,第三种有可能又会产生效率的问题。
由于没有进行过相关方面的开发,以上也是对平时了解有限的一些资料的总结,难免考虑不周。各位有更好的方法和建议吗?
分享到:
相关推荐
java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种加密方式java三种...
URL参数加密解密;使用简便;URL参数加密解密;使用简便;URL参数加密解密;使用简便;URL参数加密解密;使用简便;
asp.net web URL 伪装或加密 能保护 URL 地址!
主要介绍了Java实现url加密处理的方法,涉及java基于base64、编码转换实现加密解密相关操作技巧,需要的朋友可以参考下
web前端三种常见的通过JS加密文本方式,包含md5、base64、sha1,源文件
url传递参数 加密,,,DEC 加密过程,
.net c#URL加密 在网上看那些都不是委明白,自己做了一个比较简单,而且容易明白的
网站url加密解密asp.net .net url加密网站url加密解密asp.net .net url加密网站url加密解密asp.net .net url加密网站url加密解密asp.net .net url加密网站url加密解密asp.net .net url加密
2、URL加密传输 3、数据库储存 4、本地储存 5、加密/解密任意字符 6、静态加密/动态加密 设计思路: 1、运行效率 (让马儿跑得比火箭快) 2、耗能低 (给马儿喝尿) 3、稳定 由于字数限制,请到博客看详细介绍 ...
有几种常见的加密方式和实现.
url解码器 用于破解url,加密字符串
url编码加密解密器 url编码加密解密器 url编码加密解密器1
URL传递参数的一种加密方法,让您的参数不在明文传输
微软自己本身的加密及解密对象及方法,方便供广大的开发人员的使用!
DEC 加密过程 第一个参数:被加密的字符串 第二个参数:密钥(只支持8个字节的密钥 返回:加密后的字符串
本文给大家分享一段给url参数加密解密的javascript代码,非常的好用,有需要的小伙伴直接拿走吧
C#各种加密方式 C# 加密方式 北大青鸟高老师 沈阳森淼
C#_URL加密
java中对一串URL进行加密,并建立指定密钥的算法及规则,并建立解密方式进行比对截取解密后的数据。
解决URL传输过程中得加密,解密问题,无论多少个参数,地址栏上显示的只有一个经过加密得URL,到达客户端再解密成多个参数值,同时可以解密字符串,加密字符串