译文翻译申明文中是翻译文章,文章内容著作人alex

在找寻网络安全问题时，对不明财产和隐敝网站的收集一般最后会令人贪小失大。

假如您对一个总体目标开展安全性测试，如同第一次对它实行安全风险评估一样细腻，完全查验全部內容，那麼相信您一定会寻找新的物品：尤其是假如要检测的编码早已不断开发设计了一段时间。

这是一个有关高风险系统漏洞的小故事，该系统漏洞会危害PayPal浏览量较大的网页页面之一：登陆表格。（最终被奖赏了$15300美元）

基本发觉

在访问 PayPal的关键身份认证步骤时，我注意到一个javascript文档，在其中好像包括了一个CSRF动态口令和对话ID的內容：

这马上造成了我的留意，由于在一个合理的javascript文档中出示一切种类的对话数据信息得话，一般都给网络攻击可趁之机。

在说白了的跨网站脚本制作包括（XSSI）进攻中，故意网页页面能够应用HTML <script>标识导进跨域脚本制作，进而使其可以浏览文档中包括的一切数据信息。

果真，我迅速就检测确定了该XSSI系统漏洞，虽然它应用了JavaScript混淆器来随机化每一个要求的用户标识符，但趣味的是，动态口令仍被置放在十分非常容易搜索的部位，一下子就被找到。

殊不知，水可载舟亦可覆舟，需看该信息内容怎样运用了。我马上下手找到_csrfh和_sessionID的准确含意，及其他们是不是能够真实用以具体进攻中。

进一步发掘

我试着将PayPal服务平台上已受权要求中的基本CSRF动态口令更换为_csrf的值，历经一次次的试着后，我得到的结果是，应用此特殊动态口令没法开展經典的跨网站要求仿冒进攻。一样，_sessionID也不好。

接下去，我回到该系统漏洞脚本制作，查询该动态口令的的具体主要用途，最终对PayPal用于避免 暴力行为进攻（安全性挑戰）的一个关键维护体制开展了深入分析。尽管此体制已被普遍应用，但我将关键详细介绍此登陆表格。

这一念头非常简单：几回试着登录失败后，您必须先处理reCAPTCHA挑戰，随后才可以再试。可是，这一挑戰就很有赚头了。

它的体制是那样的：在检验到很有可能的暴力破解密码试着后，下一次身份认证试着的回应将是一个网页页面，在其中仅包括Google短信验证码。假如客户根据了短信验证码检测，会向/auth/validatecaptcha进行一个HTTP POST要求。

在要求行为主体中又看到了_csrf和_sessionID了解的影子，行为主体中也有别的2个值，稍候会详细介绍。

对短信验证码要求的回应致力于将客户再次引进身份认证步骤。因此，它包括一个自身递交的表格，在其中包括客户全新登陆要求出示的全部数据信息，包含她们的电子邮箱和纯文字登陆密码。