读书笔记——吴翰清《白帽子讲Web安全》

目录

第一篇 世界观安全

一 个人安全世界观

第二篇 客户端脚本安全

一 浏览器安全
二 跨站脚本攻击（XSS）
三 跨站点请求伪造（CSRF）
四 点击劫持（ClickJacking）
五 HTML5 安全

第三篇 服务端应用安全

一 注入攻击
二 文件上传漏洞
三 认证与会话管理
四 访问控制
五 加密算法与随机数
六 Web框架安全
七 应用层拒绝服务攻击
八 PHP安全
九 Web Server配置安全

第四篇 互联网公司安全运营 

一 互联网业务安全
二 安全开发流程（SDL）
三 安全运营

 

第一篇 世界观安全

一 个人安全世界观

1.安全问题的本质是信任的问题。

2.安全是一个持续的过程。

3.安全三要素：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability），简称CIA。

• 机密性要求保护数据内容不能泄露，加密是实现机密性要求的常见手段。
• 完整性要求保护数据内容是完整的，没有被篡改的。
• 可用性要求保护资源是“随需而得”。
• 扩展：可审计性，不可抵赖性。

4.如何实施安全评估？4个阶段：资产等级划分-->威胁分析-->风险分析-->确认解决方案。

（1）资产等级划分

• 互联网安全的核心问题，是数据安全的问题。因此，对互联网公司的资产等级划分，就是对数据作等级划分，而后要划分信任域和信任边界。

（2）威胁分析

• 威胁分析就是把全部的威胁都找出来。
• 通常采用头脑风暴法和威胁建模法（好比微软提出的STRIDE模型）。
• 漏洞的定义：系统中可能被威胁利用以形成危害的地方。

（3）风险分析

• 风险由如下因素组成：Risk（风险）=Probability（发生的可能性）*Damage Potential（损失的大小）
• 一种科学衡量风险的方法：微软提出的DREAD模型。
• 注意：模型是死的，人是活的。模型只能起到辅助做用，人要灵活运用。

（4）设计安全方案

• 一个优秀的安全方案应该具有如下特色：

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

5.安全方案设计技巧

（1）Secure By Default原则

• 黑名单、白名单原则（尽量使用白名单，不用或者少用黑名单）
• 最小权限原则（要求系统只授予主体必要的权限，而不要过分受权）

（2）Defence In Depth（纵深防护）原则

• 纵深防护包含2层含义：首先，要在各个不一样层面、不一样方面实施安全方案，避免出现疏漏，不一样安全方案之间须要相互配合，构成一个总体；其次，要在正确的地方作正确的事情。即：在解决根本问题的地方实施针对性的安全方案。

（3）数据与代码分离原则

（4）不可预测性原则

• 不可预测性原则可以有效地对抗基于篡改、伪造的攻击。

第二篇 客户端脚本安全

一 浏览器安全

1.同源策略（Same Origin Policy）

• 同源策略是一种约定，它是浏览器最核心也最基本的安全功能。
• 浏览器的同源策略，限制了来自不一样源的“document”或脚本，对当前“document”读取或者设置某些属性。
• 影响“源”的因素有：host、子域名、端口、协议。
• 在浏览器中，<script>、<img>、<iframe>、<link>等标签均可以跨域加载资源，而不受同源策略的限制。
• 对于浏览器来讲，除了DOM、Cookie、XMLHttpRequest会受到同源策略的限制外，浏览器加载的一些第三方插件也有各自的同源策略。最多见的一些插件如Flash、Java Applet、Silverlight、Google Gears等都有本身的控制策略。

2.浏览器沙箱

• 挂马：在网页中插入一段恶意代码，利用浏览器漏洞执行任意代码的攻击方式。
• 浏览器的多进程架构，将浏览器的各个功能模块分开，各个浏览器实例分开，当一个进程崩溃时，也不会影响到其余的进程。
• SandBox即沙箱，泛指“资源隔离类模块”，设计目的是为了 让不可信任的代码运行在必定的环境中，限制不可信任的代码访问隔离区以外的资源。

3.恶意网址拦截

• 工做原理：浏览器周期性地从服务端获取一份最新的恶意网址黑名单，若是用户上网时访问的网址存在于此黑名单中，浏览器就会弹出一个警告页面。
• 常见的恶意网址分为2类：挂马网站&钓鱼网站。
• 除了恶意网址黑名单拦截功能外，主流浏览器都开始支持EV SSL证书，以加强对安全网站的识别。

4.高速发展的浏览器安全

• 微软在IE8推出来XSS Filter功能，用以对抗反射型XSS。
• FireFox在FireFox4推出来Centent Security Policy（CSP），但并未获得推广。
• 浏览器加载的插件也是浏览器安全须要考虑的一个问题。

二 跨站脚本攻击（XSS）

1.XSS简介

• 跨站脚本攻击，英文全称Cross Site Script，简称XSS。
• XSS攻击，一般指黑客经过“HTML注入”篡改了页面，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
• XSS分类：反射型XSS（也叫非持久型XSS）、存储型XSS（也叫持久型XSS）、DOM Based XSS。

2.XSS攻击进阶

2.1 XSS Payload 

• XSS Payload就是XSS攻击成功后，攻击者对用户当前浏览的页面植入的可以完成具体功能的一些恶意脚本。
  • （1）Cookie劫持——一个最多见的XSS Payload就是经过读取浏览器的cookie对象，从而发起“Cookie劫持”攻击，直接登陆进用户的帐户。Cookie的“HttpOnly”标识或者把cookie与客户端IP绑定能够防止“Cookie劫持”。
  • （2）构造GET、POST请求
  • （3）XSS钓鱼——举例：利用JavaScript在当前页面上“画出”一个伪造的登陆框，当用户在登陆框中输入用户名与密码后，其密码将被发送到黑客的服务器上。
  • （4）识别用户浏览器——如何经过JS脚本识别浏览器版本？1经过XSS读取浏览器的UserAgent对象，存在误报问题；2根据各个浏览器之间存在的实现差别——不一样的浏览器会各自实现一些独特的功能，从而写代码识别出不一样的浏览器。
  • （5）识别用户安装的软件——举例：IE中，能够经过判断ActiveX控件的某个classid是否存在，来推测用户是否安装了该软件。FireFox的插件列表存放在一个DOM对象中，经过查询DOM能够遍历出全部的插件。Chrome中，经过检测扩展的图标，来判断某个特定的扩展是否存在。
  • （6）CSS History Hack——CSS History Hack就是经过CSS，来发现一个用户曾经访问过的网站。其原理就是利用style的visited属性——若是用户曾经访问过某个连接，那么这个连接的颜色会变得不同凡响。
  • （7）获取用户的真实IP地址

2.2 XSS攻击平台有：Attack API、BeEF、XSS-Proxy等。

2.3 终极武器：XSS Worm(蠕虫)

• 发起XSS Worm攻击的条件：通常来讲，用户之间发生交互行为的页面，若是存在存储型XSS，则比较容易发起XSS Worm攻击。
• 好比发送站内信、用户留言等页面，都是XSS Worm的高发区。
• 举例：Samy Worm（具备里程碑意义的第一个XSS Worm）、百度空间蠕虫等。

2.4 常见的调试JavaScript的工具：Firebug、IE开发者工具、Fiddler、HttpWatch等。

2.5 常见XSS构造技巧

• （1）利用字符编码
• （2）绕过长度限制——好比将XSS Payload写到别处，再经过简短的代码加载这段XSS Payload。在某些环境下，也能够利用注释符绕过长度限制。
• （3）使用<base>标签——<base>标签并不经常使用，它的做用是定义页面上的全部使用“相对路径”标签的hosting地址。攻击者若是在页面中插入了<base>标签，就能够经过在远程服务器上伪造图片、连接或脚本，劫持当前页面中的全部使用“相对路径”的标签。
• （4）window.name的妙用——window对象是浏览器的窗体，而并不是document对象，所以不少时候window对象不受同源策略的限制。对当前窗口的window.name赋值，没有特殊字符的限制。举例：利用window.name能够实现数据的跨域传递、缩短XSS Payload的长度等。

2.6 变废为宝：Mission Impossible

• Apache Expect Header XSS漏洞曾经一度被认为是“鸡肋”漏洞，可是后来有人提出了“使用Flash构造请求”的方法，成功地利用了这个漏洞。
• Anehta 的回旋镖的思路以下：若是在B域上存在一个反射型XSS_B，在A域上存在一个存储型XSS_A，当用户访问A域上的XSS_A时，同时嵌入B域上的XSS_B，则能够达到在A域的XSS攻击B域用户的目的。即将要利用的反射型XSS嵌入一个存储型XSS中。这个攻击技巧的缺点是，尽管跳转花费的时间很短，但用户仍是会看到浏览完地址栏的变化。

2.7 容易被忽视的角落：Flash XSS

• 前文讲到的XSS攻击都是基于HTML的，其实在Flash中一样也有可能形成XSS攻击。缘由是在Flash中是能够嵌入ActionScript脚本的。所以应该尽量地禁止用户可以上传或加载自定义的Flash文件。若是必定要使用Flash，则能够经过Flash的配置参数进行限制，若是是视频文件，则要求转码为“flv文件”。

2.8 真的高枕无忧吗？JavaScript开发框架

• 常见的JavaScript框架，Dojo、YUI、jQuery等。
• 使用JavaScript框架并不能让开发者高枕无忧，一样可能存在安全问题。除了须要关注框架自己的安全外，开发者还要提升安全意识，理解并正确地使用开发框架。

3.XSS的防护

3.1 HttpOnly

• 浏览器禁止页面JavaScript访问带有HttpOnly属性的Cookie，从而防止Cookie劫持问题。

3.2 输入检查

• 举例1：输入格式检查：有点像白名单，可让一些基于特殊字符的攻击失效。输入检查逻辑必须放在服务端代码中实现，放在前端易被绕过。
• 举例2：XSS Filter：在用户提交数据时获取变量，并进行XSS检查，但此时用户数据并无结合渲染页面的HTML代码，所以XSS Filter对语境的理解并不完整。

3.3 输出检查

（1）使用安全的编码函数

• HtmlEncode：针对Html代码的编码方式，它的做用是将字符转换成HTMLEntities，对应的标准是ISO-8859-1。HtmlEncode要求至少转换如下字符：（&-->&amp;）（<-->&lt;）（>-->&gt;）（"-->&quot;）（'-->&#x27;）（/&#x2F;）。在OWASP ESAPI中推荐了一种更严格的HtmlEncode——除了字母、数字外，其余全部的特殊字符都被编码成HTMLEntities。
• JavascriptEncode：针对JavaScript的编码方式，使用“\”对特殊字符进行转义，要求输出的变量必须在引号内。还有一个更加严格的函数来保证安全——除了数字、字母外的全部字符，都使用十六进制“\xHH”的方式进行编码。

（2）只需一种编码吗

• XSS攻击主要发生在MVC架构中的View层，大部分的XSS漏洞能够在模板系统中解决。好比Python的2个经常使用的开发框架Django和web2py都选择在View层默认escape全部变量（即HtmlEncode全部变量）以对抗xss，可是并不是在模板引擎中使用了auto-escape就万事大吉了，XSS防护须要区分状况对待。

3.4 正确地防护XSS

• XSS可能发生的场景及对应的防护方法：
• 场景1：在HTML标签中输出 ——>防护方法是使用HtmlEncode。
• 场景2：在HTML属性中输出——>防护方法是使用HtmlEncode。
• 场景3：在<script>标签中输出——>首先确保输出的变量在引号中，防护方法是使用JavascriptEncode。
• 场景4：在事件中输出——>防护方法是使用JavascriptEncode。
• 场景5：在CSS中输出——>通常来讲，要尽量禁止用户可控制的变量在“<style>标签”、“HTML标签的style属性”以及“CSS文件”中输出，若是必定有这样的需求，则推荐使用OWASP ESAPI中的encodeForCSS()函数——除了字母数字外的全部字符都被编码成十六进制形式“\uHH”。
• 场景6：在地址中输出——>若是变量在在URL的路径或者参数中输出，使用URLEncode便可，URLEncode会将字符转换为“%HH”形式，好比空格就是“%20”；若是在URL的协议与host中输出，则不能使用严格URLEncode函数，由于会把“://”、“.”等都编码掉；若是在整个URL中输出，则应该先检查变量是否以“http”开头（若是不是自动添加），以保证不会出现伪协议类的XSS攻击，而后再对变量进行URLEncode。

3.5 处理富文本

• 有些时候，网站须要容许用户提交一些自定义的HTML代码，称之为富文本。
• 在过滤富文本时，请谨记如下几条：
• （1）事件以及一些危险的标签，好比<iframe>、<script>、<base>、<form>等，应该被严格禁止。
• （2）在标签、属性、事件的选择上，应该使用白名单，避免使用黑名单。
• （3）尽量禁止用户自定义CSS与style。若是必定要容许用户自定义样式，则只能像过滤富文本同样过滤CSS，这须要一个CSS Parser对样式进行智能分析，检查其中是否包含危险代码。
• （4）有一些比较成熟的开源项目，好比Anti_Samy、HTMLPurify等，实现了对富文本的XSS检查。

3.6 防护DOM Based XSS

• DOM Based XSS是从JavaScript中输出数据到HTML页面中，须要分语境使用不一样的编码函数。

3.7 从业务风险的角度看XSS的风险

• 存储型XSS的风险高于反射型XSS。由于存储型XSS会保存在服务器上，有可能会跨页面存在，甚至可能绕过一些检测工具。
• 反射型XSS通常须要诱使用户点击一个包含XSS代码的URL连接，而存储型XSS只须要用户查看一个正常的URL连接。这样的漏洞极其隐蔽且埋伏在用户的正常业务中，风险颇高。
• 网站的PageView越高，对应页面受XSS攻击后的影响越大。

4.小结

• 理论上，XSS漏洞虽然复杂，但倒是能够完全解决的。在设计XSS解决方案时，应该深刻理解XSS攻击的原理，针对不一样的场景使用不一样的方法。同时有不少开源项目为咱们提供了参考。

三 跨站点请求伪造（CSRF，Cross Site Request Forgery）

1.CSRF简介

• 攻击者在本身的域构造一个页面，在这个页面上伪造一个请求，而后诱使目标用户访问这个页面，从而以该用户身份在第三方站点里执行了一次操做。这就是“跨站点请求伪造”。
• CSRF为何可以攻击成功？其本质缘由是重要操做的全部参数都是能够被攻击者猜到的。

2.CSRF进阶

2.1 浏览器的Cookie策略

• 浏览器的Cookie分为2种：
• Session Cookie（临时Cookie）：没有指定Expire时间，浏览器一关闭即失效。保存在浏览器进程的内存空间中。
• Third-party Cookie（本地Cookie）：服务器在Set-Cookie时指定了Expire时间，只有到了Expire时间后Cookie才会失效，因此这种Cookie会保存在本地。
• 一些浏览器默认策略是，容许在<img>、<iframe>、<script>、<link>等标签中发送用于认证的第三方Cookie，从而致使CSRF攻击成功。

2.2 P3P头的反作用

• P3P头容许跨域访问隐私数据，从而能够容许浏览器跨域发送第三方Cookie。P3P头只须要由网站设置一次便可，以后每次请求都会遵循此策略。

2.3 GET？POST？

• 由于大多数CSRF攻击发起时，使用的都是<img>、<iframe>、<script>、<link>等带有src属性的标签，而这类标签只可以发起一次GET请求，不能发起POST请求，因此不少开发者就认为只要把重要的操做改为只容许Post请求就能防止CSRF攻击，其实这种观点是错误的。由于对于攻击者来讲，有若干种方法能够构造出一个POST请求。好比在一个页面中构造好一个form表单，而后使用JavaScript自动提交这个表单。

2.4 Flash CSRF

• 在Flash中能够经过URLRequest、getUrl、loadVars等多种方式发起网络请求，包括POST请求。

2.5 CSRF Worm

• 2008年百度的CSRF Worm展现了CSRF的破坏性——即便没有XSS漏洞，仅仅依靠CSRF，也是可以发起大规模蠕虫攻击的。

3. CSRF的防护

3.1 验证码

3.2 Referer Check

• Referer Check经过检查请求是否来自合法的“源”来防护CSRF的攻击。
• 它的缺陷在于，服务器并不是何时都能取到Referer。并且，某些客户端插件容许发送自定义的Referer头。

3.3 Anti CSRF Token（主要手段）

• 因为token足够随机，使攻击者没法再构造出一个完整的URL实施CSRF攻击。
• Token须要同时放在表单和Session中。在提交请求时，服务器只须要验证表单中的Token与用户Session（或Cookie）中的token是否一致，若是一致，则认为是合法的请求，若是不一致，或者有一个为空，则认为请求不合法，可能发生了CSRF攻击。
• Token的使用原则（注意随机性和保密性）
  • （1）Token的生成必定要足够随机，须要使用安全的随机数生成器生成Token。
  • （2）为了使用方便，能够容许在一个用户的有效生命周期内，在token消耗掉前都使用同一个token。若是Token保存在cookie中，为解决多页面共存的问题，能够考虑生成多个有效的token。
  • （3）注意Token的保密性。尽可能把Token放在表单中，把敏感操做由GET改成POST，以form表单（或者AJEX）的形式提交，能够避免Token泄漏。
  • （4）CSRF的Token仅仅用于对抗CSRF攻击，若是网站还同时存在XSS漏洞，这个方案就无效了。由于XSS攻击者能够请求页面后读出页面内容里的Token值，而后再构造一个合法的请求。这个过程能够称之为XSRF。

四 点击劫持（ClickJacking）

1.什么是点击劫持？

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

2.Flash点击劫持

• 举例：攻击者制做了一个Flash游戏，诱使用户来玩这个游戏，在完成一系列复杂的动做后，最终控制了用户电脑的摄像头。

3.图片覆盖攻击（Cross Site Image Overlaying，简称XSIO）

• XSIO攻击原理：经过调整图片的style使得图片可以覆盖在他所指定的任意位置。用户点击此图片的话，会被连接到其余网站。或者不须要点击，图片自己就是一个虚假信息。
• XSIO防护：须要检查用户提交的HTML代码中，<img>标签的style属性是否可能致使浮出。

4.拖拽劫持与数据窃取

• 思路：诱使用户从隐藏的不可见的iframe中“拖拽”出攻击者但愿获得的数据，而后放到攻击者能控制的另一个页面，从而窃取数据。

5.ClickJacking 3.0：触屏劫持（TapJacking）

• 经过将一个不可见的iframe覆盖到当前网页上，能够劫持用户的触屏操做。

6.防护ClickJacking

6.1 使用frame busting方法

• 写一段JavaScript代码，以禁止iframe的嵌套，这种方法叫frame busting。
• frame busting的缺陷是，因为它是用JavaScript写的，控制能力不是特别强，所以有许多方法能够绕过它。

6.2 使用一个HTTP头——X-Frame-Options

• X-Frame-Options有3个可选值：
• 当值为DENY时，浏览器会拒绝当前页面加载任何frame页面；
• 当值为SAMEORIGIN时，frame页面的地址只能为同源域名下的页面；
• 当值为ALLOW_FROM origin时，则能够定义运行frame加载的页面地址。

五 HTML5 安全

1.HTML5新标签

1.1 新标签的XSS

• 好比笔者曾经使用了html5中新增的<video>标签（用于远程加载一段视频）写了一段XSS代码，成功地绕过来百度空间的XSS Filter。

1.2 iframe的sandbox

• HTML5专门为iframe定义了一个新的属性，叫Sandbox。它极大加强了应用使用iframe的安全性。
• 使用sandbox这一属性后，<iframe>标签加载的内容将被视为一个独立的“源”，其中的脚本将被禁止执行，表单被禁止提交，插件被禁止加载，指向其余浏览对象的连接也会被禁止。
• sandbox属性能够经过参数来支持更精确的控制。有如下几个值可选：
  • allow-same-origin：容许同源访问；
  • allow-top-navigation：容许访问顶层窗口；
  • allow-forms：容许提交表单；
  • allow-scripts：容许执行脚本。

1.3 Link Types:noreferrer

• 在HTML5中为<a>标签和<area>标签订义了一个新的Link Types:noreferrer。
• 标签指定了noreferrer后，浏览器在请求该标签指定的地址时将再也不发生Referer。
• 这种设计是为了保护敏感信息和隐私。
• <a href="xxx" rel="noreferrer">test</a>

1.4 Canvas的妙用

• <canvas>标签让JavaScript能够在页面中直接操做图片对象，也能够直接操做像素，构造出图片区域。
• 经过Canvas能够实现自动破解验证码功能，大大下降了攻击的门槛。

2.其余安全问题

2.1 Cross-Origin Resource Sharing

• 浏览器实现的同源策略限制了脚本的跨域请求，而随着跨域请求的需求增多，W3C委员会制定了一个新的标准来解决日益迫切的跨域访问问题。
• 标准叙述以下：假设A网页须要发起一个跨域请求，来请求B网页的数据，则A网页在发起请求时必须带上一个Origin Header以证实本身是一个合法的“源”，若是B网页服务器返回一个HTTP Header——Access-Control-Allow-Origin:http://www.a.com，那么这个来自A网页的跨域请求会被经过。

2.2 postMessage——跨窗口传递消息

• postMessage是HTML5制定的一个新的API，它容许每个window（包括当前窗口、弹出窗口、iframes等）对象往其余的窗口发送文本消息，从而实现跨窗口的消息传递。这个功能是不受同源策略限制的。
• 使用win.postMessage()注意事项：
  • （1）为防止消息来自非法页面，能够在接收窗口验证Domain，甚至验证URL；
  • （2）在接收窗口不该信任接收到的消息，须要对消息进行安全检查；
  • （3）使用postMessage也会使XSS Payload变得更加灵活。

2.3 Web Storage

• Web Storage是HTML5 提出的一个解决在客户端本地存储的功能。
• Web Storage分为Session Storage和Local Storage，Session Storage关闭浏览器就会失效，而Local Storage则会一直存在。Web Storage就像一个非关系型数据库，由Key-Value对组成，能够经过JavaScript对其进行操做。
• 使用方法以下：
  • 设置一个值：window.sessionStorage.setItem(key,value);
  • 读取一个值：window.sessionStorage.getItem(key);
  • 此外，Firefox还单独实现了一个globalStorage：window.globalStorage.namedItem(domain).setItem(key,value);
• Web Storage缺点：
  • 攻击者有可能将恶意代码保存在Web Storage中，从而实现跨页面攻击。
  • 当Web Storage保存有敏感信息时，也有可能成为攻击对象。

第三篇 服务端应用安全

一 注入攻击

• 注入攻击的本质，就是把用户输入的数据当作代码执行。这里有2个关键条件，第一个是用户可以控制输入，第二个是本来程序要执行的代码，拼接了用户输入的数据。注入攻击是应用违背了“数据与代码分离原则”致使的结果。

1.SQL注入

• 若是网站的web服务器开启了错误回显，披露了敏感信息，则会对攻击者构造SQL注入语句提供巨大便利。

1.1 盲注（Blind Injection）

• 盲注就是在服务器没有错误回显时完成的注入攻击。此时攻击者能够构造简单的条件语句，根据返回页面是否发生变化，来判断SQL语句是否获得执行，从而判断出SQL注入漏洞是否存在。

1.2 Timing Attack

• 在mysql中有一个用于测试函数性能的BENCHMATK()函数，它可让同一个函数执行若干次，使得结果返回的时间比平时要长，经过时间长短的变化，能够判断出注入语句是否执行成功。这是一种边信道攻击，这个技巧在盲注中被称为Timing Attack。Timing Attack是盲注的一种高级技巧。在不一样数据库中，都有着相似于BENCHMATK()的函数能够被Timing Attack所利用。

2.数据库攻击技巧

2.1 常见的攻击技巧

• （1）SQL注入能够猜想出数据库的对应版本。
• （2）利用union select能够确认某个表名是否存在，以及列名是否存在。
• （3）进一步能够经过判断字符的范围，一步一步读出某字段的值。
• （4）这个过程很是繁琐，能够使用自动化注入工具sqlmap.py来帮助完成。
• （5）在注入攻击过程当中，经常会用到一些读写文件的技巧。好比mysql中，就能够经过LOAD_FILE()读取系统文件，经过INTO DUMPFILE写入本地文件，经过LOAD DATA INFILE将文件导入建立的表中，最后就能够经过通常的注入技巧直接操做表数据了。因此，在设计数据库安全方案时，能够禁止普通用户具有操做文件的权限。

2.2 命令执行

• 在MySQL中除了能够经过导出webshell间接地执行命令外，还能够利用“用户自定义函数”的技巧，即UDF（User-Defined Functions）来执行命令。好比经过lib_mysqludf_sys提供的几个函数执行系统命令。
• 其余数据库也有相似UDF的功能，利用UDF功能实施攻击的技巧也大同小异。
• 在Oracle数据库中，若是服务器同时还有Java环境，那么也可能形成命令执行。当SQL注入后能够执行多语句的状况下，能够在Oracle中建立Java的存储过程执行系统命令。
• 通常来讲，在数据库执行系统命令要求具备较高的权限。所以在创建数据库帐户时应该遵循“最小权限原则”，尽可能避免给Web应用使用数据库的管理员权限。

2.3 攻击存储过程

• （1）利用存储过程直接攻击。好比在MS SQL Server中，能够直接使用存储过程“xp_cmdshell”执行系统命令，使用存储过程“xp_regread”等来操做注册表，等等。
• （2）存储过程自己也可能会存在注入漏洞。好比存储过程当中的某些变量由外部传入，且未通过任何处理，将直接形成SQL注入的问题。

2.4 编码问题

• 基于字符集的注入攻击的解决方法：统一数据库、操做系统、Web应用所使用的字符集，以免各层对字符的理解存在差别。统一设置为UTF-8是一个很好的办法。若是由于种种缘由没法统一字符编码，则须要单独实现一个用于过滤或转义的函数，这个函数根据系统所使用的不一样字符集来限制用户输入数据的字符容许范围，以实现安全过滤。

2.5 SQL Column Truncation

• 在MySQL的配置选项中，有一个sql_mode选项。当MySQL的sql_mode设置为宽松模式时，即没有开启STRICT_TRANS_TABLES选项时，MySQL对于用户插入的超长值只会提醒warning，而不是error（若是是error则插入不成功），这可能致使发生一些“截断”问题。
• 例如：数据库中存在一个表user，该表中有一个字段为username，username的字段类型为varchar(10)，若是我在插入数据的时候，插入一个值“admin（55个空格）x”，显然它超过了设定的字段长度10。那么，若是MySQL事先设置的是宽松模式，则此时会报warning，数据自动截断，插入成功；若是MySQL事先设置的是严格模式，则报error，数据插入失败。
• 当攻击者插入一个与数据库中已存在的同名username时，则可能使攻击者经过某些认证，从而形成一些越权访问。好比经过注册一个用户名为“admin（55个空格）x”的用户，就能够修改原管理员的密码了。

3.正确地防护SQL注入

3.1 使用预编译语句

• 通常来讲，防护SQL注入的最佳方式，就是使用预编译语句，绑定变量。好比在Java语言中，使用PreparedStatement()方法，绑定变量。
• mybatis的#{}和${}语法区别：#至关于对数据 加上 双引号，$至关于直接显示数据。mybatis使用#{}语法参数化来避免SQL注入。

3.2 使用安全的存储过程

3.3 检查输入数据的数据类型

• 好比输入数字时，检查输入数据只能为整型，或者输入邮箱时，严格按照邮箱的格式检查等。

3.4 使用安全的编码函数

• 好比ESAPI.encoder().encodeForSQL( new OracleCode(), queryparam );

3.5 最小权限原则

• 数据库使用“最小权限原则”，避免Web应用之间使用root、dbowner等最高权限帐户直接链接数据库。若是有多个不一样的应用使用同一个数据库，则也应该为每一个应用分配不一样的帐户。Web应用使用的数据库帐户，不该该有建立自定义函数，操做本地文件的权限。

4.其余注入攻击

4.1 XML注入

• XML注入与HTML注入相似。解决方法就是对用户输入数据中包含的“语言自己的保留字符”进行转义便可。

4.2 代码注入

• 代码注入与命令注入每每都是由一些不安全的函数或者方法引发的，其中的典型表明就是eval()。其余的还有好比利用Java的脚本引擎实施代码注入、PHP和JSP的动态include致使代码注入、利用system()函数执行系统命令等。
• 对抗代码注入、命令注入是，须要禁用eval()、system()等能够执行命令的函数。若是必定要使用这些函数，则须要对用户的输入数据进行处理。此外，在PHP/JSP中避免动态include远程文件，或者安全地处理它。此外，在开发过程当中，应尽可能避免使用危险函数。

4.3 CRLF注入

• CRLF其实是两个字符：CR是carriage return（回车，ASCII 13，\r），LF是line feed（换行,ASCII 10,\n）。即\r\n，其十六进制编码分别为0x0d、0xa。
• CRLF常被用作不一样语义之间的分隔符。所以t经过“注入CRLF字符”，就有可能改变原有的语义。凡是使用CRLF做为分隔符的地方都有可能存在这种注入，好比log注入、“注入HTTP头”等。
• 在HTTP协议中，HTTP头是经过“\r\n”来分隔的。所以若是服务器端没有过滤“\r\n”，而又把用户输入的数据放在HTTP头中，则有可能致使安全隐患。这种在HTTP头中的CRLF注入，又能够称为“Http Response Splitting”。好比经过2次CRLF注入能够将恶意代码注入到HTTP Body中，经过1次CRLF注入能够注入一个Link头形成XSS、注入一个X-XSS-Protection:0头以关闭IE8的XSS Filter功能等。
• 对抗CRLF的方法很是简单，只要处理好“\r”、“\n”这两个保留字符便可，尤为是那些使用换行符做为分隔符的应用。

二 文件上传漏洞

1.文件上传漏洞概述

• 文件上传漏洞是指用户上传了一个可执行的脚本文件，并经过此脚本文件得到了执行服务器端命令的能力。
• 文件上传后致使的常见安全问题通常有~~~~~
• 经过文件上传漏洞进行攻击须要知足3个条件：
• （1）上传的文件能被web容器解释执行。
• （2）用户可以从Web上访问这个文件。
• （3）用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容，则也可能致使攻击不成功。

1.1 从FCKEditor文件上传漏洞谈起

• FCKEditor是一款很是流行的富文本编辑器，它通常是做为第三方应用集成到网站中的，它有一个文件上传功能，在存在漏洞的版本中，是经过检查文件的后缀来肯定是否安全的，以黑名单的的方式限制文件上传的类型，所以有一些不在黑名单中的文件，好比后缀为php2,asa,cer等的文件均可能致使发生安全问题。

1.2 绕过文件上传检查功能

• 不少应用经过判断文件名后缀的方法来验证文件的安全性——攻击者能够手动修改上传过程的POST包，在文件名后添加一个%00字节，则能够截断某些函数对文件名的判断，达到攻击目的。
• 有的应用经过判断上传文件的文件头来验证文件的类型——攻击者能够伪造一个合法的文件头，而将真实的PHP等脚本代码附在合法的文件头以后。

2.功能仍是漏洞

2.1 Apache文件解析问题

• Apache对于文件名的解析是从后往前的，直到碰见一个它认识的文件类型为止。Apache又是根据定义在自身mime.types文件中的内容来认识文件类型。在Apache 1.x、2.x中，Apache不认识.rar文件类型，因此在解析Phpshell.php.rar.rar.rar.rar.rar文件时，它会从后往前一直遍历后缀到.php，而后认为这是一个PHP类型的文件。从而致使脚本被执行。

2.2 IIS文件解析问题

• IIS 6漏洞一：分号字符截断问题，好比将文件名abc.asp;xx.jpg解析为abc.asp，从而致使脚本被执行。
• IIS 6漏洞二：由于处理文件夹扩展名出错，致使将/*.asp/目录下的全部文件都做为ASP文件进行解析。
• ISS中因为支持PUT功能致使的上传脚本问题：在IIS中，若是目录支持写权限，同时开启了WebDev，则会支持PUT方法，再结合MOVE方法，就可以将原来只容许上传的文本文件改成脚本文件从而执行webshell。Move可否执行成功，取决于IIS服务器是否勾选了“脚本资源访问”复选框。
• 通常要实施此攻击过程，攻击者应先经过OPTIONS方法探测服务器支持的HTTP方法类型，若是支持PUT，则使用PUT上传一个指定的文本文件，最后经过MOVE改写为脚本文件。

2.3 PHP CGI路径解析问题

• Nginx配置fastcgi使用PHP时，会存在文件解析漏洞。好比当访问http://www.xxx.com/path/test.jpg/notexist.php时，会将test.jpg当作PHP进行解析，notexist.php是不存在的文件。
• 这样致使的后果是，若是在任何配置为fastcgi的PHP应用里上传一张图片，其图片内容是PHP文件，则将致使代码执行。
• 官方建议是将PHP的配置文件中与此有关的一个关键选项cgi.fix_pathinfo设置为0（态度消极）。

2.4 利用上传文件钓鱼

• 钓鱼网站在传播时，会经过利用XSS、服务器端302跳转等功能，从正常的网站跳转到钓鱼网站。可是这种钓鱼会在URL中暴露真实的钓鱼网站地址，易被发现。
• 而利用文件上传功能，钓鱼者能够先将包含了HTML的文件（好比一张图片）上传到目标网站，而后经过传播这个文件的URL进行钓鱼，则URL中不会出现钓鱼地址，更具备欺骗性。

3.设计安全的文件上传功能

• （1）文件上传的目录设置为不可执行
• （2）判断文件类型（推荐白名单方式）
• （3）使用随机数改写文件名和文件路径
• （4）单独设置文件服务器的域名

三 认证与会话管理

1.Who am I?

• 认证的目的是为了认出用户是谁，而受权的目的是为了决定用户可以作什么。
• 认证明际上就是一个验证凭证的过程。若是只有一个凭证被用于认证，则称为“单因素认证”（用户体验好），若是有2个或者多个凭证被用于认证，则称为“双因素认证”或“多因素认证”（强度高）。

2.密码那些事儿

• 密码是最多见的一种认证手段。
• 密码强度——是设计密码认证方案时第一个须要考虑的问题，每一个网站在其选择上，都有本身的策略。目前并无一个标准。笔者介绍的OWASP推荐策略你们能够参考。
• 密码保存——密码必须以不可逆的加密算法，或者是单项散列函数算法，加密后存储在数据库中。目前广泛作法是将明文密码通过哈希后（MD5或者SHA-1）再保存到数据库中，使用MD5加密密码容易被“彩虹表”方法破解，为了对抗“彩虹表”类攻击，在计算密码明文的哈希值时，能够增长一个“Salt”。“Salt”是一个随机字符串，做用是为了增长明文的复杂度。Salt使用以下：MD5(Username+Password+Salt)。

3.多因素认证

• 多因素认证提升了攻击的门槛。好比支付宝是使用了支付密码、手机动态口令、数字证书、保令、支付盾、第三方证书等进行多因素认证。

4.Session与认证

• 当认证成功后，就须要替换一个对用户透明的凭证，这个凭证，就是SessionID。通常会把SessionID加密后保存在Cookie中，由于Cookie会随着HTTP请求头发送，且受到浏览器同源策略的保护。
• 为了安全，一要保证SessionID的随机性，二要防止SessionID劫持。

5.Session Fixation攻击

• Session Fixation攻击过程——攻击者先获取到一个未经认证的SessionID，而后将这个SessionID交给用户去认证，用户完成认证后，服务器并未更新此SessionID的值，因此攻击者能够直接凭借此SessionID登陆仅用户的帐户。
• Session Fixation解决方法——在登陆完成后，重写SessionID。

6.Session保持攻击

• Session保持攻击1——有一些系统，出于用户体验的考虑，只要这个用户还活着，就不会让这个用户的Session失效，从而攻击者能够经过不停地发起访问请求（好比刷新页面），让session一直活下去。
• Session保持攻击2——还有不少系统，服务器端并不维护Session，而把Session放在Cookie中加密保存，利用Cookie的Expire标签来控制Session的失效时间。而Cookie的Expire时间是彻底能够由客户端控制的。篡改这个时间并使其永久有效就有可能得到一个永久有效的Session。甚至攻击者能够为Session Cookie增长一个Expire时间，使得本来浏览器关闭就会失效的Cookie持久化保存在本地，变成一个第三方Cookie。
• 如何对抗Session保持攻击？
  • （1）在必定时间后，强制销毁Session。
  • （2）当用户客户端发生变化时，要求用户从新登陆。
  • （3）每一个用户只容许拥有一个Session。

7.单点登陆（Single Sign On，简称SSO）

• 单点登陆实现了用户只登陆一次，就能够访问全部的系统。
• 它有利有弊，利是风险集中化，只须要保护好这一个点，弊是风险被集中了，单点一旦被攻破，影响的范围将涉及全部使用单点登陆的系统。
• 目前最大的单点登陆实现是OpenID，可是发展有限。

四 访问控制

1.What Can I do?

• 访问控制——某个主体对某个客体须要实施某种操做，而系统对这种操做的限制就是权限控制。
• 在Web应用中，根据访问客体的不一样，常见的访问控制能够分为基于 URL/方法/数据的访问控制。
• 漏洞举例：有些网站后台页面存在未受权访问漏洞，好比一个后台管理页面只有管理员才能够访问，它是不会被连接到前台页面上的，因此正经常使用户是不知道的。可是它却未对用户访问权限进行控制，致使任意用户只要构造出了正确的URL就能够访问这些页面。解决方法只要加上“基于页面的访问控制”能够了。

2.垂直权限管理（又称为“基于角色的访问控制”）

• 访问控制就是创建起用户与权限之间的对应关系，一种应用普遍的方法是基于角色的访问控制（Role-based Access  Control），简称RBAC，咱们称之为“垂直权限管理”。即高权限角色访问低权限角色的资源每每是被容许的，而低权限角色访问高权限角色资源每每被禁止。为防止发生“越权访问”，在配置权限时，应该使用“最小权限原则”和“默认拒绝”策略。
• 举例：Spring Security中的权限管理就是RBAC模型的一个实现。

3.水平权限管理（又称为“基于数据的访问控制”）

• “垂直权限管理”不足之处——同一个角色下的不一样用户可能存在私有数据，RBAC模型只会验证用户A是否属于角色RoleX，而不会判断用户A可否访问只属于用户B的数据DataB，所以，发生了“越权访问”。这种问题，咱们就称之为“水平权限管理问题”。
• 水平权限问题与业务需求息息相关，目前并无通用的解决方案，通常是具体问题具体解决。

4.OAuth简介

• OAuth是一个在不提供用户名和密码的状况下，受权第三方应用访问Web资源的安全协议。好比它能够使得用户在不须要向人人网提供MSN用户名和密码的状况下，能够受权MSN将用户的好友名单提供给人人网。

五 加密算法与随机数

1.概述

• 常见的加密算法分为两类：
  • （1）分组加密算法，好比DES、3-DES、Blowfish、IDEA、AES等。
  • （2）流密码加密算法，好比RC四、ORYX、SEAL等。
• 针对加密算法的攻击，根据攻击者能得到的信息，能够分为：惟密文攻击、已知明文攻击、选择明文攻击、选择密文攻击。

2.流密码加密算法

• Stream Cipher Attack——流密码的加密是基于异或操做的，每次都只操做一个字节。性能好。

流密码加密算法中的几种常见攻击方法：

2.1 Reused Key Attack

• 在流密码的使用中，最多见的一个错误就是使用同一个密钥进行屡次加解密，这将使破解流密码很是简单。这种攻击叫作“Reused Key Attack”。在这种攻击下，攻击者不须要知道密钥便可还原出明文。
• 举例——破解authcode()函数加密。
• 延伸——弱随机IV问题（IV指初始化向量）：在anthcode()函数中，它默认使用了4字节的IV，使得破解的难点增大，但其实4字节的IV是很脆弱的，它不够随机，攻击者能够经过“暴力破解”的方式找到重复的IV。

2.2 Bit-Flipping Attack

• 攻击者在不知道明文的状况下，经过改变密文，使得明文按其须要的方式发生改变的攻击方式，被称为Bit-Flipping Attack。
• 解决Bit-Flipping攻击的方法是验证密文的完整性。最多见的方法是增长带有KEY的MAC（Message Authentication Code，消息验证码），经过MAC验证密文是否被篡改。
• 经过哈希算法来实现的MAC，称为HMAC。HMAC因为其性能较好，而被普遍应用。

2.3 WEP破解

• WEP是之前用的无线加密传输协议，破解了WEP的密钥，就能够免费蹭网了。WEP采用RC4算法，因为存在漏洞易被破解，目前已经被WPA（全名为Wi-Fi Protected Access，有WPA和WPA2两个标准）取代了。

3.分组加密算法中的几种攻击方法

3.1 ECB模式的缺陷

•  对于分组加密算法，除去算法自己，还有一些通用的加密模式，不一样的加密算法会支持一样的几种加密模式。常见的加密模式有：ECB、CBC、CFC、OFB、CTR等，若是加密模式被攻击，那么不论加密算法的密钥有多长，都有可能再也不安全。
• ECB模式是最简单的一种加密模式，它的每一个分组之间相对独立，改变分组密文的顺序，将改变解密后的明文顺序；替换某个分组密文，解密后该对应分组的明文也会被替换，而其余分组不受影响。这与链式加密模式（CBC）彻底不一样，链式加密模式的分组先后之间会互相关联，一个字节的变化，会致使整个密文发生变化。
• 当须要加密的明文多于一个分组的长度时，应该避免使用ECB模式，而使用其余更加安全的加密模式。

3.2 Padding Oracle Attack

• 针对CBC模式的Padding Oracle Attack——它能够在不知道密钥的状况下，经过对padding bytes的尝试，还原明文，或者构造出任意明文的密文。
• padbuster工具能够自动实施Padding Oracle攻击。
• Padding Oracle Attack的关键在于攻击者可以获知解密结果是否符合padding。在实现和使用CBC模式的分组加密算法时，注意这一点便可。

4.密钥管理

• 在密码学里有个基本原则：密码系统的安全性应该依赖于密钥的复杂性，而不该该依赖于算法的保密性。
• 密钥管理中最多见的错误就是将密钥硬编码在代码里，这样作大大提升了密钥泄漏的可能性。
• 对于web应用，常见的作法是将密钥（包括密码）保存在配置文件或者数据库中，在使用时由程序读出密钥并加载进内存，必定不能把密钥写入本地文件中。

5.伪随机数问题

• 伪随机数，是经过一些数学算法生成的随机数，并不是真正的随机数。密码学上的安全伪随机数应该是不可压缩的。

5.1 弱伪随机数的麻烦

• 在WEB应用中，密码、key、SessionID、token等许多很是关键的“secret”都是经过伪随机数算法生成的，若是使用了弱伪随机数算法，则可能致使很是严重的安全问题。

5.2 时间真的随机吗

• 有的程序员直接使用系统时间代替随机数生成，这样生成的随机数时根据时间顺序增加的，能够从时间上进行预测，从而存在安全隐患。
• 要切记——不要把时间函数当成随机数使用。

5.3 破解伪随机数算法的种子

• 在PHP中，经常使用的随机数生成算法有rand()、mt_rand()，最大值分别为32767（3万多）、2147483647（约21.5亿）。
• rand()范围很是小，若是将其用户一些重要的地方，将会很是危险。
• mt_rand()也有一些缺陷。能够经过猜想种子，来猜想其产生的伪随机数。
  • 原理：伪随机数是由数学算法实现的，它真正随机的地方在于“种子（seed）”。种子一旦肯定后，再经过同一伪随机数算法计算出来的随机数，其值是固定的，屡次计算所得值的顺序也是固定的。
  • 攻击方式：
    • （1）经过一些方法猜想出种子的值；
    • （2）经过mt_rand()对猜解出的种子值进行播种；
    • （3）经过还原程序逻辑，计算出对应的mt_rand()产生的伪随机数的值。

5.4 使用安全的随机数

• 谨记：在重要或敏感的系统中，必定要使用足够强壮的随机数生成算法。好比
  • 在java中，能够使用java.security.SecureRandom；
  • 在Linux中，能够使用/dev/Random或者/dev/urandom；
  • 在PHP中，能够使用openssl_random_pseudo_bytes()函数；
  • 其余，能够在算法上经过多个随机数的组合以增长随机数的复杂性，好比经过给随机数使用MD5算法后，再链接一个随机字符，而后再MD5算法一次。

6.小结

• 算法的选择和使用之最佳实践：
  • （1）不要使用ECB模式；
  • （2）不要使用流密码（好比RC4）；
  • （3）使用HMAC-SHA1代替MD5（甚至是代替SHA1）；
  • （4）不要使用相同的key作不一样的事情；
  • （5）salts和IV须要随机产生；
  • （6）不要本身实现加密算法，尽可能使用安全专家已经实现好的库；
  • （7）不要依赖系统的保密性。
• 当你不知道如何选择时，有如下建议：
  • （1）使用CBC模式的AES256用于加密；
  • （2）使用HMAC-SHA512用于完整性检查；
  • （3）使用带salt的SHA-256或SHA-512用于Hashing。

六 Web框架安全

1.MVC框架安全

• MVC是Model-VIew-Controller的缩写，它将Web应用分为三层，View层负责用户视图、页面展现等工做；Controller负责应用的逻辑实现，接收View层传入的用户请求，并转发给对应的Model作处理；Model层则负责实现模型，完成数据的处理。
• 从数据的流入来看，用户提交的数据前后流经了View层、Controller层、Model层，数据的流出则反过来。
• 优秀的安全方案应该是在正确的地方作正确的事情，好比在View层解决XSS问题，在Model层解决SQL注入问题等等。
• 在框架中集中实施安全方案，能够大大节省程序员的工做量，并且能够使全部基于框架开发的业务都能受益，从安全方案的有效性来讲，更容易把握。

2.模板引擎与XSS防护

• 在当前流行的MVC框架中，View层经常使用的技术是使用模板引擎对页面进行渲染。
• 最好的XSS防护方案，是在不一样的场景使用不一样的编码函数，而一些模板引擎倒是统一使用HtmlEncode编码来防护XSS攻击，这样颇有可能会被攻击者绕过。
• 不过幸运的是，在模板引擎中能够以实现自定义的编码函数，应用于不一样场景。在Django中是使用自定义filters，在Velocity中则能够使用“宏”。经过自定义的方法，使得XSS防护功能获得完善。
• 在其余的模板引擎中，也能够根据“是否有细分场景使用不一样的编码方式”来判断XSS的安全方案是否完整。在使用Web框架时，应该慎重对待安全问题，不可盲从官方文档。

3.Web框架与CSRF防护

• 在Web框架中能够使用security token解决CSRF攻击的问题。
• 对应Web框架来讲，能够要求全部的写操做都使用HTTP POST，自动地在全部涉及POST的代码中添加token，这些地方包括全部的form表单，全部的Ajex POST请求等。
• 完整的CSRF防护方案，对于Web框架来讲有如下几处须要改动。
  • （1）在Session中绑定token。若是不能保存到服务器端Session中，则能够替代为保存到Cookie里。
  • （2）在form表单中自动填入token字段。
  • （3）在Ajex请求中自动添加token，这可能须要已有的Ajex封装实现的支持（通常是插入一个包含了token的HTTP头，使用HTTP头是为了防止Token泄密，由于通常的JavaScript没法获取到HTTP头的信息，可是存在一些跨域漏洞时可能会出现例外）。
  • （4）在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击。
• 在Spring MVC以及一些其余的流行Web框架中，并无直接提供对CSRF的保护，所以这些功能须要本身实现。

4.HTTP Headers管理

• 在Web框架中，能够对HTTP头进行全局化的处理，所以一些基于HTTP头的安全方案能够很好地实施。好比
  • （1）将Http头当作Key-Value对，对抗CRLF的方案只需在“value”中编码全部的\r\n便可（固然了，用户绝对不能控制key，由于这是很是危险的）；
  • （2）在框架中统一管理好跳转的目的地址，好比指定跳转地址只能在白名单中，防止被钓鱼。
  • （3）有不少与安全相关的Headers，也能够统一在Web框架中配置。好比用来对抗ClickJacking的X-Frame-Options，web框架能够封装此功能，并提供页面配置。
  • （4）对全部的Cookie默认添加HttpOnly，不须要此功能的Cookie则单独在配置文件中列出。

5.数据持久层与SQL注入

• 对抗SQL注入的最佳方式就是使用“预编译绑定变量”。
• 使用ORM（Object/Relation Mapping）框架对SQL注入是有积极意义的。

6.还能想到什么

• 凡是在Web框架中可能实现的安全方案，只要对性能没有太大的损耗，都应该考虑实施。好比：
  • （1）在Web框架中为上传文件功能提供一个足够安全的二方库或者函数；
  • （2）保存好安全检查的日志；
  • （3）与时俱进等。

7.Web框架自身安全

• Web框架曾经出现过的严重漏洞：
  • （1）Struts 2命令执行的漏洞
  • （2）从Struts 2的问题补丁能够看出，其开发者对于安全的理解很是不到位。
  • （3）Spring MVC命令执行漏洞
  • （4）Django命令执行漏洞

七 应用层拒绝服务攻击

1.DDOS简介

• DDOS又称为分布式拒绝服务，全称是Distributed Denial of Service。DDOS本质是利用合理的请求形成资源过载，致使服务不可用。
• 常见的DDOS攻击有SYN flood（最经典，利用了TCP协议设计中的缺陷）、UDP flood、ICMP flood等。
• TCP三层握手过程~~~
• SYN flood攻击过程~~~
• 对抗SYN flood的措施主要有SYN Cookie/SYN Proxy、safereset等算法。
• 在不少对抗DDOS的产品中，通常会综合使用各类算法，结合一些DDOS攻击的特征，对流量进行清洗。

2.应用层DDOS—— CC攻击

• CC攻击原理：对一些消耗资源较大的应用页面不断发起正常的请求以达到消耗服务器资源的目的。
• 在Web应用中，查询数据库、读写硬盘文件等操做，相对都会消耗比较多的资源。
• 应用层DDOS攻击还能够经过如下方式完成：在黑客入侵了一个流量很大的网站后，经过篡改页面，将巨大的用户流量分流到目标网站。

3.防护应用层DDOS

3.1 限制请求频率

• 最多见的针对应用层DDOS攻击的防护措施，是在应用中针对每一个“客户端”作一个请求频率的限制。好比经过IP地址和Cookie定位一个客户端，若是客户端的请求在必定时间内过于频繁，则对以后来自该客户端的全部请求都重定向到一个出错页面。
• 虽然网站能够根据IP地址定位攻击者，可是在实际的攻击中，攻击者通常会使用代理服务器或者傀儡机来隐藏本身的真实IP地址，从而绕过服务器对单个IP地址请求频率的限制了。
• 解决应用层DDOS攻击咱们能够从如下3个方面入手：
  • （1）应用代码作好性能优化。
  • （2）在网络架构上作好优化（好比利用负载均衡进行分流）。
  • （3）实现一些对抗手段，好比限制每一个IP地址的请求频率。

3.2 人机识别

3.2.1 验证码的那些事儿——识别人

• 验证码（CAPTCHA）的用户体验很差，可是却可以有效地阻止自动化的重发行为。
• 验证码破解技术：
  • （1）直接利用图像相关算法识别验证码。
  • （2）利用Web实现上可能存在的漏洞破解验证码。好比
    • 原理1：验证码的验证过程，是对比用户提交的明文和服务器端Session里保存的验证码明文是否一致。
    • 对应漏洞：由于验证码消耗掉后SessionID未更新，致使使用原来的SessionID能够一直重复提交同一个验证码。
    • 原理2：还有的验证码实现方式，是提早将全部的验证码图片生成好，以哈希过的字符串做为验证码图片的文件名。使用验证码时，则直接从图片服务器返回已经生成好的验证码。这种设计本来的想法是为了提升性能。
    • 对应漏洞：这种一一对应的验证码文件名会存在一个缺陷：攻击者能够事先采用枚举的方式，遍历全部的验证码图片，并创建验证码到明文之间一一对应关系，从而造成一张“彩虹表”。这也会致使验证码形同虚设。修补的方式是验证码的文件名须要随机化，知足“不可预测性”原则。

3.2.2 识别客户端

• 通常状况下，服务器端应用能够经过判断HTTP头中的User-Agent字段来识别客户端，可是User-Agent是能够被客户端篡改的，因此不能信任。一种比较可靠的方法是让客户端解析一段JavaScript并给出正确的运行结果，或者发送一个flash让客户端解析。但有的客户端脚本是内嵌在浏览器中的“内挂”，那就没法检测了。

3.3 其余

• 在Apache的配置文件中，有一些参数能够缓解DDOS攻击。好比调小Timeout、KeepAliveTimeout值，增大MaxClients值。
• 目前已经有一些开源的Module所有或者部分实现了真的应用层DDOS攻击的保护。好比mod_qos、mod_evasive等。
• Yahoo的专利。

4.资源耗尽攻击

4.1 Slowloris攻击

• 原理：因为WebServer对于并发的链接数都有必定的上限，所以如果恶意地占用住这些链接不释放，那么Web Server的全部链接都将被恶意链接占用，从而没法接受新的请求，致使拒绝服务。
• 攻击：在正常的HTTP包头中，是以两个CLRF表示HTTP Headers部分结束的。所以攻击者能够构造一个不完整的HTTP请求（最后一行只有一个CLRF），Web Server只收到了一个\r\n，所以将认为HTTP Header部分没有结束，并保持此链接不释放，继续等待完整的请求。此时客户端再发送任意HTTP头，保持住链接便可。当构造多个链接后，服务器的链接数很快就会达到上限。

4.2 HTTP POST DOS

• 原理：在发送HTTP POST包时，指定一个很是大的Content-Length值，而后以很低的速度发包，好比10-100s发一个字节，保持住这个链接不断开。这样当客户端链接数多了之后，占用住了Web Server的全部可用链接，从而致使DOS。

4.3 Server Limit DOS

• 原理：因为Web Server限制Request Header最大值为8192字节，若是客户端发送的HTTP包头超过这个大小，服务器就会返回一个4xx错误。
• 攻击：假设攻击者经过XSS攻击，恶意地往客户端写入了一个超长的Cookie，因为Cookie也是放在HTTP包头中发送的，Web Server默认会认为这是一个超长的非正常请求，从而致使拒绝服务，则在该客户端清空Cookie以前，将没法再访问该Cookie所在域的任何页面。
• 防护：调整Apache配置参数LimitRequestFieldSize，这个参数设置为0时，对HTTP包头大小没有限制。

5 一个正则引起的血案：ReDOS

• 当正则表达式写的很差从而被恶意输入利用，消耗大量资源，致使DOS。这种攻击被称为ReDOS。
• 原理：当用户恶意构造输入时，有缺陷的正则表达式会增长正则引擎解析数据时的消耗，就会消耗大量的系统资源（好比CPU和内存），从而致使整台服务器的性能降低，表现的结果是系统速度很慢，有的进程或服务失去响应，与拒绝服务的后果是同样的。

八 PHP安全

1.文件包含漏洞

• 文件包含是PHP的一种常见用法，主要由4个函数完成：include()、require()、include_once()、require_once()。当使用这4个函数包含一个新的文件时，该文件将做为PHP代码执行，PHP内核并不在乎该包含的文件是什么类型。
• 利用条件：（1）include()等函数经过动态变量的方式引入须要包含的文件；（2）用户可以给控制该动态变量。

1.1 本地文件包含漏洞（Local File Inclusion，LFI）

• 好比这段代码，include “/home/wwwrun/”.$file.'php';，用户能够控制参数file，当file的值为“../../etc/passwd”时，PHP将访问/etc/password.php文件。
• 可是这个文件是不存在的，攻击者能够在最后加入一个0字节，截断file变量以后的字符串（由于PHP内核是由C语言实现的，在链接字符串时，0字节（\x00）将做为字符串的结束符）。即“../../etc/passwd\0”，经过Web输入时，只须要URLEncode，变成“../../etc/passwd%00”。
• 字符截断技巧，也是文件包含中最经常使用的技巧。但在通常的web应用中，0字节用户实际上是不须要使用的，所以彻底能够禁用的。
• 此时，攻击者能够使用另一个技巧，利用操做系统对目录最大长度的限制，能够不须要0字节而达到截断的目的。目录字符串，在Windows下256字节、Linux下4096字节时会达到最大值，最大值长度以后的字符将被丢弃。如何构造出这么长的目录呢？经过“./”便可。好比“./././././././././.abc”或者“////////////abc”或者“../1/abc../1/abc../1/abc”。
• 本地文件包含漏洞可以读取敏感文件或者服务器端脚本的源代码，从而为攻击者进一步攻击奠基基础。
• 使用了“../../../”这样的方式来返回到上层目录中，这种方式又被称为“目录遍历”。常见的目录遍历漏洞，还能够经过不一样的编码方式来绕过一些服务器端逻辑。好比%2e%2e%2f等同于../等等。
• 目录遍历漏洞是一种跨越目录读取文件的方式，但当PHP配置了open_basedir时，将很好地保护服务器，使得这种攻击无效。open_basedir的值是目录的前缀，若是要限定一个指定的目录，则须要在最后加上“/”。
• 要解决文件包含漏洞，应该尽可能避免包含动态的变量，尤为是用户能够控制的变量。一种变通方法是使用枚举，将$file的值被枚举出来，也就避免了任意文件包含的风险。

1.2 远程文件包含漏洞（Remote File Inclusion，RFI）

• 攻击者能够构造攻击URL，用来执行任意命令。

1.3 本地文件包含的利用技巧

如下几种常见技巧，用于本地文件包含后执行PHP代码。

• （1）包含用户上传的文件。——最简单的方法，用户上传的文件内容中若是包含PHP代码，那么这些代码被include()加载后将会执行。可是可否攻击成功，取决于文件上传功能的设计，好比要求知道用户上传后文件所在的物理路径，有时候这个路径很难猜到。
• （2）包含data://或PHP://input等伪协议。——伪协议须要服务器支持，同时要求allow_url_include设置为ON。
• （3）包含Session文件。——须要攻击者能控制部分Session文件的内容。
• （4）包含日志文件。——间接地将PHP代码写入日志中，而后包含日志文件便可。可是当日志文件过大时，PHP进程可能会僵死。所以在凌晨时包含日志文件将提升攻击的成功性，由于此时日志文件可能很是小。
• （5）包含/proc/self/environ文件。——它是Web进程运行时的环境变量，其中不少都是用户能够控制的，最多见的作法是在User-Agent中注入PHP代码，完成攻击。
• （6）包含上传的临时文件。——以上方法，若是PHP配置了open_basedir，则极可能会失效。但PHP建立的上传临时文件，每每处于PHP容许访问的目录范围内。该临时文件的文件名是随机的，但并无使用安全的随机函数，因此能够使用暴力破解文件名。
• （7）包含其余应用建立的文件，好比数据库文件、缓存文件、应用日志等，须要具体状况具体分析。

2.变量覆盖漏洞

2.1 全局变量覆盖

• 变量若是未被初始化，且能被用户所控制，那么极可能会致使安全问题，而在PHP中，这种状况在register_globals为ON时尤其严重。

2.2 extract()变量覆盖

• extract()函数能将变量从数组导入当前的符号表。当extract()函数从用户能够控制的数组中导出变量时，可能发生变量覆盖。
• 安全作法是肯定register_globals=OFF后，在调用extract()时使用ECTR_SKIP参数保障已有变量不会被覆盖，而且extract()的来源数组不能被用户控制。

2.3 遍历初始化变量

• 常见的一些以遍历的方式释放变量的代码，可能致使变量覆盖。

2.4 import_request_variables变量覆盖

• bool import_request_variable( string $types [, string $prefix])
• import_request_variables()将GET、POST、Cookie中的变量导入到全局，使用这个函数只须要简单地指定类型便可。其中第二个参数是为导入的变量添加的前缀，若是没有指定，则将覆盖全局变量。

2.5 parse_str()变量覆盖

• parse_str()函数每每被用于解析URL的query string，可是当参数值能被用户控制时，极可能致使变量覆盖。

2.6 防护变量覆盖

• （1）确保register_globals=OFF。若不能自定义php.ini，则应该在代码中控制。
• （2）熟悉可能形成变量覆盖的函数和方法，检查用户是否能控制变量的来源。
• （3）养成初始化变量的好习惯。

3.代码执行漏洞

• 条件（1）用户可以控制函数输入（2）存在能够执行代码的危险函数。

3.1 “危险函数”执行代码

• 危险函数popen()、system()、passthru()、exec()等均可以直接执行系统命令。
• 此外，eval()函数也能够执行PHP代码。
• 3.1.1 phpMyAdmin 3.4.3.1 远程代码执行漏洞——这是一个典型的parse_str()覆盖变漏洞。
• 3.1.2 MyBB 1.4 远程代码执行漏洞——这是一个间接控制eval()函数输入的漏洞。
• 挖掘此类漏洞的过程，一般须要先找到危险函数，而后回溯函数的调用过程，最终看整个调用的过程当中用户是否有可能控制输入。

3.2 “文件写入”执行代码

• 在PHP中对文件的操做必定要谨慎，若是文件操做的内容用户能够控制，则也极容易成为漏洞。

3.3 其余执行代码方式

（1）直接执行代码的函数

• 好比eval()、assert()、system()、exec()、shell_exec()、passthru()、escapeshellcmd()、pcntl_exec()等。
• 最好禁用这些函数。在审计代码时能够检查代码中是否存在这些函数，而后回溯危险函数的调用过程，看用户是否能够控制输入。

（2）文件包含

• 高度关注可以包含文件的函数：include()、require()、include_once()、require_once()。

（3）本地文件写入

• 重点关注可以往本地文件里写入内容的函数，好比file_put_contents()、fwrite()、fputs()等。
• 注意，写入文件的功能能够和文件包含、危险函数执行等漏洞结合，最终使得本来用户没法控制的输入变成可控。在代码审计时要注意这种“组合类”漏洞。

（4）preg_replace()代码执行

• preg_replace()的第一个参数若是存在/e模式修饰符，则容许代码执行。
• 当第一个参数中包含变量，而且用户可控，有可能经过注入/e%00的方式截断文本，注入一个“/e”。

（5）动态函数执行

• 用户自定义的动态函数能够致使代码执行，须要注意这种状况。

（6）Curly Syntax

• PHP的Curly Syntax也能致使代码执行，它将执行花括号间的代码，并将结果替换回去。

（7）回调函数执行代码

• 不少函数均可以执行回调函数，当回调函数用户可控时，将致使代码执行。
• 能够执行回调函数的函数有array_map()、ob_start()等。

 （8）unserialize()致使代码执行

• unserialize()函数能够将序列化的数据从新映射为PHP变量。可是unserialize()在执行时若是定义了__destruct()函数，或者是__wakeup()函数，则这2个函数将执行。
• unserialize()代码执行有2个条件，一是unserialize()的参数用户能够控制，这样能够构造出须要反序列化的数据结构；二是存在__destruct()函数或者是__wakeup()函数，这2个函数实现的逻辑决定了能执行什么样的代码。

4.定制安全的PHP环境

经过配置php.ini加固PHP的运行环境。

• （1）设置register_globals=OFF，防止出现变量覆盖问题。
• （2）给open_basedir设置一个值，限制PHP只能操做指定目录下的文件。
• （3）设置allow_url_include=OFF,allow_url_fopen=OFF，以对抗远程文件包含。
• （4）正式环境中设置display_errors=OFF，log_errors=ON，关闭错误回显，将错误信息记录在日志中。
• （5）推荐magic_quotes_gpc=OFF。
• （6）若PHP是以CGI的方式安装，则须要关闭cgi.fix_pathinfo选项（cgi.fix_pathinfo=0），以免出现文件解析问题。
• （7）设置session.cookie_httponly=1，开启HttpOnly。
• （8）如果全站HTTPS则请开启session.cookie_secure选项（session.cookie_secure=1）。
• （9）若是是共享环境（好比APP Engine）则建议开启安全模式safe_mode（它会影响不少函数），和disable_functions配合使用；若是是单独的应用环境，则能够考虑关闭它，更多地依赖于disable_functions控制运行环境安全。
• （10）disable_functions可以在PHP中禁用函数。

九 Web Server配置安全

1.Apache安全

• （1）检查Apache安全的第一件事情，就是检查Apache的Module安装状况，根据“最小权限原则”，应该尽量地减小没必要要的Module，对于要使用的Module，则检查其对应版本是否存在已知的安全漏洞。
• （2）使用单独的低权限用户身份运行Apache，这个用户身份不该该具有shell（必定不要使用root或者admin身份），它惟一的做用就是用来运行Web。
• （3）Apache还提供了一些配置参数，能够用来优化服务器的性能，提升对抗DDOS攻击的能力。
• （4）要保护好 Apache Log。好比实时地发送到远程的syslog服务器上等，防止黑客入侵后修改、删除入侵痕迹。

2.Nginx安全

• （1）多多关注Nginx的漏洞信息，并及时将软件升级到安全的版本。
• （2）使用单独的用户身份运行Nginx。
• （3）调整Nginx配置参数，以缓解一些DDOS和CC攻击。

3.jBoss远程命令执行

• JBoss有一个管理后台——JMX-Console，默认安装的JMX-Console是没有任何认证的，黑客能够通8080端口访问/jmx-console进入到这个管理界面。在JMX-Console中，有多种能够远程执行命令的方法，最简单的方法就是经过DeploymentScanner远程加载一个war包。或者经过JMX-Console提供的BSH Deployment方法，一样也能够部署war包。
• 在加固时，须要删除JMX-Console后台，若是由于业务须要不得不使用JMX-Console，则应该使用一个强壮的密码，且运行JMX-Console的端口不该该面向整个Internet开放。

4.Tomcat远程命令执行

• Tomcat的Tomcat Manager做用与JMX-Console相似，管理员也能够在Tomcat Manager中部署war包。庆幸的是，Tomcat Manager部署war包须要有manager权限，而这一权限是在配置文件中定义的。须要由管理员修改此文件，定义出manager角色。可是像下面这种配置，就存在安全隐患了。
• <role rolename="manager"/>
• <user username="tomcat" password="tomcat" roles="tomcat,manager"/>
• 它直接将Tomcat用户添加为manager角色，而Tomcat用户的密码极可能是一个默认密码，这种配置违背了“最小权限原则”。
• 加固时，强烈建议删除这一后台。

5.HTTP Parameter Pollution

• HPP攻击原理：经过GET或者POST向服务器发起请求时，提交两个相同的参数，好比提交/?a=test1&a=test2，某些服务器环境中，会只取第一个参数或者只取第二个参数，而在另一些环境中，好比.net环境中，则会变成：a=test1,test2。利用这种特性，攻击者能够构造一些参数值绕过一些服务器的逻辑判断。
• 好比以下代码：/index.aspx?page=select 1& page=2,3 from table where id=1，经过HPP混淆参数，从而绕过ModSecurity对于SQL注入的检测。

第四篇 互联网公司安全运营 

一 互联网业务安全

1.产品须要什么样的安全

• 若是咱们的产品可以潜移默化地培养用户的安全习惯，将用户往更安全的行为上引导，那么这样的安全就是最理想的产品安全。

2.业务逻辑安全

3.帐户是如何被盗的

4.互联网的垃圾

• 垃圾注册、垃圾消息等的危害及处理

5.关于网络钓鱼

• 5.1 钓鱼网站简介
• 5.2 邮件钓鱼
  • 目前有许多识别发件人邮箱的安全技术，大部分都是基于域名策略的，好比SPF、雅虎的DomainKeys、微软的Sender ID技术等。
• 5.3 钓鱼网站的防控
  • （1）控制钓鱼网站的传播途径
  • （2）直接打击钓鱼网站
  • （3）用户教育
  • （4）自动化识别钓鱼网站
• 5.4 网购流程钓鱼

6.用户隐私保护

二 安全开发流程（SDL）

1.SDL简介

• SDL全称是Security Development Lifestyle，即安全开发生命周期。它是由微软最先提出的。
• 微软的SDL过程大体分为16个阶段：
  • 培训（1核心安全培训）-->
  • 要求（2肯定安全要求、3建立质量门/bug栏、4安全和隐私风险评估）-->
  • 设计（5肯定设计要求、6分析并减少攻击面、7威胁建模）-->
  • 实施（8使用指定的工具、9弃用不安全的函数、10静态分析）-->
  • 验证（11动态代码分析、12模糊测试、13攻击面评析）-->
  • 发布（14事件响应计划、15最终安全评析、16发布存档）-->
  • 响应（17执行时间响应计划）

2.敏捷SDL

• SDL适用于采用瀑布法进行开发的软件开发团队，微软为敏捷开发专门设计了敏捷SDL，以变化的观点实施安全工做。

3.SDL实战经验

• （1）与项目经理进行充分沟通，排出足够的时间。
• （2）规范公司的立项流程，确保全部项目都能通知到安全团队，避免遗漏。
• （3）树立安所有门的权威，项目必须由安所有门审核完成后才能发布。
• （4）将技术方案写入开发、测试的工做手册中。
• （5）给工程师培训安全方案。
• （6）记录全部的安全bug，激励程序员编写安全的代码。

4.需求分析与设计阶段

• 此阶段，安全工程师须要关心产品主要功能上的安全强度和安全体验是否足够，主要须要思考安全功能。另外，能够对项目经理、产品经理或者架构师进程访谈，以了解产品背景和技术架构，并给出相应建议。

5.开发阶段

• 开发阶段应该力求代码实现上的安全，作到“安全的功能”。

5.1 提供安全的函数

• 将安全方案写入开发规范中，真正地让安全方案落地。

5.2 代码安全审计工具

• 目前尚未比较完美的自动化代码审计工具，代码审计工具的结果仍须要人工处理。耗费人力。
• 实际上，对于甲方公司来讲，彻底能够根据开发规范来定制代码审计工具。其核心思想是，并不是直接检查代码是否安全，而是检查开发者是否遵照了开发规范。

6.测试阶段

• 安全测试，通常分为自动化测试和手动测试2种方式。
• 自动化测试以覆盖性的测试为目的，能够经过“Web安全扫描器”对项目或产品进行漏洞扫描。好比Appscan、skipfish等。
• 经过扫描器产生的安全报告可能会存在误报与漏报，须要通过安全工程师确认，并结合手动测试的结果，最终造成一份安全测试报告。

三 安全运营

1.把安全运营起来

• 安全是一个持续的过程，而“安全运营”的目的，就是把这个“持续的过程”执行起来。
• 公司安全的发展蓝图能够分为“Find and Fix”、“Defend and Defer”和“Secure at the source”三个方向，每个方向的最终结果都须要由“安全运营”来保证。

2.创建漏洞修补流程

• （1）创建相似bugtracker的漏洞跟踪机制，并为漏洞的紧急程度选择优先级；
• （2）创建漏洞分析机制，并与程序员一块儿制定修补方案，同时review补丁的代码实现；
• （3）对曾经出现的漏洞进行归档，并按期统计漏洞修补状况。

3.安全监控

4.入侵检测

• 常见的安全监控产品有IDS（入侵检测系统）、IPS（入侵防护系统）、DDOS监控设备等。
• 相对于传统的IDS，WAF（Web应用防火墙）专一于应用层攻击的检测和防护。
• 优秀的开源WAF有ModSecurity、PHPIDS等。
• ModSecurity是Apache的一个Module，它能获取到全部访问Apache Httped Server的请求，并根据本身的规则对这些请求进行匹配，以检测哪些请求存在攻击行为。
• PHPDIS是为PHP应用设计的一套入侵检测系统，它与应用代码的结合更为紧密，须要修改应用代码才能加载并使用它。

5.紧急响应流程

• 紧急响应流程就是在发生紧急安全事件时，须要启动一个用户快速处理事件的流程。
• 当安全事件发生时，首先应该通知到安全专家，并由安全专家着急紧急响应如今，处理相关问题。

（完）