上述简易的登录验证策略存在明显的安全漏洞,需要优化。
客户端第一次发出登录请求时, 用户密码以明文的方式传输, 一旦被截获, 后果严重。因此密码需要加密,例如可采用RSA非对称加密。具体流程如下:
再仔细核对上述登录流程, 我们发现服务器判断用户是否登录, 完全依赖于sessionId, 一旦其被截获, 黑客就能够模拟出用户的请求。于是我们需要引入token的概念: 用户登录成功后, 服务器不但为其分配了sessionId, 还分配了token, token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据,也需要加密。于是一次登录的细节再次扩展。
在最原始的方案中, 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id,就认为请求来自相应的登录客户端。 但是只要sessionId被截获, 请求就可以为伪造, 存在安全隐患。
引入token后,上述问题便可得到解决。 服务器将token和其它的一些变量, 利用散列加密算法得到签名后,连同sessionId一并发送给服务器; 服务器取出保存于服务器端的token,利用相同的法则生成校验签名, 如果客户端签名与服务器的校验签名一致, 就认为请求来自登录的客户端。
1.3 TOKEN失效
用户登录出系统
失效原理:
在服务器端的redis中删除相应key为session的键值对。
App因为要实现自动登陆功能,所以必然要保存一些凭据,所以比较复杂。
App登陆要实现的功能:
这里判断时间,主要是防止攻击者截取到加密串后,可以长久地利用这个加密串来登陆。
不用AES加密,用RSA公钥加密也是可以的。AES速度比RSA要快,RSA只能存储有限的数据。
这个问题存在于设置了后台域名的朋友找到文件 phpcms\modules\attachment\functions\global.func.php 其中的initupload函数:
$upload_path = empty($admin_url) ? APP_PATH : 'http://'.$admin_url.'/'
$swf_auth_key = md5(pc_base::load_config('system','auth_key').$sess_id)
下面加一句
$swf_path = empty($admin_url) ? JS_PATH : 'http://'.$admin_url.'/statics/js/'
然后把
flash_url:"'.JS_PATH.'swfupload/swfupload.swf?"+Math.random(),
修改为
flash_url:"'.$swf_path.'/swfupload/swfupload.swf?"+Math.random(),
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)