黑客攻防技术宝典――Web实战篇

Web应用程序安全的关键问题因素：1.不成熟的安全意识2.独立开发3.欺骗性的简化4.迅速发展的威胁形式5.资源与时间限制6.技术上强其所难Web应用程序使用三层相关联的安全机制处理用户访问：1.身份验证2.会话管理3.访问控制处理用户输入：1.输入的多样性2.输入处理方法：a)拒绝已知的不良输入b)接受已知的正常输入c)净化d)安全数据处理e)语法检查3.边界确认步骤：a)应用程序受到用户的登录信息b)应用程序执行一个SQL查询检验用户证书c)如果用户成功登录，应用程序再将用户资料中的某些数据传送给SOAP服务，经一步获得用户账户的有关信息d)应用程序在用户的浏览器中显示用户的帐户信息4.多步确认与规范化处理攻击者：1.处理错误2.维护审计日志3.向管理员发出警报4.应对攻击HTTP1.HTTP请求：每个HTTP请求的第一行都由三个以空格间隔的项目组成三个项目：1)一个说明HTTP方法的动词（最常用的是GET）2)被请求的URL3)使用的HTTP版本2.HTTP响应：每个HTTP响应的第一行都由三个以空格间隔的项目组成三个项目：1)使用的HTTP版本2)表示请求结果的数字状态码3)一段文本形式的“原因短语”，进一步说明响应状态3.HTTP方法：GET——获取资源POST——执行操作HEAD——与GET类似，但服务器不会在其响应中返回消息主体TRACE——诊断目的OPTIONS——要求服务器报告对某一特殊资源有效的HTTP方法PUT——试图使用包含在请求主体中的内容HTTP消息头1.常用消息头：Connection——用户告诉通信的另一端，在完成HTTP传输后是否关闭TCP/IP连接Content-Encoding——压缩响应以加快传输速度Content-Length——规定消息主体的字节长度Content-Type——规定消息主体的内容类型Transfer-Encoding——为方便通过HTTP传输而对消息主体使用的任何编码2.请求消息头：Accept——告诉服务器客户愿意接受哪些内容Accept-Encoding——告诉服务器客户愿意接受哪些内容编码Authorization——用于为一种内置HTTP身份验证向服务器提交证书Cookie——用于向服务器提交它以前发布的cookieHost——用于指定出现在被请求的完整URL中的主机名称If-Modified-Since——用于说明浏览器最后一次收到被请求的资源的时间If-None-Match——用于指定一个实体标记Referer——用于指示提出当前请求的原始URLUser-Agent——提供与浏览器或发生请求的其他客户端软件有关的信息3.响应消息头：Catch-Control——用于向浏览器传送缓存指令ETag——用于指定一个实体标签Expires——用户向浏览器说明消息主题内容的有效时间Location——用户在重定向响应中说明重定向目标Pragma——用户向浏览器传送缓存指令Server——提供所使用的Web服务器软件的相关信息Set-Cookie——用户向浏览器发布cookie，浏览器又在随后的请求中将其返回服务器——提供与服务器所支持的身份验证类型相关的信息状态码：1xx——提供信息2xx——请求被成功提交3xx——客户被重定向到其它资源4xx——请求包含错误5xx——服务器执行请求时遇到错误服务器端功能：1.脚本语言（PHP、VBScript、Perl）2.Web应用程序平台（ASP.NET、JAVA）3.Web服务器（Apache、IIS、NetscapeEnterprise）4.数据库（SQL、ORACLE、MySQL）客户端功能：HTML、超链接、表单、JavaScript、厚客户组件编码方案：URL编码、Unicode编码、HTML编码、Base64编码、十六进制编码解析应用程序：枚举内容和功能：1.Web抓取2.用户指定的抓取3.发现隐藏的内容4.应用程序页面与功能路径5.发现隐藏的参数分析应用程序：1.确定用户输入进入点2.确定服务器端技术：a)提取版本信息b)HTTP指纹识别c)文件扩展名d)目录名称e)会话令牌f)第三方代码组件3.确定服务器端功能：a)仔细分析请求b)推测应用程序的行为4.解析受攻击面通过客户端传送数据：1.隐藏表单字段2.HTTPCookie3.URL参数4.Referer消息头5.模糊数据6.ASP.NETViewState收集用户数据：HTML表单：1.长度限制2.基于脚本的确认3.禁用的元素收集用户数据：厚客户端组件1.Javaapplet（反编译Java字节码、字节码模糊处理）2.ActiveX控件（逆向工程、利用输出函数、修改由控件处理的输入、托管代码反编译）3.ShockwaveFlash对象安全处理客户端数据：1.通过客户传送数据2.确认客户生成的数据3.日志与警报攻击验证机制一、验证技术：1.基于HTML表单的验证2.多元机制3.客户SSL证书或智能卡4.HTTP基本和摘要验证5.使用NTML或Kerberors、整合Windows的验证6.验证服务二、验证机制设计缺陷：1.密码保密性不强：a)非常短或空白的密码b)以常用的字典词汇或名称为密码c)密码和用户名完全相同d)仍然使用默认密码2.蛮力攻击登录3.详细的失败消息4.证书传输易受攻击5.密码修改功能6.忘记密码功能7.记忆功能（“记住我”）8.用户伪装功能9.证书确认不完善10.非唯一性用户名缺陷：a)在注册阶段或随后修改密码的过程中，共享同一个用户名的两个用户可能碰巧选择相同的密码b)及时由于失败登录尝试次数方面的限制，在其他地方不可能实施这种攻击，攻击者仍然可以利用这种行为成功实施蛮力攻击）11.可预测的用户名12.可预测的初试密码13.证书分配不安全三、验证机制执行缺陷：1.故障开放登录机制2.多阶段登录机制中的缺陷：a)使得仅拥有部分正常登录所需各种证书的攻击者能够成功登录b)攻击者若能在不同登录阶段的转换过程中干扰这些标记，就可以更改应用程序的行为，让他们只需部分证书即可通过验证，或者提升其权限c)应用程序可能认为每个阶段的用户身份不会发生变化3.不安全的证书储存四、保障验证机制的安全：1.使用可靠的证书：a)强制执行适当的最小密码强度要求b)使用唯一的用户名c)系统生成的任何用户名和密码应具有足够的随机性d)允许用户设置足够强大的密码2.安全处理证书：a)以不会造成非授权泄露的方式创建、保存和传送所有证书b)使用公认的加密技术保护客户与服务器之间的所有通信c)只使用POST请求向服务器传输证书d)客户端“记住我”功能应仅记忆非保密类数据e)使用一种密码修改工具，定期修改密码f)考虑在适当的地方使用下拉菜单而非文本字段截取用户的一些登录信息3.正确确认证书：a)确认完整的密码b)在登录处理过程中主动防御无法预料的事件c)对验证逻辑的伪代码和实际的应用程序源代码进行仔细的代码审查d)严格控制用户伪装功能，防止攻击者滥用它获得未授权访问e)对多阶段登录进行严格控制4.防止信息泄露：a)应用程序使用的各种验证机制不应通过公开的消息，或者通过从应用程序的其他行为进行推断，来揭示关于验证参数的任何信息b)由单独一个代码组件使用一条常规消息负责响应所有的失败登录尝试5.防止蛮力攻击：a)必须对验证功能执行的各种质询采用保护措施，防止攻击者试图使用自动工具响应这些质询b)使用无法预测的用户名，同时阻止用户名枚举6.防止滥用密码修改功能:a)应用程序应始终执行密码修改功能，允许定期使用的密码到期终止并允许用户修改密码b)只能从已通过验证的会话中访问该功能c)不应以任何方式直接提供用户名，或通过隐藏表单字段或cookie提供用户名d)应用程序应对密码修改功能加以保护，防止攻击者通过其他安全缺陷获得未授权访问e)为防止错误，新密码应输入两次f)使用一条常规错误消息告知用户现有证书中出现的任何错误g)使用“带外”方式通知用户其密码已被修改7.防止滥用账户恢复功能:a)精心设计的密码恢复机制需要防止账户被未授权方攻破，避免给合法用户造成任何使用中断b)绝对不要使用密码“暗示”之类的特性c)通过电子邮件给用户发送一个唯一的、具有时间限制的、无法猜测的一次性恢复URL是帮助用户重新控制账户的最佳自动化解决方案d)为进一步防止未授权访问，可能会向用户提出一个次要质询，用户必须在使用密码重设功能前完成质询）8.日志、监控与通知:a)应用程序应在日志中记录所有与验证有关的事件b)应用程序的实时报警与入侵防御功能应对验证过程中的一场事件进行处理c)应以“带外”方式向用户通报任何重大的安全事件d)应以“带内”方式向用户通报经常发生的安全事件攻击会话管理执行会话的最简单、也是最常见的方法就是向每名用户发布一个唯一的会话令牌或标识符。1.会话管理机制中存在的两类漏洞：a)会话令牌生成过程中的薄弱环节b)在整个生命周期过程中处理会话令牌的薄弱环节2.会话替代方案a)HTTP验证b)无会话状态机制3.结构化令牌的组成成分：a)账户用户名b)应用程序用来区分账户的数字标识符c)用户的电子邮件地址d)用户在应用程序中所属的组或扮演的角色e)日期/时间戳f)一个递增或可预测的数字g)客户的IP地址4.会话令牌处理中的薄弱环节：1)在网络上泄露令牌：a)一些应用程序在登录阶段选择使用HTTPS保护用户证书的安全，但在用户会话的其他阶段转而使用HYYPb)一些应用程序在站点中预先通过验证的区域使用HTTP，但从登录页面开始转换到HTTPSc)即使应用程序在用户成功登录后发布一个新令牌，并从登录页面开始使用HTTPS，但如果用户通过单击验证区域中的一个连接、使用“后退”按钮或者直接输入URL，重新访问一个预先验证的页面d)一些应用程序对应用程序内的全部静态内容使用HTTPe)即使应用程序在每一个页面都使用HTTPS，有些情况下，用户的令牌仍然通过HTTP传送2)在日志中泄露令牌：a)用户浏览器的日志b)Web服务器的日志c)企业或ISP代理服务器的日志d)任何在应用程序主机环境中采用的反向代理的日志e)应用程序用户通过单击站外链接访问的任何服务器Referer日志3)令牌－会话映射易受攻击4)会话终止易受攻击5)客户暴露在令牌劫持风险之中：a)攻击者可通过跨站点脚本攻击查询用户的cookie，获得他们的会话令牌，然后将其传送给自己控制的任意服务器b)攻击者可以使用其他针对用户的攻击，以不同的方式劫持用户的会话6)宽泛的cookie范围5.保障会话管理的安全：（1）生成强大的令牌（2）在整个生命周期保障令牌的安全：a)令牌只能通过HTTPS传送b)绝不能在URL中传送会话令牌c)总是执行推出功能d)会话处于非活动状态一段时间后，执行会话终止e)防止并行登录f)尽可能限定应用程序会话cookie的域和路径范围g)严格审查应用程序的代码库，以确定并删除任何跨站点脚本漏洞h)不接受用户提交、但服务器并不认可的任何令牌i)在执行转帐之类的重要操作前，要求进行两步确认或重新验证j)不完全依赖HTTPcookie传送会话令牌k)成功验证后总是建立一个新的会话，以避免会话固定攻击的影响（3）日志、监控与警报攻击访问控制1.访问控制两大类：a)垂直访问控制b)水平访问控制2.常见的漏洞：a)完全不受保护的功能b)基于标识符的功能c)多阶段功能d)静态文件e)访问控制方法不安全3.保障访问控制的安全：（1）明显的缺陷：a)不要认为用户不知道用于指定应用程序资源的URL或标识符就无法访问这些资源b)不要信任任何用户提交的表示访问权限的参数c)不要认为用户将按设定的顺序访问应用程序页面d)不要相信用户不会篡改通过用户传送的数据（2）在Web应用程序中执行有效访问控制的最佳方法：a)仔细评估并记录每个应用程序功能单元的访问控制要求b)通过用户会话做出所有访问控制决定c)使用一个中央应用程序组件检查访问控制d)通过中央应用程序组件处理每个客户请求，确认提出请求的用户被允许访问他请求