Posts List

GMail XSS 漏洞分析

原文:XSS in GMail’s AMP4Email via DOM Clobbering 译者:neal1991 welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 这篇文章是我在2019年8月通过Google 漏洞奖励计划报告的 AMP4Email 中已经修复的 XSS 的文章。该 XSS 是对著名浏览器问题 DOM Clobbering 的真实利用案例。 什么是 AMP4Email AMP4Email(也称为动态邮件)是 Gmail 的一项新功能,可以让电子邮件包含动态 HTML 内容。尽管撰写包含 HTML 标签的电子邮件已经很多年了,但通常认为 HTML 仅包含静态内容,即某种格式,图像等,没有任何脚本或表单。 AMP4Email 打算更进一步,允许电子邮件中包含动态内容。 在Google 官方 G Suite 官方博客中的帖子中,对动态邮件的使用案例进行了很好的总结 通过动态邮件,你可以轻松地直接从消息本身直接操作,例如对事件进行快速回复,填写问卷,浏览目录或回复评论。 以在 Google 文档中进行评论为例。现在,你将不再在有人在评论中提及你时接收到单独的电子邮件通知,而是会在 Gmail 中看到最新的主题,你可以在邮件中直接从中轻松回复或解决评论。 该功能引发了一些明显的安全性问题。最重要的一个可能是:跨站点脚本(XSS)?如果我们允许电子邮件中包含动态内容,是否意味着我们可以轻松地注入任意 JavaScript 代码?好吧,答案是否定的;没那么容易。

Chrome 最新零日漏洞

原文:Chrome 0-day exploit CVE-2019-13720 used in Operation WizardOpium 译者:neal1991 welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 摘要 卡巴斯基安全防护是卡巴斯基产品的一部分,过去已成功检测到许多零日攻击。最近,为 Google的 Chrome 浏览器发现了一个未知的新漏洞。我们会立即将此情况报告给 Google Chrome 安全团队。在审核了我们提供的 PoC 之后,Google 确认存在零日漏洞并将其分配为 CVE-2019-13720。 Google 已针对 Windows,Mac 和 Linux 发布了 Chrome 版本78.0.3904.87,我们建议所有 Chrome 用户尽快将其更新为最新版本!你可以点击此处阅读 Google 公告。 卡巴斯基端点产品借助漏洞利用防御组件检测漏洞。该攻击的裁决是 Exploit.Win32.Generic。 我们称这些攻击为 Operation WizardOpium。到目前为止,我们还无法与任何已知的威胁者建立明确的联系。与蓝莲花攻击有某些非常弱的代码相似性,尽管这很可能是 false flag。目标网站的配置与最近部署了类似虚假标记攻击的早期 DarkHotel 攻击更加一致。 卡巴斯基情报报告的客户可以获取有关 CVE-2019-13720 和最近的 DarkHotel 的 false flag 攻击的详细信息。有关更多信息,请联系:intelreports@kaspersky.

MyBatis 和 SQL 注入的恩恩怨怨

本文首发于安全客平台 MyBatis 是一种持久层框架,介于 JDBC 和 Hibernate 之间。通过 MyBatis 减少了手写 SQL 语句的痛苦,使用者可以灵活使用 SQL 语句,支持高级映射。但是 MyBatis 的推出不是只是为了安全问题,有很多开发认为使用了 MyBatis 就不会存在 SQL 注入了,真的是这样吗?使用了 MyBatis 就不会有 SQL 注入了吗?答案很明显是 NO。 MyBatis 它只是一种持久层框架,它并不会为你解决安全问题。当然,如果你能够遵循规范,按照框架推荐的方法开发,自然也就避免 SQL 注入问题了。本文就将 MyBatis 和 SQL 注入这些恩恩怨怨掰扯掰扯。(注本文所说的 MyBatis 默认指的是 MyBatis3) 起源 写本文的起源主要是来源于内网发现的一次 SQL 注入。我们发现内网的一个请求的 keyword 参数存在 SQL 注入,简单地介绍一下需求背景。基本上这个接口就是实现多个字段可以实现 keyword 的模糊查询,这应该是一个比较常见的需求。只不过这里存在多个查询条件。经过一番搜索,我们发现问题的核心处于以下代码: public Criteria addKeywordTo(String keyword) { StringBuilder sb = new StringBuilder(); sb.append("(display_name like '%" + keyword + "%' or "); sb.append("org like '" + keyword + "%' or "); sb.

被动扫描器之插件篇

本文首发于 freebuf, https://www.freebuf.com/articles/web/219818.html 最近被动扫描器的话题如火如荼,好多公司都在做自己的被动扫描器。而获取质量高的流量是被动扫描器起作用的关键。笔者主要开发了两个被动扫描器的插件,r-forwarder 以及 r-forwarder-burp,两个插件的代码都在 Github 上开源。两个插件分别为 Chrom 插件以及 Burp 插件,本文也从笔者开发这两个插件的经验来聊一聊被动扫描器中插件的开发。 Chrome 插件 Chrome 插件是向 Chrome 浏览器添加或修改功能的浏览器拓展程序。一般通过 JavaScript, HTML 以及 CSS 就可以编写 Chrome 插件了。市面上有很多非常优秀的 Chrome 插件拥有非常多的用户。Chrome 插件的编写也比较简单,基本上你熟悉一点前端知识,然后熟悉一下 Chrome 插件的 API,你就可以编写 Chrome 插件。Chrome 插件的安装,如果你没有发布在 Chrome 商店的话(因为网络原因,可能没办法直接从商店下载),可以通过开发者模式安装 Chrome 插件。或者你也可以注册 Chrome 插件的开发者账号(只需要 5 美元,就可以发布 20 个插件)。 简单地介绍了一下 Chrome 插件的开发,咱们主要还是聊一下关于 Chrome 插件关于被动扫描器的方面的内容。对于 Chrome 插件,主要是通过插件的能力去获取经过浏览器的流量,并将流量转发给后端来进行处理。Chrome 插件关于网络流量的处理地 API 主要有两个:chrome.devtools.network 以及 chrome.webRequest。但是前者使用的时候需要打开 Chrome 开发者工具,这个有一点不太方面,所以选择了后者,这也是对于被动流量获取一种常见的方式。 Chrome 插件中的 webrequest API 是以相应的事件驱动的,其中请求的生命周期图如下,主要有7个事件。只需要监听关键事件进行处理就可以满足被动扫描器获取流量的需求了。 其实这些事件不难理解,基本通过事件的名称就可以知道事件的含义了,主要就是请求发送前,发送请求头之前,发送请求头等等事件。对于不同的事件,可以获取的流量数据也是不尽相同的。首先,考虑一下,对于被动扫描器来说,哪些流量数据是比较关心的。被动扫描器主要是通过收集业务的正常流量来进行测试,提高测试的效率,并能取得比主动扫描器更好的效果。那么一般来说,被动扫描器最关心的就是请求的 URL 以及请求头了,如果是 POST 请求,还需要请求体。对于扫描器来说,响应头和响应体则没那么重要,其实可以通过响应状态过滤一下,一般只需要能够正常响应的请求头以及请求体即可。 对于被动扫描器上述的需求,chrome.webrequest 中的 onBeforeRequest 以及 onSendHeaders 这两个事件可以满足需求。通过前者,可以获取请求体。通过后者则可以获取请求头。不过在使用 onSendHeaders 的时候,有好几点需要注意:

Bastion -- Hack the box

介绍 目标: 10.10.10.134 (Windows) Kali:10.10.16.65 In conclusion, Bastion is not a medium box. But it would be easier to solve this box with windows VM. Command VM may be a good choice. But it can be finished by kali. 总的来说,Bastion 其实并不是一个特别简单的机器。如果使用 windows 可以更方便地解决这台靶机。Command VM 对于这台靶机其实挺不错的,不过我们也可以使用 kali 来完成这个靶机。 信息枚举 Firstly, detect the open ports: 首先,探测开放端口 # Nmap 7.70 scan initiated Sun May 5 12:33:32 2019 as: nmap -sT -p- --min-rate 10000 -oN ports 10.

使用浏览器作为代理从公网攻击内网

介绍 在 Forcepoint,我们不断寻求改善我们产品所提供的防护。为此,我们经常研究不寻常或潜在新颖的攻击技术。最近的一个研究课题是从公网发起的针对 localhost 和内网的攻击。 虽然不是新的攻击,但在安全研究社区之外,恶意 JavaScript 可以攻击内网并不广为人知。在关于该主题的有限文档中,大多数资源是从 inter-protol(协议间)漏洞来描述 [1] [2],而我们的重点是 intra-protol(协议内部)的漏洞。我们发现没有一站式资源从协议内部攻击的角度去描述这种攻击,并且在白皮书中收集这些技术是为了填补关于这些攻击文档的空白,以及让被低估的攻击面受到关注。 由于浏览器默认可以访问 localhost 以及本地局域网,因此这些攻击可以绕过潜在的本地基于主机的防火墙以及企业/消费者外围防火墙。 恶意攻击者了解这些攻击,但防守者也需要被告知。除了描述攻击的技术细节之外,我们还将讨论检测和防范攻击的方法。 可疑行为:公网到局域网的连接 从恶意站点加载的 JavaScript 可以在许多情况下能够连接用户本地计算机(localhost)或其他内部主机上运行的服务。现代 Web 浏览器不能完全阻止使用受害者浏览器作为代理攻击内网。事实上,我们不仅可以让受害者浏览器在内部发送请求,而且我们还可以发现内部主机,进行有限端口扫描,进行服务指纹识别,最后我们甚至可以通过恶意 JavaScript 来攻击易受攻击的服务。 如果从公网获取的网页尝试访问未路由的 IP 地址(例如 localhost 或内部网络),则应将其视为可疑行为。通过我们的遥测技术,我们还没有发现过存在于公网上的良性网页需要连接到私有 IP 地址,我们也没有发现任何有效和合理的业务用例来做这样的事情。是否有必要允许公网上的网页连接到私有 IP 地址,而不是在某些边缘情况下,这是值得怀疑的。一个边缘情况可能是在内部网络上使用公共 IP 地址的不常见设置。(但必须允许相反的方向的情况,因为许多内部页面可能出于完全正当的原因而获取外部资源。) 这种可疑行为与攻击链的各个部分一起具有某些特征,可以用于检测目的建模。我们稍后将回到更详细的关于检测的讨论,因为如果我们先了解攻击链的技术细节,检测就更有意义了。 在进行威胁建模时,开发者通常认为本地服务永远不会接收外部输入,因此通常缺乏对这些服务的安全审核。可能通过远程托管的恶意 JavaScript 攻击易受攻击的本地服务的最新示例是 Logitech Options 应用开启易受攻击的 WebSocket 服务器 [3]。通过远程跨域 JavaScript 进行的本地攻击代表了一种被低估的攻击面。 同源策略不会阻止本地攻击吗? 实际上,同源策略(SOP)[4]在很多情况下确实可以防范这种攻击,但正如我们看到的,仍然存在攻击可能成功的情况。尽管有相关文档,通常被忽略的事实是同源策略并不会阻止浏览器发出跨域请求,它只能阻止 JavaScript 读取响应。(同源策略允许嵌入跨域资源,如图像和 JavaScript,但这是另外一方面的内容。)对于攻击某些易受攻击的服务,它可能足以能够盲目地发送恶意请求以达到攻击者的目的。 Mozilla 的文档很好地描述了同源策略的功能:允许跨域嵌入和写入,但不允许读取。允许跨域写入的事实使得可能执行以下攻击: 受害者在互联网上浏览恶意页面。页面上的 JavaScript 根据同源策略向不应与之通信的内部服务器发出异步请求(XMLHttpRequest)。 然而,浏览器将发送请求(此时服务器被利用)。 浏览器收到响应但不会将其传递给 JavaScript。 那跨域资源共享呢? 我们要展示的攻击与跨域资源共享(CORS) [5] 无关,只与同源策略相关。在本白皮书中,我们可以假设不允许跨域资源共享请求,这意味着我们拥有最严格的设置,其中同源策略“阻止”所有内容。即使面对同源策略,我们也可以进行攻击。 攻击概述 我们将看一下使用受害者的浏览器作为代理,外部站点上的 JavaScript 如何攻击运行在 localhost 或内网中的易受攻击的服务的示例。作为概述,我们将看看以下步骤:

跨站请求伪造(CSRF)攻击

概述 跨站请求伪造(CSRF)攻击强迫终端用户在他们身份被认证的情况下执行对于目标应用未知的操作(恶意的)。CSRF 攻击一般针对状态更改请求,而不是数据被盗,因为攻击者无法查看对伪造请求的响应。通过社会工程的(例如通过电子邮件或聊天发送链接)方法,攻击者可以欺骗 Web 应用程序的用户执行攻击者选择的操作。如果受害者是普通用户,则成功的 CSRF 攻击可以强制用户执行状态更改请求,例如转账,更改其电子邮件地址等。如果受害者是管理帐户,CSRF 可能会危及整个 Web 应用程序。 值得注意的一点是 CSRF(跨站请求伪造)攻击经常与 XSS(跨站脚本)攻击(特别是反射性 XSS 攻击)混淆,两者虽然都是跨站,但并未有实际联系,利用方式也不尽相同。XSS 攻击通常是在合法的网络应用中注入恶意的内容为受害者提供服务。注入的内容会被浏览器执行,因此恶意脚本会执行。CSRF 的攻击通常是让目标用户在不知情的情况下执行一个操作(比如转账,表单提交),如果当前目标用户的还是已授权状态,那么这些操作就有可能会执行成功。可以这么理解,CSRF 就是利用用户合法的身份在用户不知情的情况下执行一些操作。而 XSS 则是在合法的网站注入恶意的内容,需要或者不需要用户交互即可执行恶意脚本,从而实现攻击。虽然两者并无太多相同之处,但是 XSS 漏洞会导致 CSRF 的某些防护措施失效,因此做好 XSS 的防护对于 CSRF 的防护也是很有意义的。 CSRF 的工作原理 CSRF 攻击是通过让一个已授权的用户的浏览器向应用发起一个恶意请求(用户尚不知情的情况)。只要用户的身份已被验证过且实际的请求已经通过用户的浏览器发送到目标应用,应用无法知道情况的来源是否是一个有效的交易或者这个用户是在知情的情况下点击这个链接。通过 CSRF 攻击,攻击者可以让受害者执行一些他们不知情的操作,比如,登出,购买操作,改变账户信息或者其它目标攻击应用提供的服务。 下面就是一个例子在机票供应商那里购买飞机票: POST http://TicketMeister.com/Buy_ticket.htm HTTP/1.1 Host: ticketmeister User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;) Firefox/1.4.1 Cookie: JSPSESSIONID=34JHURHD894LOP04957HR49I3JE383940123K ticketId=ATHX1138&to=PO BOX 1198 DUBLIN 2&amount=10&date=11042008 响应代表购买飞机票的 POST 请求已经成功执行: HTTP/1.0 200 OK Date: Fri, 02 May 2008 10:01:20 GMT Server: IBM_HTTP_Server Content-Type: text/xml;charset=ISO-8859-1 Content-Language: en-US X-Cache: MISS from app-proxy-2.