web中src已斜线开头
Directory traversal (or path traversal) is a vulnerability, the exploitation of which enables an attacker to read arbitrary files on an application’s server (source code, application data, backend credentials, OS files). In some cases, an attacker can write information to the files stored on the server, thus changing data and behavior of an application.
目录遍历(或路径遍历)是一个漏洞,利用该漏洞,攻击者可以读取应用程序服务器上的任意文件(源代码,应用程序数据,后端凭据,OS文件)。 在某些情况下,攻击者可以将信息写入服务器上存储的文件,从而更改应用程序的数据和行为。
The vulnerability may arise when:
该漏洞可能在以下情况下出现:
- working with archives; 处理档案;
- working with paths based on user input. 根据用户输入使用路径。
Let’s see an example to find out how it looks like in practice.
让我们看一个示例,以了解实际情况。
这个怎么运作? (How it works?)
Let’s examine an example of reading an arbitrary file through directory traversal. An application outputs an image through HTML to a page:
让我们来看一个通过目录遍历读取任意文件的示例。 应用程序通过HTML将图像输出到页面:
<img src="/loadImage?filename=218.png">
Image files are kept on the server at /var/www/images/
. To load an image, the application adds the requested filename (filename
value) to the specified path. In our case, the application will read the file at /var/www/images/218.png
.
图像文件保存在服务器上的/var/www/images/
。 要加载图像,应用程序将请求的文件名( filename
值)添加到指定路径。 在我们的例子中,应用程序将读取/var/www/images/218.png
的文件。
An attacker can use the following request to get an arbitrary file:
攻击者可以使用以下请求获取任意文件:
https://website.com/loadImage?filename=../../../etc/passwd
The application will read the file at /var/www/images/../../../etc/passwd
.
应用程序将在/var/www/images/../../../etc/passwd
读取文件。
../
is a step up to the next level. Three consequent steps up from /var/www/images/
will lead to the root directory. Thus, the application will read the /etc/passwd
file.
../
是下一个台阶。 从/var/www/images/
三个后续步骤将进入根目录。 因此,应用程序将读取/etc/passwd
文件。
NB! Sometimes a vulnerable application may encode the symbol
/
as%2f
. Thus, the request may look like the following/..%2f..%2f..%2f..%2fetc%2fpasswd
注意! 有时,容易受到攻击的应用程序可能会将符号
/
编码 为%2f
。 因此,该请求可能看起来像以下/..%2f..%2f..%2f..%2fetc%2fpasswd
Example of vulnerable code (1):
易受攻击的代码示例(1):
return file_get_contens($_GET['filename']);
This vulnerability can be found when:
在以下情况下可以发现此漏洞:
- ZIP archives are unpacked ZIP档案已解压缩
- dynamic content is loaded to a page 动态内容已加载到页面
- symlink is processed 符号链接已处理
- PATH parameter is processed by the web server or proxying requests PATH参数由Web服务器或代理请求处理
- downloading attachments stored in file systems 下载存储在文件系统中的附件
另一个例子 (Another example)
Directory traversal often happens when ZIP archives are processed. A ZIP archive has a certain structure. Simply put, it has file names and compressed data. When working with an archive, a programmer reads records from it one by one and unpacks it to a specified directory. Here’s an example of code that processes ZIP archives:
处理ZIP归档文件时通常会发生目录遍历。 ZIP存档具有一定的结构。 简而言之,它具有文件名和压缩数据。 使用档案时,程序员会从档案中逐一读取记录,并将其解压缩到指定目录中。 这是处理ZIP存档的代码示例:
$zip = zip_open($uploadfile);
if ($zip) {
while ($zip_entry = zip_read($zip)) {
if (zip_entry_open($zip, $zip_entry)) {
file_put_contents(zip_entry_name($zip_entry),zip_entry_read($zip_entry));
zip_entry_close($zip_entry);
}
}
zip_close($zip);
}
Note that zip_entry_name($zip_entry)
gets from the archive a file name which has to be unpacked. The vulnerability comes from the fact that the header of ZIP can contain any value because it’s a simple string, for example ../../../test
. Unpacking a file with this name will result in a vulnerability.
请注意, zip_entry_name($zip_entry)
从档案中获取了必须解压缩的文件名。 该漏洞来自以下事实:ZIP标头可以包含任何值,因为它是一个简单的字符串,例如../../../test
。 使用此名称解压缩文件将导致漏洞。
However, this cannot be achieved with regular tools. There are utilities that allow creating an archive with the symbols that will land you in the root directory. You can read more about the ZIPSlip vulnerability following a link at the end of this article (see Useful links).
但是,使用常规工具无法做到这一点。 有一些实用程序允许创建带有符号的归档文件,这些符号会将您带入根目录。 您可以通过本文结尾处的链接,了解有关ZIPSlip漏洞的更多信息(请参阅有用的链接)。
修复和预防 (Fixes and prevention)
The surefire way to prevent vulnerability is to avoid user input being transferred to the API of a file system. To prevent attacks, two security levels should be implemented:
确保漏洞的肯定方法是避免将用户输入传输到文件系统的API。 为了防止攻击,应实现两个安全级别:
- User input validation before processing. It is necessary to check that user input contains only acceptable values, for example, letters and digits. 处理之前用户输入验证。 必须检查用户输入是否仅包含可接受的值,例如字母和数字。
- After validation, the application must add the input to the base directory and use API of the file system to canonicalize paths. A canonicalized path must start with a correct/expected base directory. 验证之后,应用程序必须将输入添加到基本目录中,并使用文件系统的API规范化路径。 规范化路径必须以正确/预期的基本目录开头。
File file = new File(BASE_DIRECTORY, userInput);
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
// process file
}
不正确的修复 (Incorrect fix)
Let’s consider a vulnerability in the Voyager admin panel.
让我们考虑Voyager管理面板中的漏洞 。
public function assets(Request $request)
{
$path = str_start(str_replace(['../', './'], '',urldecode($request->path)), '/');
$path = base_path('vendor/tcg/voyager/publishable/assets'.$path);
if (File::exists($path)) {
.....
}
Look at this string:
看一下这个字符串:
str_replace(['../', './'], '',urldecode($request->path))
It enables sequential filtering of the file name: first, for ../
, and then ./
. Let’s see what happens if we submit .....///test
as a file name:
它启用了对文件名的顺序过滤:首先是../
,然后是./
。 让我们看看如果将.....///test
作为文件名提交会发生什么:
str_replace(['../'],'', ".....///test") = "...//test
str_replace(['../'],'', ".....///test") = "...//test
str_replace(['./'],'', "...//test") = "../test
str_replace(['./'],'', "...//test") = "../test
Thus, we still managed to send a combination that results in directory traversal.
因此,我们仍然设法发送了导致目录遍历的组合。
有用的链接 (Useful links)
翻译自: https://medium.com/@hacktoryga/dot-dot-slash-and-web-app-crash-2b5ce73ad6ad
web中src已斜线开头