晚上没有加班，回来后尝试几个感觉不错的行动：1.列出当天最有意义的五件事；2.靠墙站，纠正自己的姿势同时锻炼眼睛；这两点以后也要坚持成为每天的习惯。然后我又陷入了知乎的各种信息中，一个多小时的时间悄悄地流逝，我浏览过的内容中印象深的是性格改变，自我提升，自我管理，web安全相关的内容。下面摘录我觉得很不错的Web安全相关的内容：

CSRF 攻击

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攻击可以说最常见最严重的漏洞攻击了。

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注入攻击

SQL注入这种老掉牙的攻击手段，我就不多介绍了。

最简单的防御措施，使用预编译方式绑定变量：

JDBC 使用PreparedStatement.

mybatis/ibatis 使用静态变量#

正确地使用Cookie

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、应用层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>

...

• 摘自：http://www.zhihu.com/question/21606800