白帽子讲WEB安全

读<白帽子讲WEB安全>摘要

我的安全世界观

安全三要素-CIA

1. 机密性 Confidentiality

   • 数据不被泄漏
     • 加密

2. 完整性 Integrity

   • 保护数据内容完整的、没有被篡改
     • 数字签名

3. 可用性 Availability

   • DOS-Denial Of Service 攻击会破坏可用性

4. 拓展：可审计性、不可抵赖性

如何实施安全评估

互联网安全的核心问题，是数据安全的问题。

1. 资产等级划分

   1. 了解公司最重要的资产是什么，他们最看重的数据是什么 。通过访谈的形式，安全 部门才能熟悉、了解公司的业务，公司所拥有的数据，以及不同数据的重要程度，为后续的安 全评估过程指明方向
   2. 信 任域和信任边界,网络逻辑上来划分。比如最重 要的数据放在数据库里，那么把数据库的服务器圈起来； Web 应用可以从数据库中读/写数据， 并对外提供服务，那再把 Web 服务器圈起来；最外面是不可信任的 Internet

2. 威胁分析

   危害的来源称为威胁（Threat）

   可能会出现的损失称为风险（Risk）

   1. 威胁建模

      什么是威胁分析？威胁分析就是把所有的威胁都找出来。怎么找？一般是采用头脑风暴 法。当然，也有一些比较科学的方法，比如使用一个模型，帮助我们去想，在哪些方面有可能 会存在威胁，这个过程能够避免遗漏，这就是威胁建模。

      • STRIDE 模型

        威 胁	定 义	对应的安全属性
        Spoofing（伪装）	冒充他人身份	认证
        Tampering（篡改）	修改数据或代码	完整性
        Repudiation（抵赖）	否认做过的事情	不可抵赖性
        InformationDisclosure（信息泄露）	机密信息泄露	机密性
        Denial of Service（拒绝服务）	拒绝服务	可用性
        Elevation of Privilege（提升权限）	未经授权获得许可	授权

3. 风险分析

   我们判断风险高低的过程，就是风险分析的过程 .

   风险由以下因素组成：

   Risk = Probability * Damage Potential

   • DREAD 模型

     等 级	高(3)	中(2)	低(1)
     Damage Potential	获取完全验证权限；执行管理员操 作；非法上传文件	泄露敏感信息	泄露其他信息
     Reproducibility	攻击者可以随意再次攻击	攻击者可以重复攻击，但有时间 限制	攻击者很难重复攻击 过程
     Exploitability	初学者在短期内能掌握攻击方法	熟练的攻击者才能完成这次攻击	漏洞利用条件非常苛刻
     Affected users	所有用户，默认配置，关键用户	部分用户，非默认配置	极少数用户，匿名用户
     Discoverability	漏洞很显眼，攻击条件很容易获得	在私有区域，部分人能看到，需 要深入挖掘漏洞	发现该漏洞极其困难

4. 确认解决方案

   1. 安全评估的产出物，就是安全解决方案 。

   2. 设计解决方案不难，难的是如何设计一个好的解决方案。设计一个好的解决方案，是真正 考验安全工程师水平的时候。 很多人认为，安全和业务是冲突的，因为往往为了安全，要牺牲业务的一些易用性或者性 能，笔者不太赞同这种观点。从产品的角度来说，安全也应该是产品的一种属性。一个从未考 虑过安全的产品，至少是不完整的。

   3. 没有不安全的业务，只有不安全 的实现方式。

   4. 安全方 案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。

   5. ，一个优秀的安全方案应该具备以下特点：

      1. 能够有效解决问题；
      2. 用户体验好；
      3. 高性能；
      4. 低耦合；
      5. 易于扩展与升级

   白帽子兵法

   1. Secure By Default 原则 ，也可以归纳为白名单、黑名单的思想

      1. 黑名单、白名单
      2. 最小权限原则

   2. 纵深防御原则

      不同的层面、不同的角度对系 统做出整体的解决方案。

      我们常常听到“木桶理论”这个词，说的是一个桶能装多少水，不是 取决于最长的那块板，而是取决于最短的那块板，也就是短板。设计安全方案时最怕出现短板， 第 1 章 我的安全世界观 19 木桶的一块块板子，就是各种具有不同作用的安全方案，这些板子要紧密地结合在一起，才能 组成一个不漏水的木桶。

      在常见的入侵案例中，大多数是利用 Web 应用的漏洞，攻击者先获得一个低权限的 webshell， 然后通过低权限的 webshell 上传更多的文件，并尝试执行更高权限的系统命令，尝试在服务器上 提升权限为 root；接下来攻击者再进一步尝试渗透内网，比如数据库服务器所在的网段。

      Web 应用 安全、 OS 系统安全、数据库安全、网络环境安全等。在这些不同层面设计的安全方案，将共 同组成整个防御体系，这也就是纵深防御的思想。

      纵深防御的第二层含义，是要在正确的地方做正确的事情。 如何理解呢？它要求我们深入 理解威胁的本质，从而做出正确的应对措施。

   3. 数据与代码分离原则

      这一原则广泛适用于各种由于“注入”而 引发安全问题的场景。

      实际上，缓冲区溢出，也可以认为是程序违背了这一原则的后果——程序在栈或者堆中， 将用户数据当做代码执行，混淆了代码与数据的边界，从而导致安全问题的发生。

      在 Web 安全中，由“注入”引起的问题比比皆是，如 XSS、 SQL Injection、 CRLF Injection、 X-Path Injection 等。此类问题均可以根据“数据与代码分离原则”设计出真正安全的解决方案， 因为这个原则抓住了漏洞形成的本质原因。

   4. 不可预测性原则

      不可预测性原则，可以巧妙地用在一些敏感数据上。比如在 CSRF 的防御技术中，通常会 使用一个 token 来进行有效防御。这个 token 能成功防御 CSRF，就是因为攻击者在实施 CSRF 攻击的过程中，是无法提前预知这个 token 值的，因此要求 token 足够复杂时，不能被攻击者 猜测到。

客户端安全

浏览器安全

同源策略

same origin policy 时浏览器也是最核心的功能。如果缺少同源策略，浏览器的正常功能都会受影响。

浏览器只是同源策略的一种实现。

浏览器的同源策略，限制了来自不同源的"document" 或脚本，对当前的“document ”读取或者设置某些属性。

影响源的由 host (域名或ip地址）、子域名、端口、协议。

但浏览器中

XMLHttpRequest受到同源策略的约束，不能跨域访问资源。

随着业务的发展，跨域请求越来越迫切。因此W3C委员会制定了XMLHttpRequest跨域访问的要求，他需要通过目标域返回的HTTP头来授权是否允许跨域访问，因为http头对于javascript来说一般是无法控制的，所以这个方案是可以实施的，这个跨域方案的安全基础:javaScript 无法控制该Http头。如果信任基础被打破。则此方案将不在安全。

对于浏览器来说，处理DOM、cookie、XMLHttpRequest受到同源策略的限制外。浏览器加载的一些第三方插件也有各自的同源策略。最常见的插件有 flash、java applet、silverlight、 google gears等都有自己的控制策略。

浏览器沙箱

采用sandbox技术，让不受信任的脚本允许在一个受限制的环境中，从而可以保证本地桌面系统的安全。

恶意网址拦截

挂马 攻击是在正常的网页中，通过 script 或 iframe 等标签加载恶意的网址。

钓鱼网站、诈骗网站对用户来说也是一种恶意网址。

恶意网址的拦截非常简单，定期从服务器端获取一份最新的恶意网址清单。用户在浏览恶意网站时会弹出警告。

常见的恶意网址分两类：一类是挂马网站、一类是钓鱼网站。

高速发展的浏览器安全

IE 推出Xss filter

firefox 推出的csp

XSS 跨站脚本攻击

XSS简介

XSS = cross site script

XSS 通常指黑客通过 “html注入” 篡改了网页，插入了恶意的脚本。而从在用户浏览网页时，控制用户浏览器的一种攻击。这种攻击的演示案例是跨域的，所以叫跨站脚本，但是发展到今天，是否跨域已经不在重要。

• 反射型XSS

简单的把脚本反射给浏览器，黑客 往往要诱使客户‘"点击"一个恶意链接。才能攻击成功。

• 存储型XSS

把用户输入的数据存储在服务器端，这种XSS具有很强的稳定性。

• DOM Based XSS

通过修改页面的dom节点形成的XSS，称之为DOM based XSS

XSS 攻击进阶

初探XSS Payload

从攻击者的角度来体验下XSS的威力。

XSS攻击成功后，攻击者能够对当前浏览器的页面植入恶意脚本，通过恶意脚本。控制用户的浏览器，用于完成具体功能的恶意脚本。被称之为“xss payload”。

常见的payload就是cookie劫持。

cookie中一般保存了当前用户的登录凭证。如果cookie丢失，往往意味着用户的登录凭证丢失。换句话说，攻击者可以不通过密码，而直接登录进用户的账户。

攻击者获取到用户的cookie后，可以使用此cookie发起攻击。

强大的xss payload

构造GET和POST请求。

一个网站只接受http协议中的get和post请求，对攻击者来说，只通过JavaScript就可以让浏览器发送此请求。

此不需要劫持用户的cookie，只要构造 网站的现有get或post方法。即可控制客户的浏览器。

XSS钓鱼

1. xss的攻击过程都是JavaScript自动进行的，也就是说缺少交互过程。

• 如果在构造post请求是，加上验证码，但也不能彻底防止。

  攻击者：对于验证码可以把验证码图片发送到攻击者后台识别。

• 此外在大多数修改密码的功能会要求输入旧密码。但是这也不能防止xss payload。

  修改密码问题稍微复杂，需要将XSS与"钓鱼"相结合。

  实现思路：使用javascript在当前页面上"画出"一个伪造的登陆框，当用户在登录框输入用户名与密码，将密码发送至黑客的服务器上。

2. 识别用户浏览器

3. 识别用户安装的软件

CSS history hack

利用style的visited属性，如果用户曾经访问过某个链接，那么这个链接的颜色会变的与众不同。

获取用户的真实IP

xss攻击框架 “attack ip” 由可以获取本地api

XSS 攻击平台

• attach api
• BeEF
• XSS-Proxy

终极武器 XSS Worm

一般来说，用户之间发生发生交互行为的页面，如果存在存储型XSS，比较容易发起XSS Worm

调试JavaScript

• firebug
• ie 8 developer tools
• fiddler
• httpwatch

XSS构造技巧

1. 利用字符编码
2. 绕过长度限制。

• 利用事件，加载location.hash的值
• 利用注释，合并2个input标签

3. 使用base标签。 在设计XSS 安全方案时 一定要过滤这个非常危险的标签
4. window.name 的妙用。

window 对象时浏览器窗体

5. 变废为宝 Mission Impossible

• apache expect header xss

• anehta的回旋镖

• flash xss

• JavaScript 开发框架 真的安全么
  dojo
  yui
  jquery

XSS 防御

XSS的本质是HTML注入。将用户的数据当作代码执行。

HttpOnly

解决XSS攻击中的cookie劫持问题。

服务器可以设置多个cookie，可以给制定的cookie设置HttpOnly。

respone.setHeader("Set-Cookie","cookieName=value;Path=/;Domain=domainValue;Max-Age=seconds;HTTPOnly");

输入检查

XSS攻击和Sql Injection。需要对输入进行检查。这种检查被称为“XSS Filter”。

对 script 和 javascript onclick alert 等以下关键字处理。

输出检查

一般来说，除了富文本输出外，在变量输出到HTML页面时，可以使用编码或转义的方式来防御XSS攻击。

1. 安全的编码函数

   编码分为很多种，针对html代码的编码方式是HtmlEncode。HtmlEncode不是专有名字，是一种函数的实现。作用就是将字符转换成HTMLEntries，对应的标准是ISO-8859-1。

   在javascript可以使用JavaScriptEncode。

   & -> &
   > -> >
   < -> <
   " -> "
   ' -> '
   / -> /
   

正确的防御XSS攻击

   1. HTML 标签中输出。`HtmlEncode`解决 。
   2. HTML 属性中输出。`HtmlEncode`解决。
   3. script标签中输出。`javascriptencode`解决
   4. 事件中输出。`javascriptencode`解决。
   5. css标签中输出。`encodeforcss`解决。
   6. 在地址中输出。`URLEncode`解决。

处理富文本

1. 过滤富文本，比较危险的标签，比如