test

您是否有兴趣将黑客技术推广到当前最新技术水平并与信息安全社区分享您的发现？在这篇文章中，我将分享一些关于 web安全研究 的指导，这些指导是我自己在追求这条道路时遇到的机遇和陷阱所塑造的。 以破坏为生 大多数研究都是使得现有的技术更进一步，所以第一步是要熟悉当前的技术发展水平。实现这一目标的最快方法是找到一份工作，将大部分时间花在使用web黑客技术上。许多优秀人士已经就进入安全行业提出了 详细的建议 ，因此我将简要介绍这一部分。 我建议从以实践为中心的方法的 OWASP Broken Web应用程序 开始，转向更现实的挑战，比如我自己的 hackxor.net ，在 HackerOne 和 BugCrowd 上搞定简单，低回报的目标，然后最终进入成熟的高额漏洞赏金计划。一旦你有一些公开披露的漏洞，加入一个安全咨询公司应该很容易，然后就可以每天进行黑客活动了。 有很多免费的在线资源可以帮助您，包括我们的 Burp方法 ，HackerOne的 Hacker101 和 OWASP测试指南 。至于书籍，我建议阅读 WebApp Hacker's Handbook 和 The Tangled Web 。 超越已有的技术（寻找被遗忘的知识，手机多样性，没想法就是太愚蠢） 一旦你开始全职工作，你刚开始的学习负荷大，但一段时间后，你的技术技能将稳定下来并进入停滞期，除非你齐心协力继续学习。 寻找被遗忘的知识 每个人都知道你通过监控 行业专家 ， 安全新闻 和安全会议是为了跟上新的发展，然而，完全遵循新的发展，就会遗忘掉过去的知识和以前的研究paper等等宝库。（However, to exclusively follow new developments is to overlook a treasure trove of forgotten and overlooked research. ） 每次阅读高质量的博客文章时，请阅读整个档案，因为这往往会暴露出宝贵的、被遗忘的信息。例如，请阅读RSnake 2009年编写的 关于DNS重新绑定的文章 。DNS重新绑定可以完全绕过网站上基于IP /防火墙的访问控制，唯一有效的缓解方法是将HTTP头部中的host加入应用程序的白名单。然而，当时，人们很快就认为浏览器可以缓解这种情况；9年后，这种被遗忘...

原为地址：如下 https://www.anquanke.com/post/id/156356   实战Web缓存投毒（上） https://www.anquanke.com/post/id/156551   实战Web缓存投毒 （下） 摘要 长期以来，web缓存投毒都是一个被人遗忘的漏洞，一种用于吓唬开发人员乖乖修复但是无人可实际利用的“理论”上的威胁。 在本文中，我将向大家展示如何通过使用深奥的web特性来将它们的缓存系统转变为漏洞利用代码（exploit）投放系统，每一位错误访问他们主页的用户都是这种攻击的目标。 我将结合让我能够控制大量流行网站和架构的漏洞来说明和进一步扩展这种技术，从简单的单一请求攻击到劫持javascript，越过缓存层，颠覆社交媒体，误导云服务的复杂漏洞利用链。我将讨论如何防御缓存投毒，并发布Burp Suite 扩展 推动这项研究。 也可以查看我的 演讲视频 和 白皮书pdf 。 核心概念 缓存概念介绍（Caching 101） 要掌握缓存投毒技术，我们需要快速了解缓存的基本原理。 Web缓存位于用户和应用程序服务器之间，用于保存和提供某些响应的副本。在下图中，我们可以看到三个用户一个接一个地获取相同的资源： 缓存技术旨在通过减少延迟来加速页面加载，还可以减少应用程序服务器上的负载。一些公司使用像Varnish这样的软件来托管他们自己的缓存，而其他公司选择依赖像Cloudflare这样的内容分发网络（CDN），缓存分布在世界各地。此外，一些流行的Web应用程序和框架（如Drupal）具有内置缓存。 还有其他类型的缓存，例如客户端浏览器缓存和DNS缓存，但它们不是本次研究的关注点。 缓存键（Cache keys） 缓存的概念可能听起来简单明了，但它隐藏了一些有风险的假设。每当缓存服务收到对资源的​​请求时，它需要确定它是否已经保存了这个指定资源的副本，并且可以使用该副本进行响应，或者是否需要将请求转发给应用程序服务器。 确定两个请求是否正在尝试加载相同的资源可能是很棘手的问题;对请求进行逐字节匹配的做法是完全无效的，因为HTTP请求充满了无关紧要的数据，例如请求头中的User-Agent字段： GET /blog/post.php?mobile=1...

原文： http://tutorials.jenkov.com/oauth2/index.html OAuth 2.0是一种开放式 授权 协议，该协议使得应用程序可以访问彼此的数据。例如：一个游戏应用可以访问Facebook中的用户数据，或者基于位置的应用程序可以访问Foursquare应用程序的用户数据（ user data ）等。 OAuth 2.0被用于通过应用程序共享数据的示例如上图。 首先用户进入游戏的web应用，该应用要求用户通过Facebook账户登录，并定向到Facebook的登录界面，用户登录Facebook后，会重定向到之前的游戏应用。此时该应用就访问到了用户在Facebook的用户数据以及授权信息，并代表用户在Facebook中调用功能（例如发布状态更新）。 OAuth 2.0 用例 OAuth 2.0既可以用于在某个应用内访问其它应用的用户信息（比如上例中的游戏应用），又可以提供用户授权服务供其它应用调用（比如上例中的Facebook）。 OAuth 2.0是OAuth 1.0的替代，因为OAuth 1.0太复杂了，比如OAuth 1.0要求使用证书等。OAuth 2.0更加简单，不要求使用证书，仅使用SSL/TLS。 OAuth 2.0 规范 这个教程的目的是提供一个OAuth 2.0协议的概览以帮助理解，而不是涵盖此协议的所有细节。 如果你计划实现一个OAuth 2.0协议，最好是去阅读规范的详细内容，规范的地址：http://tools.ietf.org/html/draft-ietf-oauth-v2-23 OAuth 2.0 概述 在之前的介绍中我们提到，OAuth 2.0是一个开放标准，其允许某个应用程序访问其它应用程序的用户授权的数据。现在我们来介绍这个协议是如何工作的，以及规范中提到的各种概念。 OAuth 2.0 提供了不同的方式使得客户端应用获得权限去访问存储在资源服务器中的资源。现在介绍其中最安全和最常用的使用方式： 一个web应用请求访问另一个web应用 的资源。 下面的示例图描述了整个认证过程： 首先，用户访问客户端Web应用程序，在这个应用程序里有“通过Facebook登录”（或谷歌或Twitter等其他系统）的按钮。 第二步，当用户点击这个按...

跨域资源共享CORS，指的是a.com中的某个页面假设为test.html使用了XMLHttpRequest API或者fetch API去跨域访问b.com中的资源，而b.com中的资源没有设置响应头部access-control-allow-origin，则无法跨域访问成功。 场景： 在本地开启两个http服务，server1监听在8888，server2监听在8887。server1服务中有test.html文件 1：server1服务中的test.html使用XMLHttpRequest访问127.0.0.1:8887 test.html的内容如下： <script> var xhr = new XMLHttpRequest() xhr.open('GET', "http:// 127.0.0.1:8887 ") xhr.send() </script> 此时，会出现错误，因为server2没有设置响应头部 Access-Control-Allow-Origin ，如果此时server2在响应头部中加入 Access-Control-Allow-Origin:'*'，则不会出现错误，因为设置成这样就表示server2允许任何来源的域来访问自己的资源。 如果此时server2在响应头部中加入 Access-Control-Allow-Origin:'http://google.com' ，则表示server2只允许google.com来访问自己的资源，此时 test.html访问server2就会出错。 2： server1服务中的test.html使用如下方式访问127.0.0.1:8887 test.html的内容如下： <scripts src='http:// 127.0.0.1:8887 '></script> 此时，server2 在响应头部中加入 Access-Control-Allow-Origin:'*'或者不加入都不会出现错误。 3： server1服务中的test.html使用如下方式访问127.0.0.1:8887 test....