First of all, we need to express our point of view that, after all, website intrusion is to gain website management permissions, of course, this permission should be higher than the background management permission of the web site (I am sorry to take it out and say hello to others, right, isn't a website intrusion just to write a trojan script to the website directory? How to easily and effectively write scripts to the site, we may obtain the ftp password or even the root password through any means, but these cannot all be summarized into the intrusion through web vulnerabilities, this vulnerability can be exploited Based on web vulnerabilities. If there is a vulnerability, I believe that the upload vulnerability should be straightforward (and finally the upload vulnerability -_-!!).
Body
What is an upload vulnerability?
In my understandingBecause the programmer does not filter uploaded files or the filtering mechanism is not strict, malicious users can upload dynamic script pages to control website permissions through the uploaded script pages..
In simple terms, the filtering mechanism is not strict:
For example, a website only supports ASP scripts. In the upload function, the filter policy is "get the suffix after the last decimal point in the client file name, if the suffix is html, shtml, or asp, the program does not allow upload. Otherwise, the upload is successful ". If the programmer knows that the website only supports ASP parsing and does not support php or aspx parsing, other scripts cannot be executed even if they are uploaded successfully. In this case, we only need to limit asp. If you think the same way, it is really wrong. By default, the asa and cer suffixes all call asp's parsing dll. So, do you think such a program is safe? Many programmers may not understand this. If I restrict all the suffixes that can be executed as asp files on the premise of this authentication method, do you think it is safe? I will tell you later.
Here, I will briefly summarize the general categories of upload vulnerabilities (my personal abilities should be limited and I should leave it blank ):
I. No restrictions are imposed.
Ii. ClientJSVerify bypass (LocalJavascriptExtension detection)
III,HttpPacket header detection bypass (Content-typeDetection)
Iv. File Name definable Upload Vulnerability (custom file name, available0 × 00Write truncation, seeDvbbs6.0The same is true for the Upload Vulnerability)
5. Folder customizable Upload Vulnerability (custom folder name, available0 × 00Write truncation, seeDvbbs6.0Upload Vulnerability)
6. File Header detection bypass (Gif89aFile Header detection)
VII. Third-party resolution vulnerabilities (IIS,Apache,NginxResolution Issues)
8.
I believe that we have met these questions more or less and know the principles. I will not repeat them here. If you don't understand them, ask me or ask our common instructor search engine.
Let's start with a piece of code.
Obviously, the above function first obtains the content after the last decimal point in the user's file name, that is, the suffix. If the suffix is a word in the array defined in the third row, upload is not allowed, we even restricted shtml and html, and thought it was thoughtful.
Now let's see how we can break through him. After careful analysis, the program obtains the last decimal point of the file name to determine whether the file is allowed to be uploaded. If the upload is successful, name the temporary file with a value of date () and the file name. Then, move the temporary file to the directory we want to save.
For windows, the last decimal point of the file name will be "eaten" by default. You can try it and enter a decimal point at the end of the file name to save it. the decimal point will not appear, it was eaten. Linux will continue to write the decimal point.
With this concept, we will test this upload program. First, we will upload a trojan page test. php: Apparently the Upload Failed. Then we improved the address of the upload and wrote the following style (also the trojan page just now, we only manually add a decimal point to the input)
The received file name is "test. php ".."It is considered by the program to be allowed, because the value after the last decimal point is not in the blacklist range, the next program will write, date () add "_" to the current time number "120421003323" and the file name "test. php. ", that is," 120331142923_test.php".", I believe everyone has tried the previous tips. When the program writes a file name in windows, if the last digit is a decimal point in English, it will be eaten by default, the trojan is uploaded successfully.
In linux, it is still "120331142923_test.php ".."Format write, but it is still due to the parsing characteristics of apache and nginx. In most cases, it will continue to be executed as php. You can test the specific version.
Summary
Defense: some pure local detection, packet header detection, image header detection, image Body Detection getimagesize (), black and white list detection, as long as a little careless, it may be broken through, so, if we want to use these methods, we should first strictly understand the potential vulnerabilities and then fix the problems.
Finally, I would like to express my understanding in the following sentence: intrusion technology may be widely used by everyone, but this is far from enough. In actual penetration, due to various environmental problems, whether or not the penetration is the most important thing.
Author: char