晚上没有加班,回来后尝试几个感觉不错的行动:1.列出当天最有意义的五件事;2.靠墙站,纠正自己的姿势同时锻炼眼睛;这两点以后也要坚持成为每天的习惯。然后我又陷入了知乎的各种信息中,一个多小时的时间悄悄地流逝,我浏览过的内容中印象深的是性格改变,自我提升,自我管理,web安全相关的内容。下面摘录我觉得很不错的Web安全相关的内容:
CSRF的全称是Cross Site Request Forgery,就是跨站点伪造请求攻击。 简单理解:Bad guy盗用你的身份,做桌下交易。
详细原理看Cross Site Request Forgery
经典案例:
看看乌云网友如何通过CSRF漏洞,自动加关注和发微博。 我是如何刷新浪微博粉丝的
防御措施:
最有效的措施,对敏感操作增加CSRF Token验证并尽量采用POST请求方式(虽然GET 也可以增加Token验证)。
1、用户第一次请求网站是生成CSRF Token并保存到session中。 2、POST请求时,增加Input Field csrf_token, 参数值通过session获得。 3、服务器端验证Token的合法性,并更新token。
XSS攻击可以说最常见最严重的漏洞攻击了。
XSS的全称是Cross-site Scripting,就是跨站脚本攻击。主要分为非存储型XSS(反射型)和存储型XSS. 详细介绍看WIKI吧: Cross-site scripting
防御措施:
1、输入过滤, 即使用Filter 过滤一些敏感字符"<" ">" "#" "script"等. 2、输出过滤(output encoding),htmlEncode, javascriptEncode 3、对敏感操作增加验证码
过滤工具推荐(JAVA):
https://code.google.com/p/owaspantisamy (比较全面,但有点重)
https://code.google.com/p/xssprotect/
SQL注入这种老掉牙的攻击手段,我就不多介绍了。
最简单的防御措施,使用预编译方式绑定变量:
JDBC 使用PreparedStatement.
mybatis/ibatis 使用静态变量#
1、对于无需JS访问的cookie设置HTTPOnly 2、不要在cookie存放用户敏感数据。
合理设计一个cookie自动登录方案
要保存哪些数据:
1、cookie保存base64 encode(username|sequence|token)的value。
2、服务器使用Redis的Hashs结构保存以下这几个值。
Key: user::cookie hashKey: userAgent_ip,userAgent_sequence,userAgent_token,userAgent_expireTime
如何验证COOKIE登录:
1、如果expireTime没到而且username,sequence,token均相同,登录成功。
2、如果expireTime没到,username和sequence相同,token不同,但IP相同和userAgent不同,登录成功。为什么要这样的设计?因为同一用户可能会使用的不同设备/浏览器登录。
3、其余情况均登录失败,并清空登录cookie。
4、成功登录后,服务器update token,同时更新cookie。
后续操作:
1、修改密码/点击退出,更新服务器端的token和sequence。
2、对于敏感操作(如修改个人私隐信息,Email,password等)需要输入密码。
相信大家还记得CSDN 明文密码被暴库泄露的事件吧。 最近又有被暴库的,300w用户数据。住哪网300W+用户明文密码泄露
防御措施:
对密码采用MD5/SHA(salt+password)进行HASH,salt是一串字符,为防止Rainbow Table 破解用的, salt应该放在一个隐秘的地方(某处代码或配置文件中)。
一般来说,防御DDos的攻击是比较难,常见的DDOS方式较多(网络层DDOS、应用层DDOS等)。
一些非物理措施:
1、增加anti-spam 机制
2、限制IP请求频率, 结合ip+cookie定位一个client
3、调小Timeout, KeepAliveTimeOut, 增加MaxClients
4、增加容灾机器,优化网站性能。
5、合理配置防火墙。
摘自:http://www.qixing318.com/article/programmers-need-to-master-the-knowledge-of-web-security.html
1. 如果在操作系统层上没处理好,比如Linux的Bash环境把“特殊数据”当做 指令执行时,就产生了 OS命令执行的安全问题,这段“特殊数据”可能长得如下这般:
; rm -rf /;
2. 如果在存储层的数据库中没处理好,数据库的SQL解析引擎把这个“特殊数据”当做 指令执行时,就产生 SQL注入这样的安全问题,这段“特殊数据”可能长得如下这般:
' union select user, pwd, 1, 2, 3, 4 from users--
3. 如果在Web容器层如nginx中没处理好,nginx把“特殊数据”当做 指令执行时,可能会产生远程溢出、DoS等各种安全问题,这段“特殊数据”可能长得如下这般:
%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%20
4. 如果在Web开发框架或Web应用层中没处理好,把“特殊数据”当做 指令执行时,可能会产生远程命令执行的安全问题,这段“特殊数据”可能长得如下这般:
eval($_REQUEST['x']);
5. 如果在Web前端层中没处理好,浏览器的JS引擎把“特殊数据”当做 指令执行时,可能会产生XSS跨站脚本的安全问题,这段“特殊数据”可能长得如下这般:
'"><script>alert(/cos is my hero./)</script>
...