1550148500(1).jpg

第1章 我的安全世界观

==互联网本来是安全的，因为有了研究安全的人所以才会不安全。==

Web安全简史

• “黑客”渴望root权限
• 黑客们使用的漏洞利用代码被称为”exploit“
• 黑客的发展分为：启蒙时代、黄金时代、黑暗时代

黑帽子，白帽子

• 黑帽子指利用黑客技术造成破坏，甚至进行网络犯罪的群体
• 白帽子指精通安全技术，但是工作在反黑客领域的专家们

安全的本质

• 安全问题的本质是信任的问题
• 安全是一个持续的过程

安全三要素

• 机密性、完整性、可用性

如何实施安全评估

• 评估4个阶段：资产等级划分、威胁分析、风险分析、确认解决方案
• 优秀的安全方案应具备的特点：
  • 能够有效的解决问题
  • 用户体验好
  • 高性能
  • 低耦合
  • 易于扩展和升级

白帽子兵法

• Secure by default、最小权限、纵深防御、数据代码分离、不可预测性 五大原则

第2章 浏览器安全

同源策略

• 同源策略是浏览器最核心也是最基本的安全功能

浏览器沙箱

• 挂马：指利用浏览器漏洞执行任意代码的攻击方式。
• sandbox即沙箱，让不可信任代码运行在一定环境中，限制访问隔离区之外的资源

恶意网址拦截

• 工作原理：就是浏览器维护一个恶意网址的黑名单，如果用户访问在黑名单上的网址，就会弹出一个警告页面。
• 分类：一类是挂马网站，是指利用浏览器漏洞来执行恶意代码，另一类是钓鱼网站，是指模仿知名网站的相似页面来欺骗用户。

第3章 跨站脚本攻击（XSS）

XSS简介

• 概念：黑客通过“HTML注入”篡改网页，插入恶意脚本，从而在用户浏览网页时，控制用户浏览器。
• 根据效果分类：
  • 反射型XSS：简单地把用户输入的数据反射给浏览器。
  • 存储型XSS：会把用户输入的数据存储在服务器端，这种XSS具有稳定性。

XSS攻击进阶

• XSS Payload 是指攻击成功后执行的恶意脚本
• XSS可以实现哪些事
  • 常见的XSS Payload就是“cookie劫持”
  • Cookie的“HttpOnly”标识可以防止“cookie劫持”
  • 构造get与post请求
  • XSS钓鱼
  • 识别用户浏览器：userAgent，通过分析浏览器特性来区分
  • 识别用户安装的软件
  • CSS History Hack：通过css可以发现用户曾经访问过的网站
  • 获取用户的真实ip
• XSS攻击平台：Attack API；BeEf；XSS-Proxy
• XSS构造技巧：
  • 利用字符编码
  • 绕过长度限制
  • 使用<Base>标签
  • Window.name:可以实现跨域，跨页面传递数据
• Xss防御
  • HttpOnly: set-cookie标记httpOnly属性，解决cookie劫持
  • 输入检查：普遍做法是同时在客户端和服务端代码中实现相同的检查
    • 过滤和转义特殊字符或匹配Xss特征的敏感字符如“<script>”等
    • 输入检查的方式被成为“XSS Filter”，已经有很多开源的实现
    • Xss Filter可能会改变用户数据的语义
  • 输出检查：编码，转义
  • 正确地防御XSS
    • Xss的本质是一种“HTML注入”

第4章 跨站点请求伪造（CSRF）

CSRF简介

• 与XSS不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站

CSRF进阶

• 浏览器cookie：一种是Session Cookie，没有指定expire，浏览器关闭，cookie就失效，另一种是Third-party-Cookie，又称为本地cookie，只有expire时间到了后才会失效。
• 默认会拦截本地cookie的有：IE6，7，8，Safari
• 如果当前浏览器会拦截本地cookie，那就需要攻击者构造攻击环境，诱使用户在浏览器中先访问目标站点，使session cookie生效，再进行CSRF攻击
• 如果CSRF要攻击的目标不需要使用Cookie，那就不用考虑浏览器的cookie策略了
• sessioncookie是保存在浏览器进程中的而Third-party-Cookie是保存在本地的
• 如果网站返回给浏览器的HTTP头中携带有P3P头，将允许浏览器发送第三方Cookie，即使在ie下也不会拦截。但是由于cookie是以域和path为单位的，p3p头的设置会影响整个域的所有页面。
• 对于CSRF的防御不能依赖浏览器的cookie拦截策略
• 不仅是get，CSRF也可以发起post请求
• CSRF本质
  • 所有重要的参数都能被攻击者猜测到，所有参数和值都能猜到就可以构造伪造的请求
• CSRF防御：
  • 验证码：最简洁有效的防御手段，但是用户体验差。
  • Referer Check：也可以被用于检查请求是否来自合法的源，但是服务器端并不是任何时候都可以获取到Referer，所以不能作为主要防御手段。
  • Anti Csrf token：使用token是业界一致的做法，token的生成需要具有随机性和保密性
  • 如果网站存在XSS漏洞，那么token防御Csrf也就没用了

第5章 点击劫持（ClickJacking）

点击劫持简介

点击劫持是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

点击劫持攻击方式

• Flash点击劫持
• 图片覆盖攻击：劫持攻击的本质是视觉欺骗，所以图片覆盖也能起到类似作用
• 拖曳劫持与数据窃取：拖曳劫持的思路是诱使用户从隐藏的iframe中拖曳出攻击者希望得到的数据，然后放到攻击者能控制的另外一个页面中，从而窃取数据。
• 触屏劫持

点击劫持防御

• 一般通过禁止跨域的iframe来防范：frame busting，X-Frame-Options

第6章 HTML5 安全

• HTML5新标签的XSS：可能带来新的XSS攻击。

第7章 注入攻击

• 注入攻击的本质是把用户输入的数据当作代码执行。
• 两个关键条件：第一个是用户能够控制输入，第二个是原本程序要执行的代码，拼接了用户输入的数据。

SQL注入

• 发现漏洞方式
  • 攻击者通过web服务器的错误回显构造sql注入语句
  • 没有错误回显一样可以实现注入，就是所谓的盲注，是通过简单的条件判断对比返回结果来发现漏洞。
• 常见数据库攻击方式
  • sqlmap.py：自动化注入工具
  • 自定义函数
  • 存储过程
  • 编码问题：“基于字符集”注入
  • SQL Column Truncation
• sql注入的防御
  • 建立数据库账号时要遵循“最小权限”原则，每个应用分配不同的账号，且账号不应该具有创建自定义函数和操作本地文件的权限
  • 使用预编译语句：这是防御sql注入的最佳方式，攻击者无法改变sql语句的结构
  • 使用存储过程：但是存储过程也存在注入风险，所以应避免在存储过程中使用动态语句
  • 检查数据类型：比如限制输入为Intger类型，比如限制输入为日期格式等
  • 使用安全函数

其他注入攻击

除了sql注入外，在web安全领域还有其他注入攻击，这些注入攻击都有相同的特点，就是应用违背了“数据与代码分离”原则。

• XML注入
• 代码注入
• CRLF注入

总结

==在“拼凑”发生的地方进行安全检查，就能避免注入攻击==

第8章 文件上传漏洞

文件上传漏洞简介

• 文件上传漏洞：用户上传了一个可执行的脚本文件并通过此脚本获得了执行服务器端命令的能力。这种方式非常有效且没有什么技术门槛
• 导致的安全问题：
  • 上传web脚本语言，服务器的web容器解释并执行了脚本
  • 上传flash策略文件
  • 上传文件是病毒，木马，黑客诱骗用户或管理员下载执行
  • 上传的是钓鱼图片或包含了脚本的图片，某些版本的浏览器会作为脚本执行
• 完成攻击需要满足的条件
  • 文件能被web容器解释执行：上传的路径需要被web容器所覆盖
  • 用户能够从web上访问这个文件
  • 文件不能被安全检查，格式化等方式改变内容
• 防御文件上传漏洞：
  • 文件上次的目录设置为不可执行
  • 判断文件类型：MIME TYPE、后缀检查。推荐使用白名单的方式，黑名单方式是不可靠的
  • 对于图片的处理，可以使用压缩函数或者resize函数，破坏图片中可能包含的代码
  • 使用随机数改写文件名和文件路径
  • 单独设置文件服务器的域名

第9章 认证与会话管理

认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能做什么。

• 黑客们广泛使用的一种破解MD5加密的方法是“彩虹表（Rainbow Table）”，可以通过加salt的方式使彩虹表攻击失效
• 多因素认证，比如网上支付平台的数字证书，动态口令等
• session劫持是指通过窃取用户的SessionId后，使用该SessionId登录进用户账户的攻击方式
• session Fixation 攻击
  • 概念：比如A把汽车卖给B，但没把所有的钥匙给B。B如果没换锁就导致了session fixation问题
  • 解决方法：登录完成后，重写SessionId
• session 保持攻击
  -session一般是由周期的，但是如果session一直不失效就会出现session保持攻击
  -解决方法：
  - 强制销毁session
  - 一个用户只能拥有一个session
  - 当客户端发生变化时，要求用户重新登录

第10章 访问控制

• 分类：
  • 垂直权限管理：基于角色的权限管理（RABC模型）
    • 在配置权限时用遵循“最小权限原则”，并使用“默认拒绝”的策略，只对需要的主体单独配置“允许”的策略
  • 水平权限管理：基于数据的访问控制

第11章 加密算法与随机数

• 分类
  • 唯密文攻击
  • 已知明文攻击
  • 选择明文攻击
  • 选择密文攻击
• 原则：密码系统的安全性应该依赖于密钥的复杂性，而不应该依赖于算法的保密性

第12章 Web框架安全

• MVC框架数据流向：view层，controller层，model层，数据的流出则是反过来
• MVC框架防御XSS攻击在view层
• Mvc框架防御SQL注入攻击在model层
• Mvc框架防御CSRF攻击：通过添加security token

第13章 应用层拒绝服务攻击

• DDOS简介:

DDOS又称为分布式拒绝服务，是指利用合理的请求造成资源过载，导致服务不可用。

• 应用层DDOS攻击：所有ip地址都是真实的，针对服务器性能的攻击。
  • cc攻击：原理就是对一些消耗资源较大的应用页面不断发起正常的请求，以达到消耗服务端资源的目的
    • 防御：
      1. 限制请求频率：最常见的措施
      2. 应用层代码优化
      3. 网络架构优化，负载均衡，CDN和镜像站点分流
      4. 限制ip请求频率
      5. 验证码
  • 资源耗尽攻击：攻击者利用web sever的漏洞或设计缺陷，直接造成拒绝服务的攻击
    • slowloris攻击：以极低的速度向服务器发送HTTP请求，占用连接。
    • HTTP POST DOS：指定非常大的Content-length值，然后以很低的速度发包
    • Server Limit DOS：由cookie造成的一种拒绝服务，通过XSS攻击将cookie值设置为超长，由于Web Server对HTTP头有长度限制，导致请求不成功。
    • ReDOS，由正则表达式造成的DDOS

第14章 PHP安全

• 文件包含漏洞：代码注入的一种
• 变量覆盖漏洞
• 代码执行漏洞

第15章 Web Server配置安全

Web服务器安全考虑的是应用部署时的运行环境安全，包括Web Server、脚本语言解释器、中间件等软件，这些软件提供的一些配置参数，起到安全保护作用。

• 关注点：一是web server本身是否安全 二是是否提供了可使用了安全功能
• 应该用专门的用户身份运行web server，这个用户不应该具备shell权限，它的唯一作用是来运行web应用。
• web server如apache提供了一些配置参数，可以用来优化服务器性能，从而提高对抗DDOS的攻击能力。
• log要保存好，甚至可以实时的发送到远程服务器做备份

第16章 互联网业务安全

• 一般来说，安全是产品的一个特性，安全本身可视为产品的一个组成部分
• 一个安全方案至少还需要具备的条件：良好的用户体验，优秀的性能
• “威胁分析”是设计安全方案的基础

第17章 安全开发流程（SDL）

• 安全的开发流程，能够帮助企业以最小的成本提高产品的安全性
• SDL简介：由微软提出，通过对软件工程的控制，保证产品的安全
• SDL分为16个阶段：
  1. 培训：开发团队所有成员都必须进行适当的培训，了解安全知识
  2. 安全要求：项目确立之前就要知道安全的要求
  3. 质量门/bug栏：在项目开始时定义的标准，用于确定安全和隐私质量的最低可接受级别
  4. 安全和隐私风险评估：对功能进行安全风险评估（SRA）和隐私风险评估(PRA)
  5. 设计要求: 设计阶段仔细考虑安全需求
  6. 减小攻击面：如关闭或限制对系统服务的访问
  7. 威胁建模：为项目面临的威胁建立模型，可参考微软提出的STRIDE模型
  8. 使用特定工具：规定开发团队使用的工具版本
  9. 弃用不安全函数：使用安全团队推荐的函数
  10. 静态分析：由相关辅助工具完成代码静态分析，其结果与人工分析结合
  11. 动态程序分析：用于测试环节验证程序的安全性
  12. 模糊测试（Fuzzing Test）：通过故意引入不良代码和随机数据来诱发程序故障
  13. 威胁模型和攻击面评析：由于项目会经常变更，所以需要重新对威胁模型和攻击面进行评析
  14. 事件响应计划：每个软件在发布时都必须包含事件响应计划
  15. 最终安全评析（FSR）：发布之前仔细检查所有软件执行的安全活动
  16. 发布、存档
• SDL适用于瀑布法进行开发的软件团队，对于敏捷开发团队，则难以适应
• 敏捷的SDL就是以变化的观点来实施安全工作，在每个阶段都要更新威胁模型和隐私策略
• SDL实战准则
  1. 与项目经理进行充分沟通，排出足够时间。
  2. 规范公司的立项流程，确保所有项目都能通知到安全团队。
  3. 树立安全部门的权威，项目必须由安全部门审核后才能发布。
  4. 将技术方案写入开发、测试的工作手册中。
  5. 给工程师培训安全方案。
  6. 记录所有的安全bug，激励程序员编写安全的代码。
• 可以通过“web安全扫描器”对项目或产品进行漏洞扫描

第18章 安全运营

• 互联网公司如何规划安全蓝图：find and fix，defend and defer，secure at the source