A2-错误的认证和会话管理
攻击者 ？ 考虑匿名的外部攻击者，以及具有自己账户的用户，他们可能试图窃取他人帐户。同时业内人士像掩饰自己的行为 攻击响亮 可利用性 中等 攻击者使用用户认证或会话管理功能的泄漏或缺陷（例如，暴露的账号，密码，会话ID）来充当用户。 安全缺陷 流行性常见 技术影响 商业上影响 ？ 考虑受影响的数据或应用程序功能的商业价值。 同时考虑公众暴露漏洞对商业业务的影响。 检测难严重的影响 度适中 这些漏洞允许一些甚至所有的账户被攻击。一旦攻击成功，攻击者可以做受害者能做的任何事情。攻击的目标常常是特权账户。 开发人员常常建立自定义的认证和会话管理计划，但正确建立这些是很难的 因此，这些自定义计划常常在像退出、记忆、密码管理、超时、账户更新等领域出现漏洞。因为每一种实现都是独特的，所以寻找这些漏洞常常会非常困难。 我对劫持攻击脆弱么？
主要保护的资产是保护凭据和会话ID
1、 凭据在存储的时候总是用Hash函数或者加密保护？
2、 凭据可以被猜出或通过弱的帐户管理功能覆盖（例如，创建帐户，修改密码，找回密码，
弱会话ID）？
3、 会话ID是否暴露？
4、 会话ID对会话固定攻击脆弱？ 5、 会话ID超时或者用户退出登录？ 6、 会话ID在成功登陆后能否旋转？
7、 密码、会话ID、或者其它凭据只有通过安全协议传输层传输？ 更多细节请看ASVS要求领域的V2和V3. 我如何阻止这些东西?
对于一个组织的主要建议是提供给开发人员：
1、 一套强大的认证和会话管理控制。这种控制能力：
a)满足左右在OWASP应用安全认证标准所定义的认证和会话管理的要求。
b)提供一个简单的接口。考虑ESAP验证和用户APIS，可以效仿、使用、或者在上面构建应用。
2、强有力的措施也应避免XSS漏洞，这些漏洞可以用来窃取会话ID。见A3。 攻击场景例子
场景1：机票预订应用程序支持URL重写，把会话ID写在URL中：
http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii 一个在此站点验证通过的用户的想让他的朋友知道这笔交易。他将上面的链接通过邮件发送给他的朋友，但是不知道他会泄露自己的会话ID。当他的朋友使用这个链接时，会使用他的会话和信用卡
场景2：应用的超时事件没有被适当的设置。用户使用一个公共电脑访问站点。在没有点击注销登录的情况下，仅仅关闭了浏览器并且离开。攻击者在一个小时后使用同样的浏览器，这个浏览器让然认证通过。
场景3：内部或外部攻击者得到了系统的密码数据库的访问权限。用户的密码信息没有被加密，那么所有用户的密码会被攻击者获取
A3-跨站脚本
攻击者 ？ 考虑那些可以像你系统发送无法信任数据的人，包括外部用户，内部用户，和系统管理员 攻击向量 可利用性 中等 攻击者像目标翻译器发送简单文本格式来扰乱它的语法。几乎任何数据源都可以称为注射容器，包括外部数据源 安全漏洞 非常流行 检测简单 技术影响 影响中等 攻击者能在受害者浏览器上执行脚本来劫持用户会话、丑化网站、潜入恶意文本、重定向用户、通过恶意软件劫持用户的浏览器，等等 业务/商业影响 ？ 考虑受影响的数据或应用程序功能的商业价值。 同时考虑公众暴露漏洞对商业业务的影响。 XSS在Web应用中最常见的安全漏洞。当应用包含用户提供的数据像浏览器发送但没有适当的确认和分离这些内容时会发生XSS漏洞。但中常见的XSS漏洞1）存储2）映射3）基于DOM的XSS攻击。 通过测试或代码分析能相当简单地发现XSS漏洞。 我容易受XSS攻击么？
你需要确保所有用户提供的输入发送回浏览器，被包含在输出页面，正确地转义，或者是通过输入验证，验证是安全的之前，适当地分离。适当的输出编码，确保这样的输入始终被视
为在浏览器中的文本，而不是活动内容。IAJAX是被用来动态地更新页面，则应尽量使用安全的JavaScript API。对于不安全的JavaScript APIs，必须使用编码或验证。
自动工具可以自动的发现一些错误。但是，每一个应用用不同的浏览器端口解释器像and uses different browser side interpretJavaScript, ActiveX, Flash, and Silverlight,建立不同的输出页，使自动检测变得困难。因此，除了自动化的方法，完全覆盖需要手动代码审查和渗透测试的组合。
Web2.0技术像AJAX，使通过自动工具检测到XSS攻击变得更困难 我如何阻止XSS攻击
阻止XSS攻击，需要保证不信任的数据和动态浏览器内容相分离
1、 最佳选择是分离所有所有被写入基于HTML不可信数据。可以从 OWASP XSS Prevention
Cheat Sheet获得更多需要数据分离技术的细节。
2、一个建议是对“正”和“白名单”的输入进行适当的规范化验证，但不是一个完整的防御来抵御XSS攻击，因为很多应用在它们的输入需要特殊字符。这样的验证应该尽可能验证之前接受输入的长度，字符，格式，数据和业务规则。
3、想要更丰富的内容，可以靠刘OWASP的AntiSamy自动消毒库。 攻击案例
这个应用程序在建立下面的HTML片段时未使用验证或分离使用了不可信的数据：
(String)page+=\ 攻击者在他们的浏览器下修改参数’CC’为： '>'.
这导致了受害者的会话ID被发送到攻击者的站点，允许攻击者劫持用户现在的会话。 需要注意的是，攻击者也可以使用XSS击败任何应用程序可能采用的防御自动化CSRF。
A4-不正确的直接对象引用
攻击者 ？ 考虑你系统用户的类型。有的用户仅仅拥有访问特定系统数据的权限？ 攻击向量 可利用性 简单 攻击者，作为一个经系统授权的用户，简单地改变一个系统对象到另一个用户没有被授权对象的值。 这种访问会被批准么？ 安全漏洞 比较流行 检测简单 技术影响 影响中等 这些漏洞会使所有被参数引用的数据陷入危险。除非名称空间非常洗稀疏，攻击者可以很容易的访问该数据类型的所有可用数据。 业务/商业影响 ？ 考虑受影响的数据或应用程序功能的商业价值。 同时考虑公众暴露漏洞对商业业务的影响。 当生成网页时，应用程序经常使用实际名称或键的值。应用程序不总是验证用户被授权为目标对象。这导致一个不安全直接对象引用漏洞。测试者能轻松地通过操纵参数值来检测这种缺陷，并可以通过代码分析快速的验证用户是否被正确授权。 我容易收到攻击么？
最好的方法确定应用是否对不安全的直接对象引用是核实所有的对象引用具有适当的防御。要做到这一点，可以考虑：
1、 对于直接引用限制资源，此应用程序需要验证授权用户访问他们所要求的精确资源 2、 如果该引用是间接参照，直接引用的映射必须被限制为当前用户所授权的值。 代码审查的申请都可以快速验证两种方法是否安全实施。测试也能有效识别直接对象引用是否安全。自动化工具通常不会查找这类缺陷，因为它们不能辨别需要保护什么或者什么是安全的或不安全的。 如何阻止攻击？
阻止不安全的直接对象引用需要选择一种保护每个用户可一访问的对象 1、 使用每用户或会话间接的对象引用，这可以防止攻击者直接方位未经授权的资源。例如，
一个下拉列表六个授权资源，当前用户可以使用数字1到6来表示用户选择的值，而不是使用资源数据库中的键。该应用程序需要为每个用户的间接引用映射到服务器数据库的键。OWASP的ESAPI包含顺序和随机访问，开发人员可以用它来消除的直接对象引用的参考图。
