一、Web应用程序安全与风险
A.Web应用程序安全
1.针对Web应用程序的最严重攻击，是那些能够披露敏感数据或获取对运行应用程序的后端系统的无限访问权限的攻击
2.核心安全问题：用户可以提交做任意输入，应用程序必须假设所有输入的信息都是恶意的输入，并必须采取措施确保攻击者无法使用专门设计的输入破坏应用程序，干扰逻辑结构与行为
3.关键问题因素
- 不成熟的安全
- 独立开发
- 欺骗性的简化
- 迅速发展的威胁形势
- 资源与时间限制
- 技术上强其所难
- 对功能的需求不断增加
二、核心防御机制
A.处理用户访问
1.三层相互关联的安全机制
- 身份验证：确定用户身份
- 会话管理：基本取决于其令牌的安全性
- 访问控制：应用程序从收到的每一个请求来确认用户身份，并决定授权用户执行其所请求的操作或访问相关数据
B.处理用户输入
1.输入处理方法
- “拒绝已知的不良输入”：黑名单关键字法、效率最低、效果一般，如SELECT绕过Select
- “接受已知的正常输入”：白名单，确认机制接受任何与白名单匹配的数据
- 净化：删除恶意字符或对其适当编码或“转义”
- 安全数据处理：可使用安全的编程方法，如参数化查询（PDO）等
- 语法检查：
2.边界确认：服务器端应用程序的每一个单独的组件或功能单元将其输入当做来自潜在恶意亚涛的输入对待。除客户端和服务器之间的外部边界外，应用程序在上述每一个信任边界上执行数据确认。
C.处理攻击者
1.处理错误：生产环境下，应用程序不应在其响应中返回任何系统生成的消息或其他调试信息
2.维护审计日志
- 所有与身份验证有关的事件，如成功或失败的登录、密码修改等
- 关键交易，如信用卡支付与转账
- 被访问控制机制阻止的访问企图
- 任何包含已知攻击字符串，公然表明恶意意图的请求
3.向管理员发出警报
- 应用反常：如一个IP或用户发出的大量请求
- 交易反常：如资金数量异常
- 包含已知攻击字符串的请求
- 请求中普通用户无法查看的数据被修改
4.应对攻击：高效的输入确认机制、自动反应措施（如终止异常会话等）
D.管理应用程序
1.身份验证机制中存在的薄弱环节
2.应用程序并不对它的一些被管理功能执行有效的访问控制
3.管理功能通常能够显示普通用户提交的数据
4.管理用户往往没有经过严格的安全测试
三、Web应用程序技术
四、解析应用程序
A.枚举内容与功能
1.Web抓取
2.用户指定的抓取
3.发现隐藏的内容
4.应用程序页面与功能路径
5.发现隐藏的参数
B.分析应用程序
1.分析应用程序的功能
- 应用程序的核心功能
- 其他较为外围的应用程序行为
- 核心安全机制及其动作方式
- 应用程序处理用户提交的输入的所有不同位置
- 客户端使用的技术
- 服务器端使用的技术
- 任何可收集到的、关于服务器端应用程序内部结构与功能的其他信息
2.确定用户输入入口点
- 每个URL字符串
- URL查询字符串中提交的每个参数
- POST请求主体中提交的每个参数
- 每个cookie
- HTTP请求头
2.确定服务端技术
- 提取版本信息：Server头
- HTTP指纹识别
- 文件扩展名
- 目录名称
- 会话令牌：PHPSESSID、JSESSIONID(java)
- 第三方代码组件
3.确定服务器端功能
- 仔细分析请求
- 推测应用程序的行为
- 隔离独特的应用程序行为
4.解析受攻击面
五、避开客户端控件
A.通过客户端传送数据
1.隐藏表单字段：如隐藏金额，用户修改后服务器不判断直接使用
2.HTTP Cookie
3.URL参数
4.Referer消息头
5.模糊数据
6.ASP.NET ViewState
B.收集用户数据：HTML表单
1.长度限制：查找maxLength的字段，提交超长信息，看反馈结果确定是否有漏洞
2.基于脚本的确认：禁止或者直接更改脚本即可
3.禁用的元素：解除禁用并提交看服务器如何处理
C.收集用户数据：浏览器扩展
1.Java applet、Flash和Silverlight
2.拦截并修改浏览器扩展组件提出的请求及服务器的响应：使用工具拦截请求
3.直接针对组件实施攻击，并尝试反编译它的字节码，或者使用调试器与组件进行动态交互
- 查找<applet>或<object>找到字节码文件，并下载
- 反编译后分析源码
- 在浏览器中重新编译并执行
D.安全处理客户端数据
1.通过客户端传送数据：对数据进行签名或加密处理防止篡改
2.确认客户端生成的数据：客户提交的每一项数据都应被视为危险和潜在恶意的
3.日志与警报：假如客户端验证失效，可以记录日志，确认这是不是一次攻击
六、攻击验证机制
A.验证技术
1.基于HTML表单的验证
2.多元机制，如组合型密码和物理令牌
3.客户端SLL证书或智能卡
4.HTTP基本和摘要验证
5.使用NTLM或Kerberos整合Windows的验证
6.验证服务
B.验证机制设计缺陷
1.密码保密性不强
- 非常短或空白的密码
- 以常用的字典词汇或名称为密码
- 密码和用户名完全相同
- 仍然使用默认密码
2.蛮力攻击登录：如果应用程序允许使用者使用不同的密码重复进行登录尝试，直到找到正确的密码，那么它就非常容易遭受攻击
3.详细的失败消息
4.证书传输易受攻击
- 如果以查询字符串参数、而不是在POST请求主体中传送证书，许多地方都可能记录这些证书
- 虽然大多数Web应用程序确实使用POST请求主体提交HTML登录表单，但令人奇怪的是，应用程序常常通过重定向到一个不同的URL来处理登录请求，而以查询字符串的形式提交证书
- Web应用程序有时将用户证书保存在cookie中，通常是为了执行设计不佳的登录、密码修改、“记住我”等机制
5.密码修改功能
- 提供了详细的错误信息，说明被请求的用户名是否有效
- 允许攻击者无限制猜测“现有密码”字段
- 在验证现有密码后，仅检查“新密码”与“确认新密码”字段的值是否相同，允许攻击者不需入侵即可成功查明现有密码
6.忘记密码功能
- 忘记密码功能常常向用户提出一个次要质询以代替主要登录功能，用户可能设置极不安全的质询问题
- 与密码修改功能一样，即使应用程序开发者在主登录页面阻止攻击者向密码恢复质询的响应发动蛮力攻击，他们也往往会在忘记密码功能中忽略这种攻击的可能性
- 一些应用程序 使用一个简单的密码“暗示”代替恢复质询
- 在用户正确响应一个质询后，应用程序即允许用户重新控制他们的账户，这种机制非常容易遭受攻击
- 一些应用程序允许用户在成功完成一个质询后直接重新设置密码，并且不向用户发送任何电子邮件通知
7.“记住我”功能
- 一些“记住我”功能通过一个简单的cookie执行
- 一些“记住我”功能设置一个cookie，其中并不包含用户名，而是使用一个持久会话标识符
- 即使cookie中保存的用于重新识别用户的信息得到适当的你别担心，以防止其他用户对此进行推断或猜测，但攻击者通过跨站点脚本之类的漏洞或本地访问的用户计算机依然可以轻易获得这些信息
8.用户伪装功能
- 伪装功能可以通过“隐藏”功能的形式执行，不受常规访问控制管理
- 当判定用户是否进行伪装时，应用程序可能会信任由用户控制的数据
- 如果应用程序允许管理用户被伪装，那么伪装逻辑中存在的任何缺陷都可能导致垂直权限提升漏洞
- 某种伪装功能能够以简单“后门”密码的形式执行，该密码可和任何用户一起向标准登录页面提交，以作为该用户进行验证
9.证书确认不完善（密码）
10.非唯一性用户名
11.可预测的用户名：一些应用程序根据某种规则自动生成用户名
12.可预测的初始密码：一些应用程序一次性或大批量创建用户，并自动指定初始密码，然后以某种方式将密码分配给所有用户
13.证书分配不安全
C.验证机制执行缺陷
1.故障开放登录机制：由于某种原因产生异常但用户仍然登录成功，虽然产生的会话可能并不属于某个特殊的用户，但仍然可以通过这种方法访问一些敏感数据或功能
2.多阶段登录机制中的缺陷
- 执行多次验证检查可能会显著提高登录机制的安全性，但相应地，这个过程也存在更多的执行缺陷。
- 应用程序可能认为访问第三阶段的用户已经完成第一、第二阶段的验证，因此，它可能允许直接由第一阶段进入第三阶段并且提供正确证书的攻击者通过验证
- 应用程序可能会信任由第二阶段处理的一些数据，但攻击者能够在第二阶段操控这些数据，提供一个不同于第一阶段的值
- 应用程序可能认为每个阶段的用户身份不会发生变化，因此，它并不在每个阶段明确确认用户身份
- 如果有数据不止提交一次，深度在另一个阶段提交一个不同的值，看看是否仍然能够成功登录
- 特别注意任何通过客户端传送、并不由用户直接输入的数据
3.不安全的证书存储
- 明文存储密码
- 简单加密
D.保障验证机制的安全
1.考虑：
- 应用程序所提供功能的安全程度
- 用户对不同类型的验证控制的容忍和接受程度
- 支持一个不够友好的用户界面系统所需的成本
- 竞争性解决方案相对于应用程序可能产生的收入方面的金融成本或它所保护资产的价值
2.使用可靠的证书
- 应强制执行适当的最小密码强度要求
- 应使用唯一的用户名
- 系统生成的任何用户名和密码应具有足够的随机性
- 允许用户设置足够强大的密码
3.安全处理证书
- 应以不会造成非授权泄露的方式创建、保存和传送所有证书
- 应使用公认的加密技术保护客户端与服务器间的所有通信
- 如果认为最好在应用程序的不需验证的区域使用HTTP，必须保证使用HTTPS加载登录表单，而不是在提交登录信息时才转换到HTTPS
- 只能使用POST请求向服务器传输证书
- 所有服务器-客户端应用程序组件应这样保存证书：即使攻击者能够访问应用程序数据库中存储的所有相关数据，他们也无法轻易恢复证书的原始值
- 客户端“记住我”功能应仅记忆如用户名之类的非保密数据
- 应使用一种密码修改工具，要求用户定期修改其密码
- 如果以非正常交互的形式向新建账户分配证书，应以尽可能安全的形式传送会话，并设置时间限制，要求用户在第一次登录时更改证书，并告诉用户在初次使用后销毁通信渠道
- 应考虑在适当的地方使用下拉菜单而非文本字段截取用户的一些登录信息
4.正确确认证书
- 应确认完整的密码
- 应用程序应在登录处理过程中主动防御无法预料的事件
- 应对验证逻辑的伪代码和实际的应用程序源代码进行仔细的代码审查，以确定故障开放条件之类的逻辑错误
- 如果应用程序执行支持用户伪装功能，应严格控制这种功能，以防止攻击者滥用它获得未授权访问
- 应对多阶段登录进行严格控制，以防止攻击者破坏登录阶段之间的转换关系
- 如果在登录过程中需要回答一个随机变化的问题，请确保攻击者无法选择回答的问题
5.防止信息泄露
- 应用程序使用的各种验证机制不应通过公开的消息，或者通过从应用程序的其他行为进行推断
- 应由单独一个代码组件使用一条常规消息负责响应所有失败的登录尝试
- 如果应用程序实行某种账户锁定以防止蛮力攻击，应小心处理以防造成信息泄露
- 如果应用程序支持自我注册，那么它能够以两种方式防止这种功能被用于枚举现有用户名：不允许自我选择用户名、可以使用电子邮件地址作为用户名
6.防止蛮力攻击
- 必须对验证功能执行的各种质询采取保护措施，防止攻击者企图使用自动工具响应这些质询
- 使用无法预测的用户名，同时阻止用户名枚举
- 一些对安全性要求极高的应用程序在检测到少数几次登录失败后应立即禁用该账户
- 使用验证码进行人机质询
7.防止滥用密码修改功能
- 应用程序应始终执行密码修改功能，允许定期使用的密码到期终止并允许用户修改密码
- 只能从已通过验证的会话中访问该功能
- 不应以任何方式直接提供用户名，也不能通过隐藏表单字段或cookie提供用户名
- 作为一项高级防御措施，应用程序应对密码修改功能加以保护，防止攻击者通过其他安全缺陷，如会话劫持漏洞、跨站点脚本，甚至是无人看管的终端获得未授权访问
- 为防止错误，新密码应输入两次
- 该功能应阻止可能针对主要登录机制的各种攻击
- 应使用非常规方式通知用户其密码已被修改，但通知消息不得包含用户的旧证书或新证书
8.防止滥用账户恢复功能
- 当用户遗忘密码时，许多安全性至关重要的应用程序通过非常规方式完成账户恢复
- 精心设计的密码恢复机制需要防止账户被未授权方殹 ，避免给合法用户造成任何使用中断
- 绝对不要使用密码“暗示”之类的特性
- 通过电子邮件给用户发送一个唯一的、具有时间限制的、无法猜测的一次性恢复URL是帮助用户重新控制账户的最佳自动化解决方案
9.日志、监控与通知
- 应用程序应在日志中记录所有与验证有关的事件
- 应用程序的实时警报与入侵防御功能应对验证过程中的异常事件进行处理
- 应以非常规方式向用户通报经常发生的安全事件
七、攻击会话管理
A.状态要求
1.执行会话最简单、最常见的方法就是向每名用户发布一个唯一的会话令牌或标识符。用户在随后向应用程序提出的每一个请求中提交这个令牌。大多数情况下使用Cookie
2.存在的主要漏洞：
- 会话令牌生成过程中的薄弱环节
- 在整个生命周期过程中处理会话信息的薄弱环节
3.会话替代方案：HTTP验证（基本、摘要、NTLM验证等）、无会话状态机制
B.会话令牌生成过程中的薄弱环节
1.令牌有一定含义
2.令牌可预测
- 隐含序列
- 时间依赖
- 生成的数字随机性不强
- 测试随机性强度：Burp Sequencer
3.加密令牌
- ECB密码：对称加密算法，明文分组与密文分组完全对应，
- CBC密码：在加密每个明文分组前，将它与前一个密文分组进行XOR运算（DES和AES）
C.会话令牌处理中的薄弱环节
1.在网络上泄露令牌
- 在登录阶段使用HTTPS但在会话其他阶段使用HTTP
- 在站点中预告通过验证的区域（如首页）使用HTTP，但从登录页开始转换到HTTPS，很多情况下应用程序在用户访问时就给予令牌，而且登录后也不会修改
- 用户对URL修改仍能通过HTTP进行登录
- 静态内容使用HTTP
2.在日志中泄露令牌
3.令牌-会话映射易受攻击
- 允许同一个用户账户同时分配几个有效的令牌
- 静态令牌
4.会话终止易受攻击
- 应用程序不执行退出功能
- 仅删除了cookie
5.客户端暴露在令牌劫持风险之中
- 跨站脚本攻击查询用户cookie
- 跨站请求伪造（CSRF）
6.宽泛的cookie范围
D.保障会话管理的安全
1.生成强大的令牌
- 使用数量极其庞大的一组可能值
- 包含强大的伪随机源，确保令牌以无法猜测的方式平均分布在可能值范围内
- 合并一些信息作为熵源：来源IP及接收请求的端口号、请求中的User-Agent消息头、请求时间（毫秒）
- 使用适当的散列算法（SHA-256等）
2.在整个生命周期保障令牌安全
- 令牌只能通过HTTPS传送，最好全站HTTPS，如不行，cookie加上secure标识，将敏感内容的请求重定向到HTTPS
- 绝不能在URL中传送会话令牌
- 应总是执行退出 功能
- 会话牌非活动大癫大废一段时间后，应执行会话终止
- 应防止并行登录，一名用户登录就发布一个新令牌并废止其他属于该用户的令牌
- 如果应用程序包含任何可以查看会话令牌的管理或诊断功能，应对这种功能加以严密保护，以防止未授权的访问
- 应尽可能限定应用程序会话cookie的域和路径范围
- 应严格审查应用程序的代码库，以确定并删除任何跨站点脚本漏洞
- 不应接受用户提交，但服务器并不认可的任意令牌
- 在执行转账之类的重要操作之前，要求进行两步确认或重新验证可有效防御跨站点请求伪造和其他会话攻击
- 不完全依赖HTTP cookie传送会话令牌
- 成功验证后总是建立一个新的会话
3.每页面令牌
- 每次用户请求一个页面，都会建立一个新的页面令牌
- 会给“前进”“后退”等导航造成影响
4.日志、监控与警报
- 应用程序应监控包含无效令牌的请求
- 很难完全阻止针对会话令牌的蛮力攻击，在收到大量包含无效令牌的请求时将其来源IP屏蔽一段时间
- 即使无法立即有效防止针对会话的蛮力攻击，但保留详细的日志并向管理员发出警报仍然有用
- 只要有可能，应向用户警告与会话有关的反常事件
5.反应性会话终止
- 只要收到反常请求，就马上终止会话
八、攻击访问控制
A.常见漏洞
1.访问控制三大类
- 垂直访问控制，允许各种类型的用户访问应用程序的不同功能
- 水平访问控制允许用户访问一组相同类型的、内容极广泛的资源
- 上下文相关的访问控制可确保基于应用程序当前的状态，将用户访问仅限于所允许的内容
2.完全不受保护的功能
3.基于标识符的功能
4.多阶段功能：最后步骤没有验证前面的内容，直接提交最后一张表单实现
5.静态文件：直接给有意义的链接，无法通过程序有效控制权限
6.平台配置错误
7.访问控制方法不安全
B.攻击访问控制
1.使用不同用户账户进行测试
2.测试多阶段过程
3.通过有限访问权限进行测试
4.测试“直接访问方法”
5.测试对静态资源的控制
6.测试对HTTP方法实施的限制
C.保障访问控制的安全
1.几种明显的缺陷：
- 不要认为用户不知道用于指定应用程序资源的URL或标识符就无法访问这些资源
- 不要信任任何用户提交的表示访问权限的参数
- 不要认为用户将按设定的顺序访问应用程序页面
- 不要相信用户不会篡改通过客户端传送的数据
2.有效访问控制的一些最佳方法：
- 仔细评估并记录每个应用程序功能单元的访问控制要求
- 通过用户会话做出所有访问控制决定
- 使用一个中央应用程序组件检查访问控制
- 通过这个组件处理每一个客户端请求，确认允许提出请求的用户访问他请求的功能和资源
- 使用编程技巧确保前面的方法没有例外
- 对于特别敏感的功能，例如管理页面，可以通过IP地址进一步限制访问
- 如果静态内容需要得到保护，可以通过向执行相关访问控制逻辑服务器端动态页面传送一个文件名，间接访问，或者通过HTTP验证或应用程序服务器的其他特性隐藏进入的请求
- 无论何时通过客户端传送，指定用户所希望访问资源的标识符都容易遭到篡改
- 对于安全性很关键的应用程序功能考虑对每笔交易执行重复验证和双重授权
- 记录每一个访问敏感数据或执行敏感操作的事件
3.多层权限模型
- 可根据在应用程序服务器层面定义的用户角色，使用应用程序服务器对完整URL路径实施访问控制
- 当执行其他用户的操作时，应用程序可使用一个不同的数据库账户。
- 应使用一个权限表，对数据库中不同的数据库表执行严格的访问控制
- 用于运行基础设施中每个组件的操作系统账户只需分配组件实际需要的最低权限
4.访问控制概念
- 编程控制（programmatic control）数据库权限矩阵保存在一个数据库表中，并以编程的形式来做出访问控制决定
- 自主访问控制（Discretionary Access Control,DAC）。管理员可将自己的权限分配给其他与拥有特殊资源有关的用户
- 基于角色的访问控制（Role-Based Access Control,RBAC）使用许多命名的角色，每个角色拥有各不相同的特殊权限；每个用户分配一个这样的角色
- 声明式控制（declarative control）应用程序使用有限的数据库账户访问数据库。对不同的用户群体使用不同的账户，每个账户分配到执行该群体所允许执行的操作所必需的最低权限。
九、攻击数据存储区
A.注入解释型语言
1.解释型语言（interpreted language）是一种在运行时由一个运行时组件（runtime component）解释语言代码并执行其中包含的指令的语言
2.编译型语言（compiled language）代码在生成时转换成机器指令，然后在运行时直接由使用该语言的计算机处理器执行这些指令
3.基于解释型语言的执行方式，产生了一系统代码注入（code injection）漏洞。任何有实际用途的应用程序都会收到用户提交的数据，因此，由解释器处理的数据实际上是由程序员编写的代码和用户提交的数据共同组成的。
B.防御SQL注入
1.部分有效的防御措施
- 将用户输入中的任何单引号配对并对它们转义
- 使用存储过程
2.参数化查询
- 应用程序指定查询结构，为用户输入的每个数据预留占位符
- 应用程序指定每个占位符内容
- 应当每一个数据库查询中使用参数化查询
- 插入查询中每一种数据都应适当进行参数化
- 参数占位符不能用于指定查询中表和列的名称
- 参数占位符不能用于查询的任何其他部分，如ORDER BY或任何SQL关键字，因为它们属性查询结构的一部分
3.深层防御
- 当访问数据库时，应用程序应尽可能使用最低权限的帐户
- 许多企业数据库包含大量默认功能，可被能够执行任意SQL语句的攻击者利用
- 应评估、测试并及时安装供应端发布的所有安全补丁
十、测试后端组件
A.注入操作系统命令
1.防止OS命令注入：
- 完全避免直接调用操作系统命令；
- 实话严格的防御来防止漏洞发生（白名单）；
- 应用程序应使用命令API通过它的名称和命令行参数启动特殊的进程，而不是向支持命令链接与重定向的shell解释器传送命令字符串
2.防止脚本注入漏洞：
- 避免将用户提交的输入或者来自用户的数据传送给任何动态执行或包含函数；
- 必须传送的话白名单过滤或根据一组已知无害的字符检查在输入中使用的字符
B.操作文件路径
1.Web应用程序根据用户在请求中提交的参数向文件系统读取或写入数据，攻击者可以提交专门设计的输入，使应用程序访问开发者不希望它访问的文件。这类漏洞称为路径遍历漏洞（path traversal）。
2.防止路径遍历漏洞：
- 避免向任何文件系统API传送用户提交的数据
- 对用户提交的文件名进行相关解码与规范化之后，应检查文件名是否包含路径遍历序列（使用反斜杠或斜线）或空字节
- 应用程序 应使用一个硬编码的、允许访问的文件类型列表，并拒绝任何访问其他文件类型的请求
- 对用户提交的文件名进行一切必要的过滤后，应使用适当的文件系统API确认是否一切正常，确认文件是否位于指定的目录中
3.PHP要注意include()文件包含漏洞，可包含远程文件
C.注入XML解释器
1.防范：过滤XML元字符，主要<、>和/
D.注入后端HTTP请求
1.服务器端HTTP重定向：攻击者可以通过这种方法指定任意资源或URL，然后再由后端应用程序服务器请求这些资源或URL
2.HTTP参数注入（HPI）：攻击乾可以通过这种方法在应用程序服务器提出的后端HTTP请求中注入任意参数。如果攻击者注入后端请求中已存在的参数，就可以利用HTTP参数污染（HPP）攻击覆盖服务器指定的原始参数值。
E.注入电子邮件
1.防止：
- 应根据一个适当的正则表达式检查电子邮件地址（拒绝所有换行符）
- 消息主题不得包含任何换行符号，并应实施适当的长度限制
- 如果消息内容被一个SMTP会话直接使用，那么应禁止使用仅包含一个点字符的消息行
十一、攻击应用程序逻辑
A.逻辑缺陷的本质
1.代码中的简单错误，以及几种应用程序核心组件互操作方面的极其复杂的漏洞
2.逻辑缺陷没有共有的“签名”，许多时候表现为设计者或开发者在思考过程中做出的特殊假设存在明显或隐含的错误
B.避免逻辑缺陷
1.确保将应用程序各方面的设计信息清楚、详细地记录在文档中，以方便其他人了解设计者做出的每个假设
2.要求所有源代码提供清楚的注释：
- 每个代码组件的用途和预计用法
- 每个组件对它无法直接控制的内容做出的假设
- 利用组件的所有客户端代码引用 ，清楚记录它的效果有助于阻止在线注册功能中的逻辑缺陷
3.在以安全为中心的应用程序设计审核中，考虑在设计过程中做出的每一个假设，并想象假设被违背的每种情况
4.在以安全为中心的代码审查中，从各个角度考虑以下两个因素：应用程序如何处理用户的反常行为和输入；不同代码组件与应用程序功能之间的相互依赖和互操作可能造成的不利影响
5.始终记住，用户可以控制请求每一个方面的内容
6.根据会话确定用户的身份与权限。不要根据请求的任何其他特性对用户的权限做出任何假设
7.当根据用户提交的数据或用户执行的操作更新会话数据时，仔细考虑更新后的数据可能会给应用程序的其他功能造成什么影响
8.如果一项搜索功能可用于查询禁止某些用户访问的敏感数据，确保那些用户无法利用该项功能、根据搜索结果推断出有用的信息
9.如果应用程序根据数字交易限额执行检查，在处理用户输入前，必须对所有数据实话严格的规范化与数据确认
10.如果应用程序根据订购商品的数量决定折扣，必须保证在实际应用折扣前确定订单
11.如果在将用户提交的数据提交给可能易于受到攻击的应用程序组件前，对其进行转义处理，一定要记得对转义字符本身进行转义，否则整个确认机制可能会遭到破坏
12.始终使用适当的存储方法保存与某位用户有关的数据
十二、攻击其他用户
A.XSS的分类
1.反射型XSS漏洞（一阶跨站脚本）
- 提取用户提交的输入并将其插入到服务器响应的HTML代码中，这是XSS漏洞的一个明显特征；如果应用程序没有实施任何过滤或净化措施，那么它很容易受到攻击。利用这种漏洞需要设计一个嵌入式JavaScript代码的请求，随后 这些代码又被反射到任何提出请求的用户，因而它被称作反射型XSS
2.保存型XSS漏洞（二阶跨站脚本）
- 如果一名用户提交的数据被保存在应用程序中（通常保存在一个后端数据库中），然后不经适当过滤或净化就显示给其他用户，此时就会出现这种漏洞。
- 与反射型的区别：反射型需要用户访问指定URL，保存型威胁更大
3.基于DOM的XSS漏洞
- 用户请求一个经过专门设计的URL，它由攻击者提交，且其中包含嵌入式JavaScript
- 服务器的响应中并不以任何形式包含攻击者的脚本
- 当用户的浏览器处理这个响应时，上述脚本得以处理
B.进行中的XSS攻击
1.XSS攻击有效载荷
- 虚拟置换：在一个web应用程序页面注入恶意数据，从而向应用程序用户传送误导性信息。包括简单向站点中注入HTML标记，或者使用脚本注入精心设计的内容和导航，攻击者实际上并没有修改保存在目标web服务器上的崆，而是利用应用程序处理并显示用户提交的输入方面的缺陷实现置换
- 注入木马：在易受攻击的应用程序中注入实际运行的功能，旨在欺骗终端用户执行某种有害操作（如输入敏感数据），随后将它们传送给攻击者
- 诱使用户执行操作
- 利用信任关系：历史表单缓存数据等，推荐或要求用户把其域名添加到“可信站点”内，调用ActiveX控件等
- 扩大客户端攻击范围
2.XSS攻击的传送机制
- 传送反射型与基于DOM的XSS攻击：电邮、即时消息、第三方站点、付费链接（广告）
- 保存型XSS攻击：带内（通过网站主web应用程序提交恶意数据）、带外（通过其他渠道向应用程序提交漏洞数据）
- 链接XSS与其他攻击：XSS漏洞有时可与其他漏洞链接在一起，造成破坏性的后果
C.防止XSS攻击
1.防止反射型与保存型XSS漏洞
- 用户可控制的数据未经适当确认与净化就被复制到应用程序的响应中，这是造成反射型与保存型XSS漏洞的根本原因
- 3个因素：确认输入；确认输出；消除危险的插入点；
- 确认输入：数据不是太长；数据仅包含某组合法字符串；数据与一个特殊的正则表达式相匹配；
- 确认输出：” ，’，&，<，>
- 消除危险的插入点：应尽量避免直接在现在的JS中插入用户可控制的数据；如果标签属性接受URL作为它的值，应用程序应避免嵌入用户输入；如果攻击者通过插入一个相关指令，或者因为应用程序使用一个请求参数指定首选的字符集，因而能够控制应用程序响应的编码类型，这些情况也应该加以避免。
- 允许有限的HTML：仅允许有限的HTML子集，避免提供任何引入脚本代码的方法。采用白名单。
- 输入与输出确认机制应特别小心，尽量避免任何可能导致攻击者避开确认的漏洞，应在实施相关规范化后再对数据进行过滤与编码，而且之后不得对数据实施进一步的规范化，还必须保证其中存在的空字节不会地它的确认造成干扰
十三、攻击用户：其他技巧
A.诱使用户执行操作
1.请求伪造
- 这种类型的攻击也称为会话叠置（session riding），它们与会话劫持攻击密切相关，在攻击过程中，攻击者截获一名用户的会话令牌，因而能够“作为”该用户使用应用程序
- 本站点请求伪造（On-Site Request Forgery，OSRF）是一种利用保存型XSS漏洞的常见攻击有效载荷。
- 跨站点请求伪造（CSRF），攻击者只需创建一个看似无害的网站，致使用户的浏览器直接向易受攻击的应用程序提交一个请求，执行某种有利于攻击者的“无意”操作
- 防止csrf漏洞：标准方法是将HTTP cookie与其他追踪令牌的方法相结合，采用其他通过HTTP隐藏表单字段传输的令牌，在每次提交请求时，应用程序除确认会话cookie外，还核实表单是否传送了正确的令牌。
- 通过XSS漏洞可能突破反CSRF防御
2.UI伪装
- UI伪装通常也称为“点击劫持”（clickjacking）、“键击劫持”（strokejacking），攻击者的网页会将目标应用程序加载到其页面上的iframe中。实际上，攻击者会用其他界面覆盖目标应用程序的界面。
- “破坏框架”防御：是指每个相关的应用程序页面都会运行一段脚本来检测自己是否被加载到iframe中，如果是，则尝试“破坏”该iframe，如重定向到错误页面或拒绝显示界面（可以绕过）
- 防止UI伪装：使用X-Frame_Options响应消息头，deny指示浏览器防止页面被嵌入框架，值sameorigin指示浏览器防止第三方域执行“嵌入框架”操作
B.跨域捕获数据
1.通过注入HTML捕获数据
2.通过CSS捕获数据
3.JavaScript劫持：函数回调、JSON、变量分配、E4X
4.防止JavaScript劫持：
- 执行敏感操作的请求，应用程序应使用标准的反CSRF防御来阻止跨域请求返回任何包含敏感数据的响应
- 客户端可以使用XMLHttpRequest检索原始响应并进行其他处理，然后再将其作为脚本执行
- 如果应用程序仅接受POST请求访问可能易受攻击的脚本代码，它就能够阻止第三方站点将它们包含在<script>标签内
C.同源策略深入讨论
1.同源策略与浏览器扩展
- 同源策略与Flash
- 同源策略与Silverlight
2.同源策略与HTML5
- 可能允许外部域进行双向交互
- 攻击者可以在其控制的域上指定一个URL，从而对应用程序用户实施客户端远程文件包含攻击
3.通过代理服务应用程序跨域
D.其他客户端注入攻击
1.HTTP消息头注入：常见于Location与Set-Cookie消息头中
- 利用消息头注入漏洞
- 注入cookie
- web站点置换、脚本注入、任意重定向、针对ActiveX控件的攻击等
- HTTP响应分割
- 防止消息头注入漏洞：最有效的方法是杜绝将用户控制的输入插入到应用程序返回的HTTP消息头中；输入确认，对插入的数据进行尽可能严格的确认；输出确认，对插入到消息头中的所有数据进行过滤，检测可能的恶意字符，任何ASC2码小于0x20的字符都应被视为可疑的恶意字符
2.cookie注入
实施：
- 某些应用程序的功能在请求参数中使用一个名称和值，并在响应的cookie中设置该名称和值
- 如果存在HTTP消息头注入漏洞，就可以利用此漏洞注入任意Set-cookie
- 可以利用相关域中的XSS漏洞在目标域上设置一个cookie
- 可以利用主动中间人攻击在任意域上设置cookie，即使目标应用程序仅使用HTTPS并将cookie标记为安全
- 攻击目标用户：
-
- 由于cookie通常仅由应用程序本身设置，因此它们会受客户端代码信任
- 除将反CSRF令牌与用户会话关联外，一些应用程序还在cookie和请求参数中放置该令牌
- 攻击者可以利用某个记录性XSS漏洞，通过针对登录功能的CSRF攻击使用户登录攻击者的账户
- 会话固定：如果应用程序在用户首次访问时为每一名用户建立一个匿名会话，然后登录后该会话升级为通过验证的会话
3.开放式重定向漏洞
- 防御：
-
- 从应用程序中删除重定向页面，用直接指向相关目标URL链接替代指向重定向页面的链接
- 建立一个包含所有有效重定向URL的列表
- 应用程序应在所有重定向中使用相对URL，重定向页面应严格确认它收到的URL为相对URL
- 应用程序应该在所有重定向中使用相对于WEB根目录的URL
- 应用程序应对所有重定向使用绝对URL，重定向页面在发布重定向之前 ，应确认用户提交的URL以你的域名开头
4.客户端SQL注入
5.客户端HTTP参数污染
E.本地隐私攻击
1.持久性cookie
2.缓存Web内容
3.浏览历史记录
4.自动完成
5.Flash本地共享对象
6.Silverlight独立存储
7.Internet Explorer userData
8.HTML5本地存储机制：会话存储、本地存储、数据库存储
9.防止本地隐私攻击：不要将网页内容缓存（响应头参数Cache-Control、Pragma、Expires）
F.攻击ActiveX控件
1.防止ActiveX漏洞
- 应对控件进行以安全为中心的源代码审查与渗透测试，以确定缓冲区溢出之类的漏洞
- 控件不得暴露任何使用用户可控制的输入调用外部文件系统或操作系统、本质上存在风险的方法
G.攻击浏览器
1.记录键击：利用js
2.窃取浏览器历史记录与搜索查询
3.枚举当前使用的应用程序
4.商品扫描
5.攻击其他网络主机
6.利用非HTTP服务
7.利用浏览器漏洞
8.DNS重新绑定
9.浏览器利用框架
10.中间人攻击
十四、定制攻击自动化
A.应用定制自动化攻击
1.枚举标识符：大多数应用程序使用各种名称与标识符代指数据和资源，如账号、用户名和文档ID
2.获取数据：通过提出专门设计的特殊请求，利用各种Web应用程序漏洞，测试员就可以从应用程序中提取到有用的或敏感的数据
3.Web应用程序模糊测试：当描述探查常见Web应用程序漏洞时，能够见到大量的示例，在这些示例中，探查漏洞的最佳方法是提交各种反常的数据和攻击字符串，然后检查应用程序的响应，查找任何表示可能存在漏洞的异常现象
B.枚举有效的标识符
1.探测“触点”：HTTP状态码、响应长度、响应主体、Location消息头、Set-Cookie消息头、时间延迟
2.JAttack
C.获取有用的数据
D.常见漏洞模糊测试
1.一些漏洞会通过特别明显的应用程序行为表现出来，这些行为包括特定的错误消息或HTTP状态码
E.整合全部功能：Burp Intruder
F.实施自动化的限制
1.会话处理机制
- 测试请求时，应用程序会出于防御或其他目的，终止用于测试的会话，剩下的测试也随之失效
- 某个应用程序功能使用必须随每个请求提供的不断变化的令牌
- 所测试的请求在多阶段过程中显示。只有在首先提出一系列其他请求，应用程序进入适当的状态时，该请求才会得到正确处理
2.CAPTCHA控件
十五、利用信息泄露
A.利用错误消息
1.错误消息脚本
2.栈追踪
3.详尽的调试消息
4.服务器与数据库消息
5.使用公共信息：开源代码
6.制造详尽的错误消息
B.收集公布的信息
1.应用程序可能会公布对攻击者有利的信息：
- 公布的信息在设计上属于应用程序核心功能的一部分
- 公布的信息会无意中给其他功能造成负面影响
- 由仍然存在于当前应用程序中的调试功能泄露令牌
- 由于存在某个漏洞而导致信息泄露
2.应用程序可能向用户公布的敏感信息：
- 用户个人资料
- 用户当前使用的密码
- 包含在日志文件中的信息
- 在客户端的HTML源代码中与应用程序有关的细节
C.使用推论
1.部分行为判断：
- 注册功能根据已存在的用户名枚举用户名
- 搜索引擎允许推断出未获授权就可直接查看的编入索引的文档内容
2.根据某种对攻击者有利的事实，如程序执行时间的不同
D.防止信息泄露
1.使用常规错误消息：500.html 404.html这些
2.保护敏感信息：只要有可能，应禁止应用程序公布对攻击者有利的信息，否则，在不必要时也不得披露现有数据
3.尽量减少客户端信息披露：只要有可能，应删除或修改服务旗标，避免泄露特定软件版本等信息。另外，还应删除部署在当前生产环境中的客户端代码中的所有注释
十六、攻击本地编译型应用程序
A.缓冲区溢出漏洞
1.如果应用程序将用户可控制的数据复制到一个不足以容纳它们的内存缓存区中，就会出现缓冲区溢出漏洞
2.栈溢出：如果应用程序在未确定大小固定的缓冲区容量足够大这前，就使用一个无限制的复制操作（如C语言中的strcpy）将一个大小可变的缓冲区复制到另一个大小固定的缓冲区中，往往就会造成缓冲区溢出
2.堆溢出：与栈溢出不同的是溢出的目标缓冲区分配在堆上，而不是栈上
3.“一位偏移”漏洞：如果编程错误使得攻击者可以在一个被分配的缓冲区之后写入一个字节（或少数几个字节），就会发生这种特殊的溢出漏洞
4.查找缓冲区溢出漏洞：向一个确定目标发送较长的字符串并监控反常结果；即使实施了常规过滤，溢出可能依然存在；长度足够短、能够避开这种过滤的字符串也可能触发溢出；
B.整数漏洞
1.整数溢出：当对一个整数值进行操作时，如果整数大于它的最大可能值或小于它的最小可能值，就会造成整数溢出漏洞
2.符号错误：如果应用程序使用有符号和无符号的整数来表示缓冲区的长度，并且在某个地方混淆这两个整数，或者将一个有符号的值与无符号的值进行直接比较，或者向一个仅接受无符号的值的函数参数提交有符号的值，都会出现符号错误
3.查找整数型漏洞
- 应用程序通过查询字符串参数、cookie或消息主体，以正常形式提交整数值。这时，表示一个同样被提交的字符串长度的字段是我们测试的主要目标
- 应用程序可能提交嵌入到二进制数据巨对象中的整数值
C.格式化字符串漏洞
1.如果用户可控制的输入被当做格式化字符串参数提交给一个接受可能被滥用的格式说明符的函数（如C语言中的printf系列函数），就会产生格式化字符串漏洞
2.查找格式化字符串漏洞：在远程应用程序中探查格式化字符串漏洞的最有效方法是，提交包含各种格式说明符的数据，并监控应用程序的任何反常行为
十七、攻击应用程序架构
A.分层架构
1.攻击分层架构
- 利用层之间的信任关系：各层之间彼此信任，但如果遭受攻击，这种假设就会被打破
- 破坏其他层：如果不同层之间没有完全隔离，那么攻破一个层就可以直接破坏另一个层实话的安全保护（所有层在一台服务器上）
- 访问解密算法：加密密钥与加密数据之间未进行逻辑隔离
- 使用文件读取访问权限提取MySQL数据
- 使用本地文件包含执行命令
2.保障分层架构的安全
- 尽量减少信任关系
-
- 应用程序服务器层应对特殊资源与URL路径实话基于角色的访问控制
- 数据库服务器层可以为应用程序的不同用户和操作提供各种权限的账户
- 所有应用程序组件可以使用拥有正常操作所需的最低权限 的操作系统账户运行
- 隔离不同的组件
-
- 一个层不得读取或写入其他层使用的文件
- 对不同基础架构组件之间的网络级访问进行过滤，仅允许需要与不同应用程序层彼此通信的服务
- 应用深层防御
-
- 应根据配置与漏洞补丁，把每台主机上的技术栈的各个层面进行安全强化
- 应对保存在任何应用程序层中的数据进行加密，以防止攻破该层的攻击者轻松获得这些数据
B.共享主机与应用程序服务提供商
1.攻击共享环境
- 针对访问机制的攻击：远程访问机制不安全、过于宽泛，访问机制可能没有对数据库进行适当的隔离
- 应用程序间的攻击：预留后门、易受攻击的应用程序间的攻击（SQL注入后查看所有共享库、文件漏洞查看所有路径等）、应用程序组件间的攻击
2.保障共享环境的安全
- 保障客户访问的安全
-
- 远程访问机制应实施严格的身份确认
- 仅准予个体用户最低的访问权限
- 如果使用一个定制的应用程序提供客户访问，该应用程序必须满足严格的安全需求
- 隔离客户功能
-
- 每名客户的应用程序应使用一个独立的操作系统账户访问文件系统，仅拥有读取与写入自己路径的权限
- 强大系统功能与命令的访问权限应仅限于操作系统等级
- 应在任何共享数据库中实施相同的保护措施
- 隔离共享应用程序中的组件：应特别注意共享日志与管理功能
十八、攻击Web服务器
A.Web服务器配置缺陷
1.默认证书
2.默认内容
- 调试功能：如apache自带的phpinfo()页面
- 样本功能：这么多服务器默认包含各种样本脚本与页面
- 强大的功能：许多Web服务器软件包含一些公众无法访问的强大功能，但终端用户通过某种方式可以访问到
- JMX：JBoss默认安装的JMX控制台是一种典型的强大默认内容
- Oracle应用程序：Oracle的PL/SQL网关
3.目录列表：直接显示了目录列表
4.WebDAV方法：指用于Web分布式创作与版本控制的HTTP方法集合
5.Web服务器作为代理服务器
- 攻击者可以使用该服务器攻击因特网上的第三方系统
- 攻击者可以使用代理服务器连接组织内部网络中的任意主机
- 攻击者可以使用代理服务器反向连接代理服务器主机上运行的其他服务
6.虚拟主机配置缺陷
7.保障Web服务器配置安全
- 如有可能，修改所有默认证书，删除不必要的账户
- 在Web根目录的相关路径上应用访问控制列表（Access Control List,ACL），或者对非标准端口设置防火墙，阻止公众访问管理接口
- 删除所有实现商业目的的并不完全需要的默认内容与功能
- 如果需要保留任何默认功能，尽量对其进行强化，禁用不必要的选项与行为
- 在所有Web目录中查找 目录列表。如有可能，在一个控制整个服务器的配置中禁用目录列表，或者每个目录提供index.html文件
- 除应用程序常用的方法外（通常为GET和POST），禁用其他所有方法
- 确保没有将Web服务器配置为代理服务器
- 如果Web服务器支持虚拟主机，确保在默认主机上实施服务器采用的所有安全强化措施
B.易受攻击的服务器软件
1.应用程序框架缺陷：.NET填充提示
2.内存管理漏洞：Apache mod_isapi悬挂指针、Microsoft IIS ISAPI扩展、Apache分块编码溢出、WebDAV溢出
3.编码与规范化漏洞：Apple iDisk Server路径遍历、Ruby WEBrick Web服务器、Java Web服务器目录遍历、Allaire JRun目录列表漏洞、Microsoft IIS Unicode路径遍历漏洞、避开Oracle PL/SQL排除列表
4.查找Web服务器漏洞：使用自动化工具发送大量的请求并监控表示已知漏洞的签名，Nessus等软件
5.保障Web服务器软件的安全
- 选择记录良好的软件
- 应用供应商发布的补丁
- 实施安全强化
-
- 禁用任何不需要的内置功能，配置剩下的功能尽可能严格地运行，与商业需求保持一致
- 如果应用程序由任何其他以本地代码开发的定制服务器扩展组成，则应考虑是否可以使用托管代码重新编写这些扩展。如果不能，则应确保托管代码环境先执行其他输入确认，然后再将输入传递给这些功能
- 可以对需要保留的这么多功能与资源进行重命名，以防止攻击者利用它们实施另一层障碍
- 在整个技术栈中应用最低权限原则
- 监控新的漏洞
- 使用深层防御
-
- 可以限制Web服务器访问其他自治应用程序组件
- 可以对进出Web服务器的流量实施严格的网络级过滤
- 可以使用一个入侵检测系统确定任何表明发生安全违反的反常网络活动
C.Web应用程序防火墙
1.以下问题通常会降低防火墙的用处：
- 如果防火墙过于严格地遵循HTTP规范，它可能会对应用程序服务器如果处理请求做出假设
- 请求通过防火墙后，在处理请求的过程中，应用程序服务本身可能会修改用户输入，如对其进行解码、添加转义字符，或过滤掉特定字符串
- 许多防火墙和IDS警报基于特定的常见攻击有效载荷
十九、查找源代码中的漏洞
A.代码审查方法
1.“黑盒”测试与“白盒”测试
- “黑盒”主要从外部攻击应用程序，并监控其输入与输出，而之前并不了解它的内部工作机制
- “白盒”需要分析应用程序的内部动作，查阅所有设计文档、源代码与其他资料
- 白盒代码审查可非常高效地发现应用程序中存在的漏洞
- 应该相互补充
2.代码审查方法
- 3个步骤：
-
- 从进入点开始追踪用户向应用程序提交的数据，审查处理这些数据的代码
- 在代码中搜索表示存在常见漏洞的签名，并审查这些签名，确定某个漏洞是否存在
- 对内存危险的代码进行逐行审查 ，理解应用程序逻辑，并确定其中存在的所有问题
- 需要仔细审查的功能组件：应用程序中的关键安全机制（验证、会话管理、访问控制与任何应用程序范围内的输入确认）、外部组件接口，以及任何本地代码
B.常见漏洞签名
1.跨站点脚本
2.SQL注入
3.路径遍历
4.任意重定向
5.OS命令注入
6.后门密码
7.本地代码漏洞：缓冲区溢出漏洞、整数漏洞、格式化字符串漏洞
8.源代码注释
C.Java平台
D.ASP.NET平台
E.PHP平台
1.allow_url_open可用于防止一些文件函数访问远程文件，5.2后的allow_url_include可防止在调用文件包含函数时指定远程文件，默认关闭
2.safe_mode指令要注意
F.Perl平台
G.JavaScript
1.审查JavaScript代码时，必须确保检查.js文件和在HTML内容中嵌入的脚本
2.重点审查读取基于DOM的数据以及写入或以其他方式修改当前文档的API（document.xxx,window.xxx,eval....）
H.数据库代码组件
1.MS-SQL与Sybase功能强大的存储过程，可以执行命令或访问注册表
2.用于访问文件系统的函数
3.连接到数据库以外的库的用户定义的函数
4.可访问网络的函数
I.代码浏览工具
1.Source Insight
二十、Web应用程序黑客工具包
A.Web浏览器
1.Internet Explorer：Http Watch、IEWatch
2.Firefox：Http Watch、FoxyProxy、LiveHTTPHeaders、Wappalyzer、Web Developer
3.Chrome：XSS Rays、cookie编辑器、Wappalyzer、Web Developer
B.集成测试套件
1.工作原理
- 拦截代理服务器：由于代理 服务器能够访问浏览器与目标Web服务器之间的双向通信，因而它能够拦截它们之间传送的每一条消息
- Web应用爬虫：请求Web页面，解析这些页面，从中查找指向其他页面的链接，然后向它们提出请求；继续这个过程，直到查明一个站点的全部内容
- 应用程序测试器
- Web漏洞扫描器
- 手动请求工具
- 会话令牌分析器
- 共享功能与实用工具
2.测试工作流程
- 通常，在测试漏洞时，可以从代理服务器拦截窗口、代理服务器历史记录或站点地图中选择项目；可以通过漏洞扫描器使用被动和主动技巧自动查找常见漏洞；可以使用令牌分析器工具测试会话cookie和其他令牌的随机性；
- 通常，对于许多类型的漏洞，测试员需要返回浏览器以作进一步调查，确认某个明显的漏洞是否确实存在，或测试正在进行的攻击
3.拦截代理服务器替代工具：Tamper Data、TamperIE
C.独立漏洞扫描器
1.扫描器探测到的漏洞
- 反射型跨站点脚本漏洞
- 一些SQL注入漏洞可通过某个签名确定
- 一些路径遍历漏洞可通过提交一个针对某个已知文件的遍历序列，然后在请求中搜索该文件是否出现 ，从而进行确定
- 直接目录列表可通过请求目录路径，然后寻找一个包含看似为目录列表的文本的响应
- 明文密码提交、范围宽泛的cookie、激活自动完成的表单等漏洞可通过审查应用程序提出的常见请求与响应有效确定
- 通常，使用不同的文件扩展名请求每个枚举出的资源，可以发现在主要的公布内容中没有提供链接的数据，如备份文件和资源文件
- 自动扫描器不能发现的一些漏洞：
-
- 不完善的访问控制
- 通过修改参数值给应用程序的行为造成影响的攻击
- 其他逻辑错误
- 应用程序功能设计方面的漏洞
- 会话劫持攻击
- 泄漏敏感信息
2.扫描器的内在限制
- Web应用程序的不同
- 扫描器不理解 语法
- 扫描器不会“即兴”处理
- 扫描器并无直觉
3.扫描器面临的技术挑战
- 验证与会话处理
- 危险的后果
- “个性化”功能
- 其他自动控制挑战
4.当前产品：Acunetix、AppScan、Burp Scanner、Hailstorm、NetSparker、N-Stalker、NTOSpider、Skipfish、WebInspect
5.使用漏洞扫描器
- 了解扫描器能够确定和不能够确定的漏洞类型
- 熟悉扫描器的功能，知道如何对其进行配置，对某个应用程序进行有效扫描
- 在运行扫描器之前全面了解目标应用程序，以充分利用扫描器的功能
- 了解抓取强大的功能和自动探查危险漏洞蕴含的风险
- 始终手动核实扫描器报告的所有潜在的漏洞
- 还要意识到，扫描器可能会造成极大的混乱，在服务器与IDS防御中留下大量“指纹”
D.其他工具
1.Wikto/Nikto：可确定服务器默认的或常见的第三方内容
2.Firebug
3.Hydra：是一种用途广泛的密码猜测工具
4.定制脚本
二十一、Web应用程序渗透测试方法论
1.根据所发现的有关目标应用程序的信息指导攻击方向：
- 在某一个阶段收集到的信息有助于返回到前一个阶段，以设计更有针对性的攻击
- 在应用程序的某个区域发现的一个关键漏洞可简化另对另一个区域的攻击
- 一些区域的测试结果有助于确定在其他区域可立即探查出的重复出现漏洞模式
2.一般规范
- 一些字符在HTTP请求的不同部分具有特殊的含义
-
- &用于分隔URL字符串与消息主体中的参数
- =用于分隔URL查询字符串与消息主体中每个参数的名称与值
- ?用于标记URL查询字符串的起始位置
- 空格用于在请求的第一行标记URL的结束位置
- 因为 表示一个编码的空格，要插入一个字面量 字符，必须 将其编码为+
- ;用于在Cookie消息头中分隔单个的cookie
- #用于在URL中标记片段标识符
- %在URL编码方案中作为前缀
- 当然 ，空字节与换行符等非打印字符必须使用它们的ASC2字符代码进行URL编码
- 需要注意，在表单中输入URL编码的数据通常会导致浏览器执行另一层编码
- 许多查找常见Web应用程序的测试需要发送各种专门设计的输入字符串，并监控应用程序的响应，从中搜索表示漏洞存在的反常现象
- 通常，应用程序会从前一个请求中收集一定量的状态，这会影响它们如何响应随后的请求
- 一些应用程序使用一种负载均衡的配置，其中连续的HTTP请求可能会被不同的后端服务器在WEB层、展现层、数据层或其他层处理
A.解析应用程序内容
1.搜索可见的内容：手动浏览与被动抓取获取整个应用程序信息
2.浏览公共资源：搜索引擎收录的内容等
3.发现隐藏的内容：确定应用程序如何处理不存在的资源、审查客户端代码
4.查找默认内容
5.枚举标识符指定的功能：如请求中的action=xxx
6.调试参数：修改隐藏参数提交请求测试
B.分析应用程序
1.确定功能：了解安全机制和功能机制
2.确定数据进入点：确定应用程序中引入用户输入的所有进入点、分析数据传输与编码机制
3.确定所使用的技术
4.解析受攻击页面：确定与每一项功能有关的常见漏洞
C.测试客户端控件
1.通过客户端传送数据：隐藏字段、cookie、预设参数、ASP.NET中的ViewState
2.客户端输入控件：长度限制、JavaScript确认、彬元素等
3.测试浏览器扩展组件：Java applet、ActiveX控件、Flash对象、Silverlight对象
D.测试验证机制
1.了解验证机制
- 确定应用程序使用的验证技术（如表单、证书或多元机制）
- 确定所有与验证有关的功能（如登录、注册、账户恢复等）
- 如果应用程序并未采用自动自我注册机制，确定是否可以使用任何其他方法获得几个用户账户
2.测试密码强度
3.测试用户名枚举
4.测试密码猜测的适应性：多次无效登录是否锁定
5.测试账户恢复功能：找回密码等
6.测试记住我功能
7.测试伪装功能
8.测试用户名唯一性
9.测试证书的可预测性
10.测试不安全的证书传输
11.检测不安全的证书分配
12.测试不安全的存储
13.测试逻辑缺陷
- 测试故障开放条件：检查用户证书的每一项功能，破坏逻辑进行不同参数提交
- 测试多阶段处理机制：修改提交顺序，查看隐藏表单域或cookie等
14.利用漏洞获取未授权访问
E.测试会话管理机制
1.了解会话管理机制
2.测试令牌的含义
3.测试令牌的可预测性
4.检查不安全的令牌传输
5.检查在日志中泄漏的令牌
6.测试令牌-会话映射
7.测试会话终止
8.测试会话固定
9.检查CSRF
10.检查cookie范围
F.测试访问控件
1.了解访问控制要求
2.使用多个账户测试
3.使用有限的权限测试
4.测试不安全的访问控制方法
G.测试基于输入的漏洞
1.模糊测试所有请求参数
2.测试SQL注入
3.测试XSS和其他响应注入
- 确定反射型请求参数
- 测试反射型XSS
- 测试HTTP消息头注入
- 测试任意重定向
4.测试OS命令注入
5.测试路径遍历
6.测试脚本注入
7.测试文件包含
H.测试特殊功能方面的输入漏洞
1.测试SMTP注入
2.测试本地代码漏洞
- 测试缓冲区溢出
- 测试整数漏洞
- 测试格式化字符串漏洞
3.测试SOAP注入
4.测试LDAP注入
5.测试XPath注入
6.测试后端请求注入
7.测试XXE注入
I.测试逻辑缺陷
1.确定关键的受攻击面：多阶段过程、重要的安全功能，如登录、信任边界的转换、检查和调整交易价格或数量
2.测试多阶段过程
3.测试不完整的输入
4.测试信任边界
5.测试交易逻辑
J.测试共享主机漏洞
1.测试共享基础架构之间的隔离
2.测试使用ASP主机的应用程序之间的隔离
K.测试Web服务器漏洞
1.测试默认证书
2.测试默认内容
3.测试危险的HTTP方法
4.测试代理功能
5.测试虚拟主机配置不当
6.测试Web服务器软件漏洞
7.测试Web应用程序防火墙
L.其他检查
1.测试基于DOM的攻击
2.测试本地隐私漏洞
3.测试脆弱的SSL加密算法
4.检查同源策略配置
M.检查信息泄露
