Toda mi ambición es ser libre toda mi vida.
[paper] Mini-app Research – parameter pollution paper reading
[paper] Mini-app Research – parameter pollution paper reading

[paper] Mini-app Research – parameter pollution paper reading

1. Automated Discoverv of Parameter Pollution Vulnerabilities in Web Applications

HTTP Parameter Pollution

1.1 Introduction

HPP 攻击包括将编码的查询字符串定界符注入其他现有参数。HPP 漏洞允许攻击者在 Web 应用程序生成的 URL 中注入参数。
如果 Web 应用程序未正确清理用户输入,恶意用户可能会破坏应用程序的逻辑以执行客户端或服务器端攻击。
HPP 攻击的一个后果是,攻击者可能会覆盖现有的硬编码 HTTP 参数以修改应用程序的行为,绕过输入验证检查点,并访问和可能利用可能无法直接访问的变量。

贡献:

  • 提出了第一种用于检测 Web 应用程序中 HPP 漏洞的自动化方法。包括一个将参数注入 Web 应用程序的组件,以及一组测试和启发式方法,以确定生成的页面是否包含 HPP 漏洞。
  • 描述了 PAPAS(参数污染分析系统)的方法原型的架构和实现。 PAPAS 能够抓取网站并生成 HPP 易受攻击的 URL 列表。
  • 展示并讨论了对 5,000 多个热门网站进行的大规模真实实验。实验表明,HPP 漏洞在网络上很普遍,许多知名的主要网站都受到了影响。证实,我们发现的漏洞中至少有 46.8% 可以在客户端被利用。表明,就像早期的跨站点脚本和跨站点请求伪造一样,许多开发人员没有意识到 HPP 问题,或者他们没有认真对待它。

1.2 HTTP Parameter Pollution Attacks

1.2.1 web应用程序中的参数优先级

考虑GET方法,对于多个变量,会分别分隔获取对应变量的值,分割的方法取决于web网站的编程语言。

以下是各编程语言对于存在多个同名参数时的参数优先级

1.2.2 HPP in web application

当恶意参数被注入现有参数,而且没有被application正确清理,它的值被解码并用于生成URL_,则可以被利用。

e.g

假如这是一个JSP编写的application投票,poll_id表示这是哪一个投票,网页html如下,表示有两位被投票人,用户通过点击每一个链接来投票:

Url: http://host/election.jsp?poll_id=4568
Link1: <a href="vote.jsp?poll_id=4568&candidate=white"> Vote for Mr. White</a> 
Link2: <a href="vote.jsp?poll_id=4568&candidate=green"> Vote for Mrs. Green</a>

假如攻击者给别人发构造过的恶意链接:http://host/election.jsp?poll_id=4568%26candidate%3Dgreen

当这个篡改过的链接被访问时,服务器会将 candidate=green 作为一个额外的参数解析,这导致了服务器生成的HTML代码变成了:

http://host/election.jsp?poll_id=4568%26candidate%3Dgreen
Link 1: <a href=vote.jsp?poll_id=4568&candidate=green &candidate=white>Vote for Mr. White</a>
Link 2: <a href=vote.jsp?poll_id=4568&candidate=green &candidate=green>Vote for Mrs. Green</a>

由于之前JSP在同一个参数的多个值时,只选取第一个值,所以根据这个特性,这样一来,当用户点击投票链接时,candidate=green 参数会先于 candidate=whitecandidate=green 参数被解析,从而影响投票结果。

Cross-Channel Pollution

用于覆盖不同输入通道之间的参数(GET,POST,and so on.)。安全措施就是只允许接收同一通道的参数。

HPP to bypass CSRF tokens

一般的防御csrf方式就是使用CSRF令牌。服务器生成一个随机的CSRF令牌,将其与用户的会话关联,并在需要安全验证的请求中附加这个令牌。当用户发起请求时,服务器会检查请求中的令牌是否与服务器端存储的令牌相匹配。

hpp怎么用来绕过呢?

Url: 
showFolder?fid=Inbox&order=down&tt=24&pSize=25&startMid=0 %2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26 cmd=fmgt.delete 
Link: 
showMessage?sort=date&order=down&startMid=0 %26cmd%3Dfmgt.emptytrash&DEL=1&DelFID=Inbox& cmd=fmgt.delete&.rand=1076957714

这个实例中,攻击者通过在URL中注入恶意参数来改变网页link,这个link是获得rand保护的,但是同时也会被执行恶意操作

攻击者构造的URL:showFolder?fid=Inbox&order=down&tt=24&pSize=25&startMid=0 %2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26 cmd=fmgt.delete

%2526 是一个二次编码的 “&” 符号,即 % 被编码为 %25,因此 %2526 实际上等于 %26,即 “&” 符号,两次 URL 编码,以强制应用程序仅在删除邮件后才清理垃圾箱。同样地,%26 也是一个URL编码的 “&” 符号。攻击者通过将这些编码字符添加到URL中,构造了一个包含额外参数的链接:showFolder?fid=Inbox&order=down&tt=24&pSize=25&startMid=0&cmd=fmgt.emptytrash&DEL=1&DelFID=Inbox&cmd=fmgt.delete

点击后会使得网页原来的link变成这样:showMessage?sort=date&order=down&startMid=0 %26cmd%3Dfmgt.emptytrash&DEL=1&DelFID=Inbox& cmd=fmgt.delete&.rand=1076957714

1.3 Automated HPP Vulnerability Detection with PAPAS

1.3.1 Browser and Crawler Components

  • 插件的形式:提取页面中的内容、链接列表和表单。
  • 获取更深层次的内容:启发式算法(感觉就是自定义一些数据填入),如果登陆失败或者其他什么,可以手动

1.3.2 P-Scan:参数优先级分析

  1. 对于多参数url,一个一个来,针对每一个参数都注入同一参数来确定参数优先级
    • 生成一个与现有参数值相似的新参数值,application可以接受的值,如数值生成连续数值,字符串生成相同长度(更改两个字符)
  2. 生成两个请求
    • 1:包含val2
    • 2:包含val1和val2

example:参数优先级在以下三个链接测试:

Page0 - Original Url: application.php?par1=val1&par2=val2
Page1 - Request 1: application.php?par1=newval&par2=val2
Page2 - Request 2: application.php?par1=val1&par1=newval&par2=val2 

这个简单的测试方法在实际中不成立:如果 Page1 == Page2,则第二个参数优先于第一个。如果 Page2 == Page0,则应用程序将第一个参数优先于第二个参数。因为现在的web网页动态展示可能参数相同也会导致相同参数的值不一样。

解决方法:

  1. 预处理page,尝试消除所有不依赖于应用程序参数值的动态内容(如HTML 注释、图像、嵌入内容、交互式对象(例如 Java 小程序)、CSS 样式表、跨域 iFrame 和客户端脚本,使用正则表达式来识别和删除“计时器”,)
  2. 移除所有引用页面本身的URL

比较过程:

  1. 身份测试测试参数的改变是否对网页内容有影响,防止参数只参与不可见的逻辑
  2. 基础测试:假设完美剥离所有动态组件,根据之前的简单的测试办法测试
  3. 连接测试:看有没有合并参数值
  4. 模糊测试:处理没有完美移除动态组件的页面。使用的相似度算法基于 Ratcliff/Obershelp 模式识别算法(也称为格式塔模式匹配 [28]),并返回 0(即完全不同)到 1(即完美匹配)之间的数字。
  5. 错误检测:不希望接收多个具有相同名称的参数时,通常会发生此类错误,一般就上传参数数组。

如果这五个都没成功,则参数丢弃。

1.3.3 V-Scan: Testing for HPP vulnerabilities

将无害参数的 URL 编码版本注入到查询字符串的每个现有参数中。(e.g: 将“%26foo%3Dbar”对注入参数“par1=val1”,然后检查“&foo=bar”字符串是否包含在链接或表单的 URL 答复页)

下面的pA是出现在url和page中的参数,pB页面中没有出现的URL参数,pC出现在页面某处但不出现在 URL 中的参数集

  1. 提取url中的参数[pu1, pu2, pu3],page页中的[pp1, pp2, pp3]
  2. 注入新参数到PA(应用程序将参数复制到页面主体并保持相同的名称极有可能存在漏洞)
    • 如果PA不成功,则注入PB(测试易受攻击的参数被应用程序重命名的情况发生(小概率))
      • PB不成功,则PC(这些添加到 URL 中,并将它们用作注入恶意对的向量。)

还有改进的余地,攻击者可能需要使用不同类型的编码才能触发错误(比如上面提到的双重编码)

处理特殊情况:

  • 报错了但是实际上执行不辽参数污染攻击
Url: index.php?v1=p1&uri=apps%2Femail.jsp%3Fvar1%3Dpar1%26foo%3Dbar
Link: apps/email.jsp?var1=par1&foo=bar

一个参数用于存储目标页面的 URL。因此,对该参数执行注入等同于修改其值以指向不同的 URL。
尽管这种技术在句法上与 HPP 漏洞非常相似,但它并不是一个合适的注入案例。

  • 页面的整个 URL 成为其中一个链接的参数
Url: search.html?session_id=jKAmSZx5%26foo%3Dbar&q=shoes
Link: service_request.html?page=search%2ehtml%3f session_id%3djKAmSZx5&foo=bar&q=shoes

这种一般出现在报告问题或者打印or共享功能的页面
通过更改页面的 URL,还更改了链接中包含的页面参数。显然,这不是 HPP 漏洞。

解决方法:

  1. 看参数是否以http://等等开头
  2. 注入两次看结果是否相同,by injecting &foo=bar instead of %26foo%3Dbar

1.3.4 Implementation

PAPAS 的浏览器组件是作为 Firefox 扩展实现的,而系统的其余部分是用 Python 编写的。这些组件通过 TCP/IP 套接字进行通信。

浏览器扩展是使用 Mozilla 开发环境提供的标准技术开发的:混合了 Javascript 和 XML 用户界面语言 (XUL)。我们使用 XPConnect 来访问 Firefox 的 XPCOM 组件。这些组件用于调用 GET 和 POST 请求以及与扫描组件通信。

1.3.5 局限

  1. 不支持抓取嵌入在活动内容(如 Flash)中的链接
  2. 不支持扫描服务端的漏洞,一些 HPP 漏洞也可用于利用服务器端组件(当恶意参数值未包含在链接中但已解码并传递给后端组件时)

1.4 结论

我还从没认真看过一篇论文的结论。


2. NoTamper: Automatic Blackbox Detection of Parameter Tampering Opportunities in Web Applications

NoTamper:Web 应用程序中参数篡改机会的自动黑盒检测

2.1 Introduction

现在的webapp使用客户端 JavaScript 处理用户提供的 Web 表单输入消除了与服务器通信的延迟,从而为最终用户带来更具交互性和响应性的体验。此外,客户端表单处理减少了网络流量和服务器负载。

浏览器执行的表单处理主要涉及检查用户提供的输入是否有错误。例如,接受信用卡付款的电子商务应用程序要求信用卡到期日有效(例如,是未来的日期并且是有效的月/日组合)。输入数据经过验证后,将作为 HTTP 请求的一部分发送到服务器,输入将作为请求的参数出现。如果接受此类请求的服务器假定提供的参数有效(例如,信用卡尚未过期),则它可能容易受到攻击。

这个假设确实是由浏览器端的 JavaScript 强制执行的;但是,恶意用户可以通过禁用 JavaScript、更改代码本身或简单地使用用户选择的任何参数值手动制作 HTTP 请求来规避客户端验证。具有参数篡改漏洞的服务器容易受到各种攻击(例如启用未授权访问、SQL 注入、跨站点脚本)。

贡献:

  1. 开发了第一个系统方法来检测网络应用程序中的参数篡改机会。
    • 专门用于形成验证代码的客户端 JavaScript 代码分析技术。
    • 应对黑盒漏洞分析的诸多挑战的输入生成技术。
    • 启发式算法,用于生成可能导致漏洞的输入并对其进行优先级排序
  2. 通过报告来自八个开源应用程序和五个在线网站的多个参数篡改机会,凭经验证明了 NOTAMPER 的使用。

2.2 HIGH LEVEL OVERVIEW

2.2.1 example

  1. attack1:禁用js,上图-4和1,则使得最终价格是相减的
  2. attack2:作者在一家金融机构发现了一个类似的漏洞,成功地在任意账户之间转移了资金。在创建表单时,下拉列表中填充了用户的信用卡账户号码(参数付款)。提交不在此列表中的账户号码,恶意用户可以购买产品并向他人账户收费。
  3. attack3:模式验证绕过。这种攻击使能够执行跨站脚本攻击并升级到管理员特权。
    Web表单确保交付说明(parameter directions)只包含大写和小写字母。特别是,为了防止对服务器进行命令注入攻击,禁止使用特殊字符和标点符号。通过规避这些检查,恶意用户可以发起XSS或SQL注入攻击。

这里作者认为一般开发者对服务器的验证设计考虑大于对用户输入的验证,所以第二种情况证明用户输入验证会出现参数篡改漏洞

p_{s e r v e r}(I)=\mathit{t r}{u e}\Rightarrow p_{c l i e n t}(I)=\mathit{t r}{u e}.
p_{s e r v e r}(I)=t r u e\wedge p_{c l i e n t}(I)=f a l s e.

2.3 NoTAMPER

假如针对之前的运行实例,分析器生成的f_{client}

\begin{array}{l}{{c o p i e s\ge0\wedge\left.c o p i e s2\ge0\right.}}\\ {{d i r e c t i o n s\in\left[\left.a-z\Delta-z\right.\right]\star}}\\ {{payment\in[(123.4-5678-9012-3456\ 78-9012)]\ ;}}\end{array}

输入生成器生成的良性输入:

\begin{array}{l}{{\{c o p i e s\rightarrow0,c o p i e s2\rightarrow0,d i r e c t i o n s\rightarrow"",p a y m e n t\rightarrow1234-5678-9012-3456\}.}}\end{array}

阴性输入:

\begin{array}{l}{{\{c o p i e s\rightarrow-1,c o p i e s2\rightarrow-2,d i r e c t i o n s\rightarrow"@*.",p a y m e n t\rightarrow1234-5678-9012-3456\}.}}\end{array}
  1. HTML/JavaScript Analyzer
    感觉这个只关注了表单提交,提取p_{client}的逻辑表示:f_{client}
    • 采用一种混合的具体符号执行方法[9](GODEFROID, P., KLARLUND, N., AND SEN, K. DART: Directed Automated Random Testing. SIGPLAN Not. 40, 6 (2005), 213–223.)来分析JavaScript,并确定对用户提供的数据加强的约束。
      符号执行提供了所有验证代码中控制路径的覆盖,并模拟用户提供数据的验证。
  2. Input Generator
    构建一系列输入h_{1},,h_{n} -> f_{client}(h_{i}) = false,一系列输入b_{1},,b_{n} -> f_{client}(b_{i}) = true
    提交到服务器,分别生成对应的响应,所需数据:
    • f_{client}
    • 使用可以手动覆盖的启发式方法来计算所需变量和变量类型的列表
    • 良性:其中所有必需的变量都有值并且所有值都是正确的类型
    • 阴性:将 fclient 转换为析取范式 (DNF) 1 并为每个析取构建一个敌对输入。
      • 生成一个恶意输入,其中副本违反约束(小于零)但方向满足约束(不包含标点符号),以及另一个输入,其中副本满足约束但方向不满足约束
    • 唯一变量列表
  3. Opportunity Detector
    将每个敌对响应 H_{i} 与良性响应B_{1},,B_{n}进行比较,以生成表示服务器接受 H_{i} 的可能性的分数。
    直观地说,每个良性响应都代表服务器的成功消息,敌对响应与良性响应越相似,敌对输入成功的可能性就越大,因此具有参数篡改机会。
    • 基于 Ratcliff 和 Obsershelp 的自制文档比较策略关于近似字符串匹配的算法[16]。近似匹配
      • 去除噪音:包含许多不依赖于服务器输入的可变元素,例如时间戳、用户名、登录人数。
      • (2) B1 中不在 B2 中的内容,以及 (3) B2 中不存在的内容在B1。元素 (2) 和 (3) 包含噪声,一旦分别从 B1 和 B2 中消除,我们就会得到相同的 HTML 文档 C1。为了分析敌意响应 hi,我们重复噪声消除过程,用C1和C2
  4. 将敌对的输入和响应将按照与良性响应的相似程度进行排序,并呈现给人类测试员。
  5. 测试员自由地验证敌对输入是否是真正的参数篡改漏洞,并通过向服务器发送修改后的敌对输入来探索每个漏洞的严重程度。

3. WAPTEC: Whitebox Analysis of Web Applications for Parameter Tampering Exploit Construction

用于参数篡改漏洞利用构造的 Web 应用程序白盒分析,感觉是上一篇论文的改版,上篇是黑盒方法虽然最适合测试服务器端代码不可用的网站,但需要人工将机会转化为实际的攻击。这篇白盒测试直接省去人工参与。

3.1 介绍

检测参数篡改漏洞的基本问题是识别服务器中“缺失”的验证检查,作者直接从客户端代码中提取规范。此规范随后可用于检查服务器端代码是否存在漏洞。

贡献:

  1. 在作者的公式中,当服务器端参数验证弱于客户端验证时,对于客户端提供的输入的格式是否正确,服务器比客户端执行更少的检查。这些弱点表明服务器上存在可被恶意用户利用的安全漏洞。
    每当发现这样的弱点时,作者的方法就会自动以漏洞利用的形式生成漏洞的具体实例。
  2. WAPTEC(参数篡改漏洞利用构造的白盒分析)的方法工具通过结合形式逻辑和约束求解、符号评估和动态程序分析的技术来执行 Web 应用程序漏洞分析。
    针对使用 LAMP(Linux、Apache、MYSQL、PHP)堆栈编写的应用程序,这是使用最广泛的 Web 应用程序开发和部署平台之一。

3.2 例子

考虑一个 Web 应用程序,它提供一个购物结账表单,其中包含文本字段名称、地址、商品数量、一个显示以前使用过的信用卡的下拉菜单以选择当前购买的信用卡,以及一个设置为“购买”的隐藏字段操作。(这些字段采用典型购物会话中的通常含义)。

清单 1 和清单 2 分别列出了该应用程序的客户端和服务器端代码。

可以看见数量验证检查未在服务器中出现,恶意客户端可能会通过提交负数量字段来执行此攻击,从而将计算的成本降低到较低的值。

3.3 approach

大概思路是:

  1. 找到服务器控制路径,如果采用该路径会导致输入被接受,即路径导致敏感操作(例如运行示例第 17 行中的 INSERT 查询)
    • 使用一种约束引导搜索的形式完成的,该搜索使用服务器应该接受的输入来探测服务器,然后分析服务器执行的代码以确定该控制路径是否导致敏感接收器。将服务器应该接受的导致执行敏感操作的任何输入称为良性输入。
  2. 找到导致客户端拒绝的每个此类控制路径的输入(例如向服务器提交负数量)。
    • 通过用输入探测服务器并检查结果控制路径上的敏感接收器来完成的,尽管这次输入是服务器应该拒绝的输入。服务器应该拒绝导致执行敏感操作的任何输入都是恶意输入。恶意输入通过构造参数篡改漏洞利用是正确的。
    • 生成阴性输入的论点:如果客户端代码拒绝输入,服务器也应该拒绝它;因此,每个满足 fclient 否定的输入都是潜在的恶意输入(参数篡改利用),约束求解器可以再次直接构造它。

4 Don’t Trust Your Code! Detect Missing Server-side Checks by Code Mutation

problem

第二个是:reCaptcha 验证仅通过客户端检查来强制执行,并且服务器不会检查 reCaptcha 令牌是否有效,因此攻击者可以通过从客户端代码中删除检查来绕过这些检查。

challenge

(1)提取的安全挑战:改变客户端检查来测试缺失的服务器端检查并非易事,有很多不相关if-else分支,3.3
(2)有效生成违反客户端检查输入:使用代码突变将违反的值分配给条件变量,从而生成与检查条件的否定相对应的输入?3.5

解决第一个challenge

遍历该函数的抽象语法树(AST)以识别两种类型的安全检查:
(1)专门用于引发错误或警告的if检查。
(2)对promise的反应,基于promise是否被满足或拒绝来执行不同的函数。

FENCEHOOPER将以下模式视为引发错误或警告的指标:
(1)使用throw语句抛出异常;
(2)使用alert()和window.alert()方法发出警告;
(3)使用关键词“error”,“exception”,“alert”调用其他引发错误的方法。

解决第二个挑战

在检查之前改变输入数据:(四种类型)

漏洞类型

Broken Authentication.绕过登录

Broken Data Integrity.输入不符合客户端开发人员强制执行的检查的数据

Legal Agreement Violation.

Broken Business Logic.

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注