随着漏洞赏金金额的提高，很多靠此为生的研究者竟发现了许多所谓的漏洞，今天我们就来看看十大令人哭笑不得的漏洞。
十、并发会话过多
Gmail和Facebook会话持续了数年，你可以同时从不同的设备访问它们。如果Gmail和Facebook不想为用户提供这种便利，则可以实施会话超时，以在用户闲置五分钟后将其注销。
现在，设想一种情况，假如你需要提交汇款请求，而银行要求你填写一个包含十几个不同输入字段的在线表单。这样你就要切换到另一页以查找一些详细信息，对它们进行三次验证，然后仅检查一下Reddit(全球很受欢迎的讨论网站,它的访问量已经可以排进全球前十)。当你最终决定提交表单时，会收到一条错误消息，表明你的会话不再有效。为此你必须重新填写一遍，因为你只有这样做，才能汇款。不过，这个过程会让你极为不爽。
起初，会话超时可以阻止某些XSS的利用，但是你输入密码的次数越多，就可能会增加在恶意页面上意外输入密码的机会。
九、无用的信息披露
有一些信息披露是无用的。除了牵强附会的假想场景之外，其他信息几乎毫无用处，但仍然每天都有报道，我最喜欢的示例是"Server: Apache"，这种不可思议的鲁莽行为为无数黑客打开了后门。没有人能猜到web服务器可能正在运行Apache，或者使用53种替代技术中的一种对其进行指纹识别。不幸的是，恶意的开发人员不允许你禁用它，因此你需要部署一个反向代理。
八、缺少rate-limit/ CAPTCHA
RateLimiter 从概念上来讲，速率限制器会在可配置的速率下分配许可证，如果必要的话，每个acquire() 会阻塞当前线程直到许可证可用后获取该许可证，一旦获取到许可证，不需要再释放许可证。通俗的讲RateLimiter会按照一定的频率往桶里扔令牌，线程拿到令牌才能执行，比如你希望自己的应用程序QPS不要超过1000，那么RateLimiter设置1000的速率后，就会每秒往桶里扔1000个令牌。
虽然强制使用一次性密码的影响是毁灭性的，但这并不意味着每个应用程序终端都应该限制来自一个IP的传入连接的数量。如果请求只是在应用程序上创建工作载荷，你真的想要修复它吗?每个修复都需要关注、工程时间、测试时间，有时甚至会引入新的漏洞。没有直接影响的速率限制(除了DOS)通常被排除在漏洞奖励计划之外，因为它没有达到风险与修复成本的阈值。
七、将CSV注入作为一个漏洞
早在2014年，CSV注入(CSV Injection)漏洞的发现者James认为这是一种会造成巨大影响的攻击向量。攻击包含向恶意的EXCEL公式中注入可以输出或以CSV文件读取的参数。当在Excel中打开CSV文件时，文件会从CSV描述转变为原始的Excel格式，包括Excel提供的所有动态功能。在这个过程中，CSV中的所有Excel公式都会执行。当该函数有合法意图时，很易被滥用并允许恶意代码执行。
但是，在跟踪研究过程中，James发现了一个公式，如果受害者点击多个可怕的警告，就会在Excel中执行任意代码。结果呢?几乎所有具有CSV导出功能的站点都有此报告。
六、未指定组件中的CVE-XXXX未指定漏洞
根据你发现的易受攻击的软件版本来报告漏洞并没有什么错，但是你很容易被成千上万的此类报告所困扰。在当前条件下，它们中可能只有一小部分实际上是可利用的，或者它们可能根本不会被用户看到。由于很难找到1%的可利用漏洞并正确确定优先级，但这就需要公司付出很多成本。扫描已知漏洞通常只是第一步，真正的价值是通过报告经过验证的漏洞并具有清晰的利用载体来创造的。
五、不再具有威胁的XSS漏洞
XSS(cross-site scripting跨域脚本攻击)攻击是最常见的Web攻击，其重点是“跨域”和“客户端执行”。有人将XSS攻击分为三种，分别是：Reflected XSS(基于反射的XSS攻击)、Stored XSS(基于存储的XSS攻击)、DOM-based or local XSS(基于DOM或本地的XSS攻击)。
那些不再起作用的经典XSS攻击可以说是非常可笑的漏洞，比如document.write(location.pathname)，document.write()是Javascript中对document.open()所开启的文档流操作的API方法。document.write()方法可以向HTML输出流中插入你传入的内容，浏览器会按着HTML元素依次顺序依次解析它们，并显示出来。其中的路径在现代浏览器中总是URL编码的，如果内容类型是纯文本或json时会嗅探内容。曾经的IE可谓是漏洞百出，研究人员有很多技巧可以利用Internet Exploder。但是如今，除非用户决定通过使用过时的Internet Explorer导航到URL来查看一些黄赌毒的非法网站，否则XSS攻击漏洞可以说是毫无意义。不幸的是，这并不能阻止赏金猎人在他们的报告中把这些所谓的漏洞作为重要的一块来研究。
四、缺少安全标头
标头是HTTP规范的一部分，在HTTP请求和响应中定义消息的元数据。当用户通过客户端浏览器访问网站时，服务器使用HTTP响应头进行响应。虽然HTTP消息通常由用户读取，但元数据仅由Web浏览器处理，并且自1.0版以来已包含在HTTP协议中。
三、标签钓鱼(tabnabbing)
该攻击手法是由Mozilla Firefox浏览器的界面及创意负责人Aza Raskin发现和命名的，tabnabbing可改变用户浏览网页的标签及接口，以诱导用户输入网络服务的账号与密码。 因此，Raskin将此手法称为标签绑架(tabnapping)，他指出当使用者连上一个嵌有第三方script程序或Flash工具的网页时，就会让自己曝露于风险中，因为相关的恶意软件得以侦测使用者经常使用或正在使用的网络服务，在用户暂时离开该网页后，该网页内容及网页标签会悄悄地变身成为伪造的网络服务，并诱导用户输入个人信息。
逆向tabnabbing，会发现两种类型。通过改变打开攻击者控制的站点的页面的URL来滥用 target=_blank，这样做的目的是当你关闭攻击者控制的页面时，骗你登录钓鱼网站。幸运的是，浏览器将通过默认情况下使用noopener将window.opener设置为null来链接到target = _blank来缓解此漏洞。这意味着，再报告类似的漏洞已经毫无意义了。
二、缺少httponly标志
如果cookie设置了HttpOnly标志，可以在发生XSS时避免JavaScript读取cookie，这也是HttpOnly被引入的原因。但这种方式能防住攻击者吗?HttpOnly标志可以防止cookie被“读取”，那么能不能防止被“写”呢?答案是否定的
根据研究者多年的跟踪分析，他们观察到了一种奇特的现象。当一种安全措施像设置HTTP标头或cookie标志一样简单时，它很快就会吸引很多狂热爱好者，他们坚持认为必须在任何可能的地方使用它。这样造成的后果是他们认为任何不采取这些措施的网站都肯定不安全。
目前可以肯定，旨在通过停止使用JavaScript来窃取会话cookie来缓解XSS的使用，这几乎是无用的，因为cookie泄漏是一种复杂且不切实际的利用方法，攻击者无论如何也不死盯着这一方法来发起攻击。不幸的是，httponly标志的粉丝并不知道这一点，他们也不认识会话cookie，所以你最好将其应用于每个cookie上，否则他们可能会愤怒。
这个漏洞报告除了对赏金猎人有用外，实际的防御价值几乎可以忽略不计。
一、autocomplete=off设置失败
autocomplete 属性是 HTML5 中的新属性，在input中autocomplete属性是默认开启的。属性值：on——默认，启动自动完成;off——禁用自动完成。
input 的属性autocomplete 默认为on，其含义代表是否让浏览器自动记录之前输入的值。很多时候，需要对客户的资料进行保密，防止浏览器软件或者恶意插件获取到。可以在input中加入autocomplete="off" 来关闭记录，系统需要保密的情况下可以使用此参数。研究人员跟踪发现，“autocomplete=off设置失败”这个漏洞之所以会被漏洞赏金者视为重点发现对象，原因如下：
- 传统观点认为，使用密码管理器是实现超级安全的唯一密码的唯一方法;
- 安全审核员声称应通过设置autocomplete = off就可以阻止或禁止这种做法;
- 不同意可能会导致无法获得PCI合规性;
- 浏览器供应商不同意，因此所有主要浏览器都故意忽略此设置;
- 有些网站通过不使用type = password或禁用粘贴的方法来解决此漏洞;
那实际结果如何呢?大多数网站都把精力浪费在一个所有人都忽略的设置上，而安全问题没有得到任何解决。
本文翻译自：https://portswigger.net/research/notwasp-bottom-10-vulnerabilities-that-make-you-cry
