1、httponly
session一定要用httponly的否则可能被xxs攻击,利用js获取cookie的session_id。
要用框架的ci_session,更长的位数,httponly,这些默认都配好了。
不要用原生的phpsession,而要用ci_session。ci_session位数更长。
如果要用原生的session,应该这样设置(php.ini):
session.sid_length //sid的长度,这里要加长,默认的太短了
session.cookie_httponly = 1原生的session就会变成httponly了。
2、phpinfo
一定要关闭phpinfo页面,dump的请求信息可能会被攻击者利用。比如cookie信息。
3、强制全站https
通过cdn跳转,本地开发环境也要配https。如果有的环节不能使用https,比如消息推送,那么可以新建一个站点。
4、Strict mode
session.use_strict_mode = 1
只使用服务端自己生成的session id,不使用用户客户端生成的session id。
5、CSRF跨站请求伪造
A的cookie里有站点example.com的session id,并且未过期,B通过放一个图片在论坛上,引诱A去点击这个图片,这个图片会发起一个请求,请求伪装成example.com,A的浏览器信以为真,将example.com的cookie附加到了这个请求上面,这个请求信息被B的代码截获并且通过异步请求发送给了B,B通过这个cookie登录了A在example.com的账户。
CI有防CSRF机制,即他会在表单里面自动的插入一个隐藏的CSRF字段。需要进行如下设置:
application/config/config.php:
$config['csrf_protection'] = TRUE;
注意,这个开了以后,所有的向外站进行的请求都被阻止了。如果我们网站有向其他网站获取数据的行为,比如说调用api,那就不可以启用这个开关。
6、xss攻击
CI会对post数据进行xss过滤,只要这样调用:
$this->input->post('a',true);
只要加一个参数true,就可以对post的数据进行xss过滤。
7、重放
你把用户名密码加密了,传到服务器进行登录验证,攻击者并不需要解密你这些用户名密码,他只要把截获的这些数据包,重新再操作一次,就可以实现登录,这就是重放。
5、6的防御措施:每个表单包含一个隐藏的只能用一次的随机码token。
只用一次的token实现:redis 到期失效 使用后直接删掉
8、总结:用户安全登录流程
<1>session基本策略:
(1)session仅作会话session,关闭浏览器即失效;
(2)session的有效期设置得越短越安全,比如说60秒;
(3)相应的需要修改session的刷新时间,比如说30秒;
(4)设置用redis存储session。
配置如下:
在php.ini:
session.gc_maxlifetime = 60
这个是session的有效期,默认是1440秒,即24分钟,改为比如说60秒。当60秒后,客户端跟服务端这个sid对得上的话,也是无效的,应该在60秒之前刷新一次页面更新sid,怎么更新下面有说;
在application/config/config.php:
$config['sess_driver'] = 'redis';//设为用redis存储session $config['sess_cookie_name'] = 'ci_session'; $config['sess_expiration'] = 0;//设为会话session,关闭浏览器,客户端cookie即失效 $config['sess_save_path'] = 'tcp://127.0.0.1:端口号';//redis地址 $config['sess_match_ip'] = FALSE;//要不要验证ip是否一致 $config['sess_time_to_update'] = 30;//超30秒即刷新sid $config['sess_regenerate_destroy'] = TRUE;//重新生成sid的时候删除旧sid
<2>session id的刷新及session的过期时间区分:
注意:这些设置跟安全关系非常大,应该注意区分及使用。
上面说的session.gc_maxlifetime是什么意思?即一个session从产生,到过期不能用的时间。其实如果使用redis就清楚了,这个值就是使用redis保存sid的时候,设定的一个存续时间,这就很清楚了,当一个sid产生的时候就会把这个时间写进去,那么到了这个时间,这个key-value就会被删掉。
那么这个sess_time_to_update呢,这个顾名思义是刷新时间,这个时间是一个阈值,是指超过这个时间即刷新。并不是自动刷新,而是访问session的时候刷新!当我们在使用session的时候,他会去判断上次使用session跟这次使用session的间隔,如果间隔大于这个值,即刷新sid。这个使用,通常的表现就是我们在刷新页面,需要读取session以鉴权,那么就是在刷新页面的时候,两次间隔有超过这个时间,即刷新sid,那么结合上面的maxlifetime呢,就是刷新完之后session重新续命了,一个新的session写进去,连带一个重新开始的计时。
就是说呢,如果我们一会刷一下页面一会刷一下页面,那么必然会在必要的时候触发我们的刷新机制,那么我们的session就不会过期了,永远不会,如果经常性的在那里刷的话。如果两次刷新的时间间隔超过maxlifetime呢,这时会显示登录超时了,session已经没了,因为在过期了之后你去update,显然是不行了,update失败。
那么总结就是,这个maxlifetime决定了我们两次刷新之间不能超过多长时间,否则登录超时;而update呢肯定要小于maxlifetime,这是必然的,因为如果大于就无效了,因为过期了刷新没用。并且最好我觉得这个update最好是maxlifetime的一半以下。如果maxlifetime很长的话(希望改善用户体验,让用户老是登录超时总是不大好),那么这个update设的比较短也没关系,因为设的比较短的话,假设这个session被偷了那么有比较大的可能这个贼去使用的时候已经过期,安全性会比较高。
<2>one-times-tokens:
一次性的token
参考这个文章:
CSRF的攻击方式详解 黑客必备知识
老生常谈重放攻击的概念(必看篇)
以上这篇浅谈php(codeigniter)安全性注意事项就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持三水点靠木。
浅谈php(codeigniter)安全性注意事项
- Author -
jingxian声明:登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。
Reply on: @reply_date@
@reply_contents@