Relative Path Overwrite（相对路径覆盖）是一种通过覆盖目标文件来利用相对URL的技术，简称RPO技术。
随着RPO（相对路径覆盖）技术在强网杯的web题中被提出，国内相继出现了不少相关的writeup。作为14年就被发现的技术，它的攻击技巧早已被拓展开，本期安仔课堂，ISEC实验室的老师对这项技术之前的研究成果进行了归纳，10分钟的时间，让我们跟随老师一起初探RPO攻击。
绝对路径与相对路径的区别
一、绝对路径
图1
二、相对路径
图2
我们可以发现：绝对路径的URL目标地址完整，包含了协议和域名，而相对路径的URL并不指定协议或域名，而是使用现有的目的地来确定协议和域名。
如何理解相对路径
使用当前路径并查找其中的目录，如mytest，或使用目录遍历技术，如../mytest。
工作方式以下方的样式表为例：
图3
上方样式表的链接元素使用相对URL，引用test.css，样式表的加载取决于所在站点目录结构的位置。
例如：如果在一个名为mytest的目录中，那么样式表将从mytest /Test.css加载。使用相对URL，浏览器不知道什么是正确的路径，因此，浏览器无法访问服务器的文件系统。
RPO原理解析
一、漏洞触发条件：
①配置错误的Apache服务器或者Ngnix服务器,URL重写
②相对路径JS、CSS样式表的调用
③存储允许CSS注入的XSS
④可控页面
注：为方便演示，以Ngnix服务器为例
二、关于触发条件：
对于用户看到的完全相似的URL，服务器的处理方式也有所不同。
以下方样式表为例：
图4
对于默认的Apache服务器来说：
%2f在这里并不会被解析，因为服务器不认识这个符号，因此它会认为
..%2f1.php是一个文件。
对于默认的Ngnix服务器来说：
Ngnix会把%2f进行解码，转化为../，从而使URL如下图所示：
图5
而我们知道../表示的是向前跳转一个目录，因此我们最终得到的URL是：
图6
我们简单梳理一下流程：
目标URL：
图7
网页代码：
图8
浏览器将提交的URL编码解码后发给服务器使用%2f代替/，把URL写为：
图9
结果：
服务器：
图10
浏览器：
图11
页面中导入的样式表为：
图12
浏览器认为test.css的根目录是：
/RPO/mytest/
而不是：
/RPO/mytest/test/
所以../../test.css跳到了更高一级的目录下。
伪造一个目录ISEC，尝试导入一个不存在的RPO/Isec/test.css。
伪造：
图13
结果：
服务器：
图14
浏览器：
图15
页面中导入的样式表为：
图16
浏览器的认知中，ISEC和%2fbasic是两个不同的目录，从而导入主域下任意样式表。
三、解读触发条件：
前提：
在利用CSS选择器之前，我们需要知道它是怎么进行解析的。在CSS2规范中，明确了在某些情况下，user agents必须忽略非法样式表的一部分，这个规范定义为忽略。这意味着user agents解析非法部分时，除非明确匹配到了开始和结束，否则将予以忽略，简单的说就是解析其中格式正确完整的部分，忽略非法语法。
结论：
浏览器在解析CSS样式时，会忽略非法的部分，直到找到正确的开始才会进行解析，一直到结束停止。所以我们植入CSS代码，欺骗CSS解析器忽略之前不合法的语法内容，从而加载我们注入的CSS内容，最终页面变成渲染后的红色，如下图所示：
图17
再加入XSS的内容，我们定义了一个全局的选择器：
图18
RPO攻击还原
实例：
在infinite security上我们找到这样一个简单的实例：
在下面的页面中，它存储了XSS，满足了条件，因此，在CSS中的表达式功能将执行JavaScript。
图19
现在通过分析源代码链接与href风格.css，让我们看看开发者工具或浏览器中的网络部分，我们可以通过从url结尾添加和去除/来看到RPO的行为。
通过删除style.css，我们得到404状态码响应。
图20
通过添加style.css，我们获得200OK状态码响应。
图21
由于Internet Explorer支持表达式，因此，为了运行这个代码，我们将在旧版本的IE中执行这个页面。当此页面加载到IE中时，IE中的CSS解析器将执行CSS部分，跳过HTML部分，执行XSS负载，最终执行XSS的payload。
图22
RPO（相对路径覆盖）技术作为14年的攻击方式，如今依然被广泛运用，近期举办的强网杯上也出现了类似题目， 网上有很多的思路，大家可搜索下方链接以作参考。
图23
RPO攻击扩展
最初的RPO攻击有一些（隐含的）限制：
①易受攻击的HTML和HTML加载的样式表必须是同一个文件。
②攻击者无法操作已加载样式表URL的查询字符串参数。
因此，我们来探讨几个特殊环境下避免这些限制的技术（如上实例），主要是利用Web服务器或浏览器解释URL的差异来欺骗浏览器或服务器。
（注：不同环境版本结果有出入）
例如：点.、斜杠/、反斜杠、问号？和分号；等字符及其编码的等价物在URL中具有特殊意义，服务器和浏览器可以通过交互让这些具有不同含义，这些不同的解释给了攻击者扩展RPO攻击的可能性。
一、在IIS/ASP.NET上加载另一个文件
前提条件：通过使用包含/的URL来遍历路径，可以欺骗浏览器将另一个文件作为样式表加载到IIS/ASP.NET上。
由Soroush Dalili发现，Poc：
图24
URL返回/demo/rpo/test.aspx的内容，因为%2f和/，在IIS/ASP.NET上被同等对待。
图25
同时， 因为浏览器不将%2f视为路径分隔符，HTML中的链接元素（如上文所示）将从
/demo/rpo/andivipage.css.aspx/style.css加载样式表。样式表URL的PATH_INFO部分，即/style.css的部分在服务器端被忽略了。
这意味着上述两种限制中的第一种，即关于文件路径的限制，已经成功的被规避。
注意：这种技术对攻击者来说非常方便，因为攻击者可控内容的URL有时与包含路径相对样式表的网页不同。
二、在Safari/Firefox上加载另一个文件
Safari在路径解释方面的独特之处在于它不对URL中的编码点（和其他字符）进行解码，攻击者可以将其用于另一种文件加载攻击。
假设Safari用户访问下面的URL：
图26
Safari按照原样把URL路径发送到服务器（PHP/Apache），服务器将解析路径中的.%2E，并返回/member/top.php的内容。
假设响应包含以下脚本元素：
图27
由于Safari不对URL中的编码点进行解码，加载的JS路径将是
/member/profile_photo.php/js/jquery.js，这意味着服务器加载了一个不同于主HTML的文件。在本例中，Profile_Photo.php返回的图像将在浏览器上作为JavaScript执行。
至于Firefox，它的独特之处在于如何处理跟踪编码的双点。
假设Firefox用户访问下面的URL：
图28
Firefox将路径发送到服务器，但是不解析最后编码的点，服务器对它进行解析，然后返回/members/的内容。
假设内容下面包含一个脚本元素：
图29
当Firefox在确定JS路径留下未解决的尾随点时，加载的JS路径将是
/member/profile_photo.php/js/jquery.js，这将返回Profile_Photo.php的内容。
注意：在这两种攻击中，攻击者都无法像在ASP.NET上一样自由地控制加载的资源路径。，具体而言，前一种攻击要求加载资源路径以../开头，而后一种攻击要求HTML路径以/结尾。
三、在WebLogic/IE上加载另一个文件
与IIS/ASP.NET一样，WebLogic对待%2f和/是平等的，但是上述对ASP.NET的攻击并不仅仅适用于WebLogic，原因如下：
①WebLogic需要分号来添加字符串到URL的末尾；
②像..%2F这样的字符串是在分号不会导致服务器遍历之后才出现（WebLogic在第一个分号出现后完全忽略了一个字符串）。
因此，我们使用另一种方法便能成功攻击，如下图所示：
图30
这个URL将返回/aa/Test1Servlet的内容，因为如上所述，WebLogic只是在第一个分号之后忽略一个字符串。
假设内容包含下面的链接元素：
图31
当浏览器确定样式表URL时，原始URL中的.%2E/被解码为../，这样发送给服务器的样式表路径将是/aaa/test2Servlet；/style.css，而它作用于/aaa/test2servlet的内容。
这意味着与第一个HTML不同的HTML文件被成功加载为样式表。
攻击要求
①.%2E在初始HTTP请求中按原样发送；
②它们在下一个样式表加载请求中对这些事件进行解码。
注意：这两种情况只有在IE上才能满足， 攻击URL在位置标头中提供。
图32
换句话说，如果攻击URL是在中提供的，或者只是在地址栏中输入，则此技术不起作用，因为处于这些情况时，在向服务器发送初始请求之前，IE就会立即解析路径中的.%2E/ 。
四、在WebLogic+Apache上加载带有查询字符串的文件
在基于Java的大型企业系统中，我们经常可以看到将Apache置于WebLogic前面的系统架构。对于这个构成，Oracle提供了一个Apache模块（mod_wl.so），它就像他们之间的反向代理。
有趣的是，在将URL路径传递给后端WebLogic之前，该模块以一种非常独特的方式规范URL路径。具体来说，它将URL路径中的%3F解码为？，这显然会混淆URL解析器，给攻击者提供机会。
图33
假设内容包含下面的链接元素：
图34
在本例中，最终样式表从浏览器发送到Apache的路径是/aaa/test1servlet？param={}*{color：red}/style.css，这是因为浏览器将%3F视为URL路径的一部分。因此，在确定最终样式表的路径时，浏览器不会删除该部分。
如前所述，样式表中的URL由模块解码，然后发送到后端WebLogic，以便在WebLogic中将之后的部分视为查询字符串，这意味着本节开头显示的第二个限制，即查询字符串，成功地被绕过。
特别声明：文章来源用户上传并发布，本站只提供信息存储服务，不拥有所有权，内容仅供参考。