客户端脚本安全
浏览器安全
同源策略
例外标签
<script>,<img>,<iframe>,<link>等标签不受同源限制
但浏览器限制了JS的权限，使其不能读、写返回的内容
限制范围
DOM
Cookie
XMLHttpRequest
XMLHttpRequest受到同源策略的约束，不能跨域访问资源
浏览器沙箱
sandbox，泛指“资源隔离类模块”
设计目的一般是为了让不可信的代码运行在一定的环境中，限制不可信代码访问隔离区之外的资源
恶意网址拦截
挂马网站
利用浏览器的漏洞执行shell code，在用户电脑中植入木马
钓鱼网站
通过模仿知名网站的相似页面来欺骗用户
跨站脚本攻击（XSS）
XSS本质
Cross Site Script => 一种HTML注入
XSS类型
反射型XSS
eg. 诱导用户“点击”一个恶意链接才能攻击成功
存储型XSS
eg. 保留一个含有恶意JS代码的网页在服务器端，所有访问者都会被执行恶意代码
DOM Based XSS
eg. 通过修改DOM节点形成的XSS
XSS Payload
通过读取浏览器的Cookie对象，从而发起“Cookie劫持”攻击
攻击者可以不通过密码而直接登录
XSS钓鱼
通过钓鱼实现“与用户交互”获取用户关键信息
防范措施
针对XSS的Cookie劫持
在Set-Cookie时为Cookie标注“HttpOnly”标识
过滤<base>标签
攻击者可以劫持当前页面中所有使用“相对路径”的标签
输入检查
XSS Filter
客户端JS与服务器端同时检查，阻挡大部分误操作的正常用户
输出检查
安全编码
HtmlEncode
JavascriptEncode
UrlEncode
处理富文本
对标签使用白名单
eg. 只允许出现<a>,<img>,<div>等比较"安全"标签
使用开源XSS Filter项目
eg. Anti-Samy
跨站点请求伪造（CSRF）
CSRF概念
Cross Site Request Forgery => 跨站点请求伪造
攻击者利用用户的身份操作用户账户的一种攻击方式
源于Web的隐式身份验证机制
虽然可以保证一个请求是来自于某个用户的浏览器
但却无法保证该请求是用户批准发送的
防范措施
验证码
强制用户必须与应用进行交互才能最终完成请求
Referer Check
检查请求是否来自合法的“源”
eg. 防止图片盗链应用场景
缺陷在于服务器并非任何时候都能取到Referer
Token
Anti CSRF Token
一定要使用安全的随机数生成器生成Token
同时要注意Token的保密性和随机性
点击劫持（ClickJacking）
基本概念
一种视觉上的欺骗手段
eg. 攻击者使用一个透明的、不可见的iframe覆盖在一个网页上诱导用户在该页面上进行操作
点击劫持利用的是与用户产生交互的页面，而CSRF是另外的页面
劫持类型
iframe点击劫持
控制iframe的长、宽以及调整top，left的位置，将iframe页面内的任何部分覆盖到任何地方
同时设置iframe的position为absolute，并将z-index的值设置为最大=>让ifame处于页面最上层
通过设置opacity来控制iframe的透明程度，值为0是完全不可见的
Flash点击劫持
目前Adobe公司已经修复了此漏洞
图片覆盖攻击
利用图片的style或控制css，使图片覆盖到页面上的任意位置形成点击劫持
拖拽劫持与数据窃取
诱导用户从隐藏的不可见iframe中“拖拽”出攻击者希望得到的数据
然后放到攻击者能够控制的另外一个页面中从而窃取数据
触屏劫持
针对触屏操作捕捉手机OS事件，将一个不可见的iframe覆盖到当前网页上来劫持用户的触屏操作
防范措施
frame busting
通过写JS代码来禁止iframe的嵌套
控制能力并不强，有许多方法可以绕过它
X-Frame-Options
在HTTP Header中增加X-Frame-Options选项
DENY
SAMEORIGN
ALLOW-FROM origin
HTML5安全
新标签的XSS
<video>, <audio>等
需要加入XSS Filter黑名单避免发生XSS
iframe的新属性sandbox
新特性
<iframe>加载的内容会被视为一个独立的“源”，其中脚本将被禁止执行
options
allow-same-origin：允许同源访问
allow-top-navigation：允许访问顶层窗口
allow-forms：允许提交表单
allow-scripts：允许执行脚本
Link Types：noreferer
为<a>和<area>定义了新的Link Types: noreferer
浏览器在请求该标签指定的地址时将不再发送Referer
Canvas
可以让JS在页面中直接操作图片对象，也可以直接操作像素，构造出图片区域
其强大的功能甚至可以用来破解验证码，大大降低了攻击的门槛
其他安全问题
Cross-Origin Resource Sharing
尽量不使用通配符"*"，使用更多HTTP Header做更精确的控制
postMessage - 跨窗口传递消息
postMessage允许每一个window对象向其他窗口发送文本消息不受同源策略限制
可能会导致DOM based XSS的产生
Web Storage
Storage类型
Session Storage
Local Storage
安全隐患
攻击者可能会将恶意代码保存在Web Storage中，从而实现跨页面攻击
服务端应用安全
注入攻击
注入攻击类型
SQL注入
恶意查询语句注入
盲注（Blind Injection）
构造简单的条件语句，根据返回页面是否发生变化，来判断SQL语句是否得到执行
Timing Attack
MySQL中有一个BENCHMARK()函数可以让同一个函数执行若干次
通过检查函数结果返回时间长短的变化来判断出注入语句是否执行成功
数据库攻击
SQL注入
防御SQL注入
使用预编译语句，绑定变量（参数化）
使用存储过程（不推荐使用存储过程，不利于维护）
检查数据类型（必须严格参照类型来匹配）
使用安全函数（充分借助各种Web语言提供的编码函数对抗SQL注入）
使用最小权限原则（避免Web应用直接使用root, dbowner等高权限账户连接DB）
命令执行
利用“用户自定义函数”即UDF来执行命令
攻击存储过程
利用存储过程执行系统命令
编码问题
尽量统一数据库、操作系统、Web应用所使用的字符集
其他注入攻击
XML注入
需要对用户输入数据中包含的“语言本身的保留字符”进行转义
代码注入
多见于脚本语言中，需要避免使用危险函数
CRLF注入
CRLF是两个字符：CR（\r）和LF（\n），注入CRLF字符可能会改变原有语义
多用于日志注入、HTTP头注入
需要在使用换行符作为分隔符的应用中处理好"\r","\n"两个保留字符
重要原则
“数据与代码相分离”，在“拼凑”发生的地方进行安全检查
文件上传漏洞
基本概念
用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力
基于富文本编辑器的漏洞
攻击者可以手动修改上传过程的POST包绕过文件上传检查功能
eg. 0x00字符截断的问题
基于Web Server的漏洞
Apache文件解析问题
老版本是从文件名的后方向前方解析，匹配mime.types名单
IIS文件解析问题
老版本存在文件名截断问题
建议取消“脚本资源访问”复选框
利用文件上传钓鱼
老版本IE会将钓鱼图片当做HTML执行
设计安全的文件上传
文件上传的目录设置为不可执行
判断文件类型
对于文件类型检查推荐使用白名单的方式
对于图片采用压缩函数或者resize函数处理可能包含的HTML代码
使用随机数改写文件名和文件路径
极大增加攻击的成本
单独设置文件服务器的域名
浏览器同源策略会导致客户端攻击失效
认证与会话管理
密码安全
长度与复杂度要求
OWASP推荐的一些最佳实践
密码的保存
必须以不可逆的加密算法/单向散列函数算法加密后存在数据库中
计算哈希值时增加一个Salt增加明文的复杂度
多因素认证
密码与多种手段结合（手机动态口令、数字证书、支付盾、第三方证书等），保证用户账户安全
Session与认证
生成SessionID时需要保证足够的随机性（使用足够强的伪随机数生成算法）
Session Fixation攻击
在登录完成后，重写SessionID
需要增加或改变用于认证的Cookie值
Session保持攻击
一定时间后强制销毁Session => 可能会影响一些正常的用户
当用户客户端发生变化时（IP、UserAgent等信息变化了）要求其重新登录
单点登录（SSO）
单点登录有利有弊，风险集中，一旦攻破后果严重！
访问控制
垂直权限管理
基于角色的访问控制（RBAC）
用户-角色-权限
应当使用“最小权限原则”+“默认拒绝”的策略
只在有需要的主体单独配置“允许”的策略
水平权限管理
基于数据的访问控制，缺乏数据级访问控制
OAuth
目前OAuth2.0是广为采用的授权协议标准
加密算法与随机数
密钥管理
不要把密钥硬编码在代码里，而应该存储在配置文件或数据库中，按需读取
伪随机数
不要将时间函数作为随机数使用
在重要系统中一定要使用足够强壮的随机数生成算法
Web框架安全
模板引擎与XSS防御
启用HtmlEncode
对不同场景实现自定义的编码函数
Web框架与CSRF防御
在Session中绑定Token
在form表单中自动填入Token字段
在Ajax请求中自动添加Token
在服务器端对比POST提交参数的Token与Session中绑定的Token是否一致
Http Headers管理
在Web框架中对Http头进行全局化处理，保障基于Http头的安全方案
数据持久层与SQL注入
使用ORM对抗SQL注入
Web框架自身的漏洞
eg. Structs2, Spring MVC 3 ...
应用层DDOS攻击
DDOS概念
利用合理请求导致资源过载造成服务不可用
常见DDOS攻击
SYN flood, UDP flood, ICMP flood
CC攻击
对一些消耗资源较大的应用页面不断发起正常请求以消耗服务端资源
应用层DDOS
限流（Rate Limit）
对每个“客户端”做一个请求频率的限制
常见解决方法
应用代码性能优化
合理利用memcache等分布式缓存转移数据库压力
及时释放资源，减少空连接消耗
网络架构优化
善于利用负载均衡分流避免单点问题
充分利用CDN和镜像站点分流缓解主站压力
实现对抗手段
限制每个IP的请求频率
高级的验证码
核心思想
DDOS本质是对有限资源的无限制滥用
解决核心思路是限制每个不可信任的资源使用者的配额
安全运营体系
安全开发流程（SDL）
参考：微软SDL过程（16个阶段）
敏捷SDL
与项目经理充分沟通，排出足够的时间做安全评估
规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏
树立安全部门的权威，项目必须由安全部门审核完成后才能发布
将技术方案写入开发、测试的工作手册中
强化代码规范，使用安全功能
给工程师培训安全方案
记录所有的安全Bug，激励程序员写出安全的代码
安全测试
自动化测试
通过Web安全扫描系统进行漏洞扫描
手动测试
自动化的扫描报告需要结合手动测试结果，最终形成一份安全测试报告
及时修复安全测试报告中提到的问题，再迭代进行安全测试以验证漏洞的修补情况
重要结论
SDL需要从上往下推动，归根到底仍然是“人”的问题
实施SDL一定要得到技术负责人和产品负责人的权利支持，完善软件发布流程
安全运营
漏洞修补流程
建立完善的BugTracker漏洞追踪机制，并为漏洞的紧急程度选择优先级
建立漏洞分析机制，并与开发一起制定修补方案，同时Review补丁的代码实现
对曾经出现的漏洞进行归档，并定期统计漏洞修补情况
安全监控
主要目的是为了探测网站或网站的用户是否被攻击，是否发生了DDOS，从而可以做出反应
入侵检测
物理上主要部署入侵检测产品
应用中实现代码级的安全监控功能
eg. 记录安全日志汇总酌情发出安全警报
紧急响应流程
为了在最快时间内做出反应，须建立完善的报警机制
邮件报警
IM报警
短信报警
注意事项
保护安全事件的现场
确保准确的后续分析入侵行为及定损
以最快速度处理完问题
最短时间内找到对应的人并制定出相应的计划
重要结论
安全运营实施的好坏，将决定公司安全是否能健康地发展
