Part I Preface
The most popular website attack method on the Internet now is SQL Injection. Although SI technology is easy to learn and use, and it is easy to obtain greater permissions, because its popularity is too great, programmers with a little security awareness will notice this problem now, and the data submitted through the GET method will be recorded by the server, making it easy for network administrators to find intruders.
Non-SI attacks have relatively little server operation permissions, but they are still very useful for intrusions that aim to obtain data.
Part II Method Introduction
There are several conventional non-SI attacks:
1. Cross-site scripting attack (XSS)
Cross-site scripting attacks will not directly damage the website server. The main target of attacks is the website visitors. Here intruders have roughly three purposes:
First, infringe on the website page viewers: such as adding automatically downloaded codes to the website page, or using IE Frame vulnerabilities to implant *s to the browser, or hijacking the browser.
The second is to steal the browser's cookies. The intruder can create a page that can accept and save information on his website, and add a hidden iframe with a length and width of 0 on the page of the intruded website. The address is: /?info=. The page on the server side accepts the info information and saves it in the database, so that the intruder can obtain the browser's cookies information on the intruded website. If the password of ordinary users is stolen, the harm is not very great, but if the intruder uses social engineering to allow the administrator to access the page after logging in and keeping the password in cookies, he can steal the administrator's password and further control the website.
The third is to use a large number of visitor requests to repeat a certain operation. A while ago, a business website reported that a famous domestic search engine added a hidden iframe to its search alliance to visit the business website, and conducted a DDOS attack on it, causing its server to be overloaded. Not to mention whether this matter is true or false, but this idea is something we should pay attention to. There is an article titled "Playing Under the X Tree" in the 11th issue of "Hacker X Files" in 2004 (page 62). The author used cross-site scripting attack to insert posting code into the page. The huge number of visits caused the number of spam to soar, and the server was overwhelmed and almost collapsed.
The method of cross-site attack seems simple, you only need to add dangerous code to the submitted content (such as message and comment), but how to bypass the program's filtering of illegal characters is a very complicated thing. Commonly used methods include: changing case, converting to ASII code or escape characters, calling remote js script files and other script deformation and hidden methods, using Flash Geturl parameters, etc.
Tips
1. How to deal with form detection.
In order to prevent cross-site scripting attacks, some websites add some Javascript code to their forms to detect the value of the text box. If it is illegal, a dialog box will pop up and submit is prohibited. However, this restriction that is only made on the client is equivalent to no restrictions. We can save the web page locally, remove the corresponding detected JS code, and then modify the form action attribute in the web page to point to the website, and submit it. If the website does not verify again on the server side, it will be hacked. (This loophole exists in the Hebei Province high school students’ information technology examination procedures.)
2. About UBB.
UBB code is a means used by some programs to limit the html code while not causing the submitted information to be too monotonous. The method is to let the user use some specific tags and then convert these tags on the server side. However, if the converted statement is not written properly, it will still cause danger. (We will further show how to bypass UBB in the following example.)
Please use examples to experience it with me:
Example 1-1: Script insertion without filtering
This is a version of the "Customer Feedback" function of a Dynamic Mall, which is a self-submit page called, where the code that stores data to the database is like this.
rs(\\"fksubject\\")=checkFFSQLStr(trim(request(\\"fksubject\\")))
rs(\\"fkleixing\\")=checkFFSQLStr(request(\\"fkleixing\\"))
rs(\\"fkcontent\\")=checkFFSQLStr(trim(request(\\"fkcontent\\"))) 'Look, no dangerous character filtering is performed
rs(\\"fkusername\\")=checkFFSQLStr(trim(request(\\"fkusername\\")))
rs(\\"fkemail\\")=checkFFSQLStr(trim(request(\\"fkemail\\")))
rs(\\"fktel\\")=checkFFSQLStr(trim(request(\\"fktel\\")))
rs(\\"fklaizi\\")=checkFFSQLStr(trim(request(\\"fklaizi\\")))
rs(\\"fkdate\\")=now
rs(\\"fkip\\")=(\\"remote_addr\\")
It is not difficult to find that before the program stores the data into the database, it only filters whether there are characters that can constitute SI (this filter is precisely unnecessary because the parameters do not introduce query conditions), and does not filter dangerous characters such as script, and the page that displays the message is not filtered first and then displayed. If we submit <script>alert()</script> in the message, the user's cookies information can be popped up. (As shown in Figure 1)
Example 1-2: Script insertion of poorly filtered UBB
A piece of the UBB conversion page of a famous blog program is as follows:
Str = Replace(Str, \\"script\\", \\"script\\")
Str = Replace(Str, \\"SCRIPT\\", \\"SCRIPT\\")
Str = Replace(Str, \\"Script\\", \\"Script\\")
Str = Replace(Str, \\"script\\", \\"Script\\")
We can submit characters like sCRipt to bypass this limitation, such as submitting information
[ img ]javascript:()[ /img ](remove spaces)
The window can be closed.
2. Overreach of power
The overright attack is a vulnerability that causes programmers to detect access to pages that are not perfectly caused by programmers to allow intruders to access pages that only specific users or administrators can access.
This overreach of authority reminds me of the popular "chat room kicking method" a long time ago (about 2000 years ago), which uses the page responsible for kicking people in some chat room programs with incomplete user permission detection to achieve the purpose of kicking people at will.
However, this kind of vulnerability that exceeds the administrator's permissions is usually more hidden, especially for non-open source programs, which can only be guessed based on experience. Let’s take a look at an example of the more ordinary user permissions: the page of a program that modifys user information is introduced into the program by obtaining GET parameters and displaying relevant data, such as: /?userid=Daniel. This was originally a modification of user Daniel’s information, but if the program does not add other verification, we can modify any user’s information by modifying the value of the parameter, such as submitting /?userid=Kitty to modify the Kitty user’s information.
When creating such programs, programmers should verify the session to determine whether the user is logged in, and should obtain the currently logged in username from the session. Other data such as Get, cookies, etc. are untrustworthy.
Another type of overpowering, we can call it "more step by step". This type of vulnerability is targeted at some processes that require N steps to be completed. Step X does not detect whether the X-1 step is completed, allowing the attacker to skip the previous X-1 step. This vulnerability often occurs in the program that retrieves passwords. The page that finally completes verification and modifyes the password is just placed in the web page in a hidden domain, but no relevant detection is performed in the next step, resulting in the password of any user that can be modified.
Tips
1. Utilization of hidden domains.
Many programmers like to use form hidden domains instead of sessions to pass parameters that appear in some steps in the program. For some non-sensitive data, this can save a certain amount of server resources, but for some sensitive data, this is very dangerous, because although the user cannot see the hidden domain on the web page, the user can view the source code to find the hidden domain, and can achieve the purpose of overemphasis by saving the web page locally and modifying the value of the hidden domain.
OK, let's look at a few examples:
Example 2-1: A step-by-step loophole in a certain version of the Dynamic Mall to retrieve user passwords
This version of Dynamic Mall has many loopholes. The part of the password recovery is divided into 4 pages, ~, which corresponds to the operations of filling in the username, filling in the prompt password answer, resetting the password, and updating the new password to the database. This is what some of the code is written.
<%username=request(\\"username\\")
passwd=md5(trim((\\"passwd\\")))
set rs=(\\"\\")
sql=\\"select * from [user] where username='\\"&username&\\"'\\"
sql,conn,1,3
If Then
%>
<script language=\\"javascript\\">
alert(\\"This user has not registered yet, please register on the homepage!\\")
=\\"javascript :()\\"
</script>
<%
else
rs(\\"userpassword\\")=passwd
end if
set rs=nothing
set conn=nothing%>………
It can be found that the first line does not detect whether the data has been filled in the relevant information.
Suppose we want to steal the user Kitty's password for some reason: We can do this: first register a new user Daniel, write down the answers to the prompts, and then retrieve the password until this page, save this page locally, open the page with notepad, change the Daniel in the form action attribute value to Kitty, and add the URL in the complete page, then open this page locally, fill in the password and submit it to modify the Kitty's password to the password you just filled in on this page.
Example 2-2: The overreach of the permission of Jiuku Network’s personal homepage space management system 3.0:
Detection of login in the program is achieved by including the file on the page.
<%if session(\\"user_userid\\")=\\"\\" or session(\\"user_username\\")=\\"\\" then 'Cause of the vulnerability
\\"<script>alert('Sorry, you haven't logged in or have an error in logging in!');=''</script>\\"
end if
%>
It can be seen that this file only checks whether the session is empty, but does not check whether the operation is of the currently logged in user! Therefore, this program has many vulnerabilities to override the authority. First, look at the vulnerability of override the information of users: after logging in, you can see that the interface is divided into three frameworks: upper, left and right. The frame at the top is mainly a few navigation connections. Press and hold the shift point to "Modify Personal Information" to open it in a new window. The address is: http://127.0.0.1/?userid=39&username=Daniel. It is not difficult to see that the value of the username parameter in the address is the current username, so let's try changing it... Open the page http://127.0.0.1/?userid=39&username=Kitty, the information we filled in when registering a Kitty user is displayed on the Bingo! The webpage shows the information we filled in when registering a Kitty user! Change it casually... Here we can modify its password to prompt questions and answers, and then modify the user's password through the "Forgot Password" function. Let’s look at the vulnerability of displaying and modifying any user files. After detection, the page responsible for displaying the file list is http://127.0.0.1/?userid=39&username=Daniel&path=Daniel. We can browse, upload, delete, change the name of the files on the server by modifying the path value.
Example 2-3: Vulnerability in LB5000 modifying registration statement
Due to the overriding vulnerability of Lei Ao’s LB5000 and the two files, the attacker can directly modify the forum’s “Registration Statement” and “Short Message Welcome Information”. You can modify the "Registration Statement" by submitting the following request: / cgi-bin/?action=process&therules=The content to be modified. We can write some cross-site code through this.
3. Cookies cheating
What are cookies? Cookies are text files stored in the browser directory that record information you access to a specific site and can only be read back by the site where the cookies were created. They consist of about 255 characters and only occupy 4KB of hard disk space. When a user is browsing a site, it is stored in the client's memory. After exiting the browser, it is stored in the user's hard disk. Most of the information stored in cookies is ordinary, such as when you browse a site, this file records each keystroke information and the address of the visited site. However, many Web sites use cookies to store private data, such as registration passwords, usernames, credit card numbers, etc.
Cookies spoofing is to modify the cookies to be read by the client to the value we want to disguise on the client to deceive the program, making it mistakenly believe that we are logged in users to achieve a certain purpose. It can be said that this is also a way to override the authority.
We still say that some programmers lack risk estimates and trust clients too much. Storing sensitive information that should be stored in session in cookies causes this vulnerability, so this vulnerability is relatively hidden.
The general idea of conducting this kind of attack is to obtain legal cookies->using tools to modify cookies->access restriction page, which is successful in overdoing rights.
Suppose we have a legal account on the site, and now we want to log in with the user Kitty, but we don't have Kitty's password (nonsense, otherwise what else will attack...). Let's try to use cookies to spoof the purpose:
Log in as Daniel and choose to save login information, close the browser, use the IECookiesView software to open the cookies information of the machine, select the site, modify the username value to Kitty, visit the website again, and find that we have logged in as Kitty.
However, this kind of attack also has a relatively big flaw. Not to mention whether the website saves information in cookies, some websites save usernames and passwords in cookies. Each time they visit, they first check based on the username and password, and then determine whether it is legal. Therefore, this vulnerability is not very effective when used alone, but it is much easier to use with other intrusions. For example, when a certain site's database is downloaded, the passwords in it are all MD5 encrypted. Unless the MD5 hash value is brute-forced, it is impossible to log in on the website. However, if the website saves the username and password after MD5 in cookies, we can apply it. Or the website's SI prevention measures are relatively strict, and the injection point cannot be found in the url, so you can find the injection point in the cookies, etc. Some websites save users' permissions in cookies, and can also achieve the purpose of escalating permissions through modification.
Example 3-1 Deception vulnerability of a downloader:
The code for processing login is as follows:
<%If Cookies(\\"down_Isadder\\")=\\"\\" then%>
<script language=\\"Vbscript\\">
msgbox(\\"Sorry, you do not have permission to manage users! If you are an administrator, please log in!\\")
()
</script>
<%Else%>
…………
It's so dizzy. It only checks whether the cookies are empty, so we use IECookiesView to change the value of down_Isadder to any value (of course, except for the null value) to log in to management.
Example 3-2: L-blog's cookie overriding upload fraud vulnerability:
This recent vulnerability has really destroyed WebLog, including many hackers. There is a logical vulnerability in L-Blog's extracted cookies file that allows any user to upload files across the administrator's permissions.
Part of the code of the file:
IF memStatus="SupAdmin" OR memStatus="Admin" Then
IF ("action")="upload" Then
It can be seen that the program detects whether the value of SupAdmin is the corresponding value to the administrator. If so, uploading is allowed, and not detecting who the logged in user is. Let’s look at the program that verifies cookies and check that if memName (the user name obtained in cookies) is empty, no operation will be performed. If not empty, verify that the saved username and password are correct and cookies are not cleared correctly. This leaves us a vulnerability. If the username value (memName) in cookies is empty and the user permission (memStatus) is not empty, the file will not verify the username and password. However, if the upload page detects that memStatus is an administrator, it can be uploaded.
We can first register an ordinary user, log in and save cookies, modify cookies to make the value of memName empty, the value of memStatus is SupAdmin or Admin, and then you can upload it.
However, we can only upload certain types of files. We cannot upload Asp *s. What should we do... Let's take a look at how to upload Asp *s.
4. Illegal upload loophole
To be legal and illegal, let’s first talk about two simple vulnerabilities that are not considered vulnerable.
Some programs restrict extensions such as asp, asa, etc. cannot be uploaded, but we look at the settings of IIS and found that some extensions are explained by cer. So if some programs do not allow uploading asp files, we can change the extension of the * to cer and then upload. At this time, if the server does not remove the resolution of cer, we can run the *. There are also some files with extensions that can execute SSI (Server Side Include) instructions, such as stm, upload a file with the content of " <!--#include file=""-->", and then access this file to see the content of the file. Therefore, when programmers perform upload detection, they should set what kind of files are allowed to be uploaded instead of what kind of files cannot be uploaded.
Let’s talk about the vulnerability in the upload program.
The upload loophole of the Dynamic Network forum that appeared a while ago has been storms. Daniel also used this loophole to attack many stubborn broilers. Let’s analyze the upload of Dynamic Network first:
Dongwang originally did not allow uploading dangerous files such as asp, but the uploading process has certain loopholes that cause the parameters obtained by the program to be incorrect, allowing the intruder to upload any file.
First look at a page submitted and uploaded reg_upload.asp:
<form name=\\"form\\" method=\\"post\\" action=\\"\\" enctype=\\"multipart/form-data\\" >
<input type=\\"hidden\\" name=\\"filepath\\" value=\\"uploadFace\\">
<input type=\\"hidden\\" name=\\"act\\" value=\\"upload\\">
<input type=\\"file\\" name=\\"file1\\">
<input type=\\"hidden\\" name=\\"fname\\">
<input type=\\"submit\\" name=\\"Submit\\" value=\\"Upload\\" onclick=\\"=,[0].=true,
[0].=true;\\">
</form>
The program extracts the values in the file1 form and the fname form to make judgments. In other words, the program will detect the asp file to be uploaded directly from the page. However, we can construct the data packets ourselves and submit them using NC to achieve the purpose of cross-detection. But our main problem is that the uploaded file must be in asp format. Although the value of file1 is legal, what should we do if the purpose of saving the extension is asp?
There is a sentence in the componentless upload class used by Dynamic Network that is written like this:
filename=formPath&year(now)&month(now)&day(now)&hour(now)&minute(now)&second(now)&ranNum&\\".\\"&fileExt
This filename is the file name of the saved file generated by the program. The key to detecting a string in a computer is to see if it encounters a '' character. If so, it is considered that the string is over. That is to say, when we construct the path to upload the file, we just need to deceive the computer and make it think that path parameters like "" have ended, and we can achieve our goal.
This is the analysis of the principle of this vulnerability. Many uploads now have this vulnerability. It is too tiring to catch the packet first and then submit it manually. Daniel recommends that you use some upload vulnerability exploit tools online to reduce the burden.
Let’s take a look at a loophole in My Power 3.51. Part of the code of its upload page Upfile_Soft.asp is as follows:
Fot i=0 to ubound(arrUpFileType)
If fileEXT=trim(arrUpFileType(i)) then
Enableupload=true
Because the upload class used by My Power can upload multiple files, we can see from the above code that if the extension of the N-1th file is illegal when uploading multiple files, and the extension of the Nth file is legal, it can pass the detection. So we just need to construct the page ourselves, upload two files, and the second extension can be uploaded by the program, that's fine. However, the My power system prohibits external submission of forms. How to bypass this restriction? Please see - the offense and defense of forms.
Tips:
1. Use the database backup and recovery function to turn legal and illegal.
After all, there are still many systems that do not have upload logic vulnerabilities, so how do we upload script *s? This trick requires you to log in to the background and the website system has the functions of backing up and restoring the database. Now, the * horse is renamed to a legal extension through legal channels, and then the uploaded file name is written in the backup and recovery path on the page of backup and recovery, and then restore it. Since the program stores the database with the asp extension, the * horse can also be parsed normally.
5. The offense and defense of the form
Some of the unsafe factors about forms in the program have been mentioned in some places in the previous article. Let’s summarize it now. For form attacks, the main idea is to save the page containing the form locally, modify and remove relevant restrictions, and complete the action submission address to the address on the website, and then submit it.
So it is not difficult to see that everything about the form is dangerous and untrustworthy if it is not verified again on the server side. It is recommended that programmers try to verify again on the server side while doing form legality checks on the client side and add corresponding code prohibited from external submission on the server side. :
<%server_v1=Cstr((\\"HTTP_REFERER\\"))
server_v2=Cstr((\\"SERVER_NAME\\"))
if mid(server_v1,8,len(server_v2))<>server_v2 then
\\"<br><br><center><table border=1 cellpadding=20 bordercolor=black bgcolor=#EEEEEE width=450>\\"
\\"<tr><td style='font:9pt Verdana'>\\"
\\"The path you submitted is incorrect. Please do not mess with this parameter if you are prohibited from submitting data from outside the site!\\"
\\"</td></tr></table></center>\\"
end if%>
Let's think about the limitations of forms: Js legality check, hidden domain, and non-modified domain.
I don’t know if you still remember the forum group of the ofstar forum. It uses a readonly domain to display members of a certain group. We can download the web page, remove the readonly attribute, and then add the members you want to join this forum yourself, and then submit...
Tips:
1. Bypass the prohibition of external submissions:
You can write a socket program yourself to modify the value of http_referer, but this method is more troublesome, so I will introduce a simple one.
This trick requires you to upload images. When IE opens an image, if the image contains html code, it can run its code just like a web page. In this way, we can change the constructed page to an image, upload it, access this page and submit it on the server side. (Note: When constructing the page, you must write all basic tags such as <html>.)
Example 5-1: Vulnerability to upload to any directory in Jiuku Network’s personal homepage space management system 3.0:
After logging in, click the "Upload File" button and a web page pops up. There is a text box for uploading, and there is also a text box for uploading the directory, but it cannot be modified. Save this page in IE, and then find the 44th line of the file. The code is: <LI>Upload to: <INPUT class=INPUT style="WIDTH: 200px" ReadOnly…We delete this ReadOnly, then find the 37th line of the file, complete the value in the action attribute of the form tag (that is, add the website address), and then open the page locally. At this time, the "Upload" text box can be modified. We change it to:../, select file upload, and you can find that this file has been uploaded to the previous directory.
6. Vulnerabilities in the content of brute library and brute file
Everyone has heard of the %5c riot vulnerability. It is to change the address bar closest to the file name to "%5c" for the page that operates the database. If the following conditions are met, you can see the path of the database: the general error return page is provided by local IE, so we must first turn off the local error page. Specifically, in the menu item 'Tools->Internet Options->Advanced->Show friendly information'; if the other party's database is Access-type; the %5c riot requires a secondary directory, and the first-level directory cannot succeed; the other party's page has no fault-tolerant statements. The principle is quite complicated, please Google it yourself.
Some programmers like to write the page extension of include as inc, and many tutorials also suggest this, but this makes the program have a big vulnerability. Since inc is not parsed by default, it is displayed directly in text, so if others can directly access the page defined by your database (such as) and know the database address or SQL account password.
In order to prevent software downloads, some websites use a page to read the software and then send it to the client in the form of output stream. The file name parameters are usually attached to the address in GET. For example, /?path=, we can first guess the location of the data link file relative to the software library and change the value of the path parameter. If you are lucky, you can download the unresolved data link file.
Part III Summary and Postscript
It was early morning, the sun rose, and the sun shone on the earth. This article I spent about 3 days of spare time basically ended here, but I want to emphasize that non-SI loopholes in the website program are far more than this, and many unknown logical loopholes have not been discovered. Due to the limitations of space and time, this topic only briefly introduces some of the most commonly used methods at present. I hope Daniel can play a role in attracting everyone. If you really study the code of some programs on the Internet carefully, you can find that many loopholes that have not been discovered by others have appeared.
The loophole is not terrible, what is terrible is that programmers do not have a rigorous attitude and a complete and comprehensive thinking.
The old editor Tudou once asked me how I thought of this topic. In fact, I just feel deeply regretful and worried about the behavior of novices (including myself) who only know how to use NBSI to randomly bet on websites. Hackers who only know how to use tools are not hackers. We must learn to use our own ideas to discover vulnerabilities and patch vulnerabilities in order to achieve real technical improvements.
The most popular website attack method on the Internet now is SQL Injection. Although SI technology is easy to learn and use, and it is easy to obtain greater permissions, because its popularity is too great, programmers with a little security awareness will notice this problem now, and the data submitted through the GET method will be recorded by the server, making it easy for network administrators to find intruders.
Non-SI attacks have relatively little server operation permissions, but they are still very useful for intrusions that aim to obtain data.
Part II Method Introduction
There are several conventional non-SI attacks:
1. Cross-site scripting attack (XSS)
Cross-site scripting attacks will not directly damage the website server. The main target of attacks is the website visitors. Here intruders have roughly three purposes:
First, infringe on the website page viewers: such as adding automatically downloaded codes to the website page, or using IE Frame vulnerabilities to implant *s to the browser, or hijacking the browser.
The second is to steal the browser's cookies. The intruder can create a page that can accept and save information on his website, and add a hidden iframe with a length and width of 0 on the page of the intruded website. The address is: /?info=. The page on the server side accepts the info information and saves it in the database, so that the intruder can obtain the browser's cookies information on the intruded website. If the password of ordinary users is stolen, the harm is not very great, but if the intruder uses social engineering to allow the administrator to access the page after logging in and keeping the password in cookies, he can steal the administrator's password and further control the website.
The third is to use a large number of visitor requests to repeat a certain operation. A while ago, a business website reported that a famous domestic search engine added a hidden iframe to its search alliance to visit the business website, and conducted a DDOS attack on it, causing its server to be overloaded. Not to mention whether this matter is true or false, but this idea is something we should pay attention to. There is an article titled "Playing Under the X Tree" in the 11th issue of "Hacker X Files" in 2004 (page 62). The author used cross-site scripting attack to insert posting code into the page. The huge number of visits caused the number of spam to soar, and the server was overwhelmed and almost collapsed.
The method of cross-site attack seems simple, you only need to add dangerous code to the submitted content (such as message and comment), but how to bypass the program's filtering of illegal characters is a very complicated thing. Commonly used methods include: changing case, converting to ASII code or escape characters, calling remote js script files and other script deformation and hidden methods, using Flash Geturl parameters, etc.
Tips
1. How to deal with form detection.
In order to prevent cross-site scripting attacks, some websites add some Javascript code to their forms to detect the value of the text box. If it is illegal, a dialog box will pop up and submit is prohibited. However, this restriction that is only made on the client is equivalent to no restrictions. We can save the web page locally, remove the corresponding detected JS code, and then modify the form action attribute in the web page to point to the website, and submit it. If the website does not verify again on the server side, it will be hacked. (This loophole exists in the Hebei Province high school students’ information technology examination procedures.)
2. About UBB.
UBB code is a means used by some programs to limit the html code while not causing the submitted information to be too monotonous. The method is to let the user use some specific tags and then convert these tags on the server side. However, if the converted statement is not written properly, it will still cause danger. (We will further show how to bypass UBB in the following example.)
Please use examples to experience it with me:
Example 1-1: Script insertion without filtering
This is a version of the "Customer Feedback" function of a Dynamic Mall, which is a self-submit page called, where the code that stores data to the database is like this.
rs(\\"fksubject\\")=checkFFSQLStr(trim(request(\\"fksubject\\")))
rs(\\"fkleixing\\")=checkFFSQLStr(request(\\"fkleixing\\"))
rs(\\"fkcontent\\")=checkFFSQLStr(trim(request(\\"fkcontent\\"))) 'Look, no dangerous character filtering is performed
rs(\\"fkusername\\")=checkFFSQLStr(trim(request(\\"fkusername\\")))
rs(\\"fkemail\\")=checkFFSQLStr(trim(request(\\"fkemail\\")))
rs(\\"fktel\\")=checkFFSQLStr(trim(request(\\"fktel\\")))
rs(\\"fklaizi\\")=checkFFSQLStr(trim(request(\\"fklaizi\\")))
rs(\\"fkdate\\")=now
rs(\\"fkip\\")=(\\"remote_addr\\")
It is not difficult to find that before the program stores the data into the database, it only filters whether there are characters that can constitute SI (this filter is precisely unnecessary because the parameters do not introduce query conditions), and does not filter dangerous characters such as script, and the page that displays the message is not filtered first and then displayed. If we submit <script>alert()</script> in the message, the user's cookies information can be popped up. (As shown in Figure 1)
Example 1-2: Script insertion of poorly filtered UBB
A piece of the UBB conversion page of a famous blog program is as follows:
Str = Replace(Str, \\"script\\", \\"script\\")
Str = Replace(Str, \\"SCRIPT\\", \\"SCRIPT\\")
Str = Replace(Str, \\"Script\\", \\"Script\\")
Str = Replace(Str, \\"script\\", \\"Script\\")
We can submit characters like sCRipt to bypass this limitation, such as submitting information
[ img ]javascript:()[ /img ](remove spaces)
The window can be closed.
2. Overreach of power
The overright attack is a vulnerability that causes programmers to detect access to pages that are not perfectly caused by programmers to allow intruders to access pages that only specific users or administrators can access.
This overreach of authority reminds me of the popular "chat room kicking method" a long time ago (about 2000 years ago), which uses the page responsible for kicking people in some chat room programs with incomplete user permission detection to achieve the purpose of kicking people at will.
However, this kind of vulnerability that exceeds the administrator's permissions is usually more hidden, especially for non-open source programs, which can only be guessed based on experience. Let’s take a look at an example of the more ordinary user permissions: the page of a program that modifys user information is introduced into the program by obtaining GET parameters and displaying relevant data, such as: /?userid=Daniel. This was originally a modification of user Daniel’s information, but if the program does not add other verification, we can modify any user’s information by modifying the value of the parameter, such as submitting /?userid=Kitty to modify the Kitty user’s information.
When creating such programs, programmers should verify the session to determine whether the user is logged in, and should obtain the currently logged in username from the session. Other data such as Get, cookies, etc. are untrustworthy.
Another type of overpowering, we can call it "more step by step". This type of vulnerability is targeted at some processes that require N steps to be completed. Step X does not detect whether the X-1 step is completed, allowing the attacker to skip the previous X-1 step. This vulnerability often occurs in the program that retrieves passwords. The page that finally completes verification and modifyes the password is just placed in the web page in a hidden domain, but no relevant detection is performed in the next step, resulting in the password of any user that can be modified.
Tips
1. Utilization of hidden domains.
Many programmers like to use form hidden domains instead of sessions to pass parameters that appear in some steps in the program. For some non-sensitive data, this can save a certain amount of server resources, but for some sensitive data, this is very dangerous, because although the user cannot see the hidden domain on the web page, the user can view the source code to find the hidden domain, and can achieve the purpose of overemphasis by saving the web page locally and modifying the value of the hidden domain.
OK, let's look at a few examples:
Example 2-1: A step-by-step loophole in a certain version of the Dynamic Mall to retrieve user passwords
This version of Dynamic Mall has many loopholes. The part of the password recovery is divided into 4 pages, ~, which corresponds to the operations of filling in the username, filling in the prompt password answer, resetting the password, and updating the new password to the database. This is what some of the code is written.
<%username=request(\\"username\\")
passwd=md5(trim((\\"passwd\\")))
set rs=(\\"\\")
sql=\\"select * from [user] where username='\\"&username&\\"'\\"
sql,conn,1,3
If Then
%>
<script language=\\"javascript\\">
alert(\\"This user has not registered yet, please register on the homepage!\\")
=\\"javascript :()\\"
</script>
<%
else
rs(\\"userpassword\\")=passwd
end if
set rs=nothing
set conn=nothing%>………
It can be found that the first line does not detect whether the data has been filled in the relevant information.
Suppose we want to steal the user Kitty's password for some reason: We can do this: first register a new user Daniel, write down the answers to the prompts, and then retrieve the password until this page, save this page locally, open the page with notepad, change the Daniel in the form action attribute value to Kitty, and add the URL in the complete page, then open this page locally, fill in the password and submit it to modify the Kitty's password to the password you just filled in on this page.
Example 2-2: The overreach of the permission of Jiuku Network’s personal homepage space management system 3.0:
Detection of login in the program is achieved by including the file on the page.
<%if session(\\"user_userid\\")=\\"\\" or session(\\"user_username\\")=\\"\\" then 'Cause of the vulnerability
\\"<script>alert('Sorry, you haven't logged in or have an error in logging in!');=''</script>\\"
end if
%>
It can be seen that this file only checks whether the session is empty, but does not check whether the operation is of the currently logged in user! Therefore, this program has many vulnerabilities to override the authority. First, look at the vulnerability of override the information of users: after logging in, you can see that the interface is divided into three frameworks: upper, left and right. The frame at the top is mainly a few navigation connections. Press and hold the shift point to "Modify Personal Information" to open it in a new window. The address is: http://127.0.0.1/?userid=39&username=Daniel. It is not difficult to see that the value of the username parameter in the address is the current username, so let's try changing it... Open the page http://127.0.0.1/?userid=39&username=Kitty, the information we filled in when registering a Kitty user is displayed on the Bingo! The webpage shows the information we filled in when registering a Kitty user! Change it casually... Here we can modify its password to prompt questions and answers, and then modify the user's password through the "Forgot Password" function. Let’s look at the vulnerability of displaying and modifying any user files. After detection, the page responsible for displaying the file list is http://127.0.0.1/?userid=39&username=Daniel&path=Daniel. We can browse, upload, delete, change the name of the files on the server by modifying the path value.
Example 2-3: Vulnerability in LB5000 modifying registration statement
Due to the overriding vulnerability of Lei Ao’s LB5000 and the two files, the attacker can directly modify the forum’s “Registration Statement” and “Short Message Welcome Information”. You can modify the "Registration Statement" by submitting the following request: / cgi-bin/?action=process&therules=The content to be modified. We can write some cross-site code through this.
3. Cookies cheating
What are cookies? Cookies are text files stored in the browser directory that record information you access to a specific site and can only be read back by the site where the cookies were created. They consist of about 255 characters and only occupy 4KB of hard disk space. When a user is browsing a site, it is stored in the client's memory. After exiting the browser, it is stored in the user's hard disk. Most of the information stored in cookies is ordinary, such as when you browse a site, this file records each keystroke information and the address of the visited site. However, many Web sites use cookies to store private data, such as registration passwords, usernames, credit card numbers, etc.
Cookies spoofing is to modify the cookies to be read by the client to the value we want to disguise on the client to deceive the program, making it mistakenly believe that we are logged in users to achieve a certain purpose. It can be said that this is also a way to override the authority.
We still say that some programmers lack risk estimates and trust clients too much. Storing sensitive information that should be stored in session in cookies causes this vulnerability, so this vulnerability is relatively hidden.
The general idea of conducting this kind of attack is to obtain legal cookies->using tools to modify cookies->access restriction page, which is successful in overdoing rights.
Suppose we have a legal account on the site, and now we want to log in with the user Kitty, but we don't have Kitty's password (nonsense, otherwise what else will attack...). Let's try to use cookies to spoof the purpose:
Log in as Daniel and choose to save login information, close the browser, use the IECookiesView software to open the cookies information of the machine, select the site, modify the username value to Kitty, visit the website again, and find that we have logged in as Kitty.
However, this kind of attack also has a relatively big flaw. Not to mention whether the website saves information in cookies, some websites save usernames and passwords in cookies. Each time they visit, they first check based on the username and password, and then determine whether it is legal. Therefore, this vulnerability is not very effective when used alone, but it is much easier to use with other intrusions. For example, when a certain site's database is downloaded, the passwords in it are all MD5 encrypted. Unless the MD5 hash value is brute-forced, it is impossible to log in on the website. However, if the website saves the username and password after MD5 in cookies, we can apply it. Or the website's SI prevention measures are relatively strict, and the injection point cannot be found in the url, so you can find the injection point in the cookies, etc. Some websites save users' permissions in cookies, and can also achieve the purpose of escalating permissions through modification.
Example 3-1 Deception vulnerability of a downloader:
The code for processing login is as follows:
<%If Cookies(\\"down_Isadder\\")=\\"\\" then%>
<script language=\\"Vbscript\\">
msgbox(\\"Sorry, you do not have permission to manage users! If you are an administrator, please log in!\\")
()
</script>
<%Else%>
…………
It's so dizzy. It only checks whether the cookies are empty, so we use IECookiesView to change the value of down_Isadder to any value (of course, except for the null value) to log in to management.
Example 3-2: L-blog's cookie overriding upload fraud vulnerability:
This recent vulnerability has really destroyed WebLog, including many hackers. There is a logical vulnerability in L-Blog's extracted cookies file that allows any user to upload files across the administrator's permissions.
Part of the code of the file:
IF memStatus="SupAdmin" OR memStatus="Admin" Then
IF ("action")="upload" Then
It can be seen that the program detects whether the value of SupAdmin is the corresponding value to the administrator. If so, uploading is allowed, and not detecting who the logged in user is. Let’s look at the program that verifies cookies and check that if memName (the user name obtained in cookies) is empty, no operation will be performed. If not empty, verify that the saved username and password are correct and cookies are not cleared correctly. This leaves us a vulnerability. If the username value (memName) in cookies is empty and the user permission (memStatus) is not empty, the file will not verify the username and password. However, if the upload page detects that memStatus is an administrator, it can be uploaded.
We can first register an ordinary user, log in and save cookies, modify cookies to make the value of memName empty, the value of memStatus is SupAdmin or Admin, and then you can upload it.
However, we can only upload certain types of files. We cannot upload Asp *s. What should we do... Let's take a look at how to upload Asp *s.
4. Illegal upload loophole
To be legal and illegal, let’s first talk about two simple vulnerabilities that are not considered vulnerable.
Some programs restrict extensions such as asp, asa, etc. cannot be uploaded, but we look at the settings of IIS and found that some extensions are explained by cer. So if some programs do not allow uploading asp files, we can change the extension of the * to cer and then upload. At this time, if the server does not remove the resolution of cer, we can run the *. There are also some files with extensions that can execute SSI (Server Side Include) instructions, such as stm, upload a file with the content of " <!--#include file=""-->", and then access this file to see the content of the file. Therefore, when programmers perform upload detection, they should set what kind of files are allowed to be uploaded instead of what kind of files cannot be uploaded.
Let’s talk about the vulnerability in the upload program.
The upload loophole of the Dynamic Network forum that appeared a while ago has been storms. Daniel also used this loophole to attack many stubborn broilers. Let’s analyze the upload of Dynamic Network first:
Dongwang originally did not allow uploading dangerous files such as asp, but the uploading process has certain loopholes that cause the parameters obtained by the program to be incorrect, allowing the intruder to upload any file.
First look at a page submitted and uploaded reg_upload.asp:
<form name=\\"form\\" method=\\"post\\" action=\\"\\" enctype=\\"multipart/form-data\\" >
<input type=\\"hidden\\" name=\\"filepath\\" value=\\"uploadFace\\">
<input type=\\"hidden\\" name=\\"act\\" value=\\"upload\\">
<input type=\\"file\\" name=\\"file1\\">
<input type=\\"hidden\\" name=\\"fname\\">
<input type=\\"submit\\" name=\\"Submit\\" value=\\"Upload\\" onclick=\\"=,[0].=true,
[0].=true;\\">
</form>
The program extracts the values in the file1 form and the fname form to make judgments. In other words, the program will detect the asp file to be uploaded directly from the page. However, we can construct the data packets ourselves and submit them using NC to achieve the purpose of cross-detection. But our main problem is that the uploaded file must be in asp format. Although the value of file1 is legal, what should we do if the purpose of saving the extension is asp?
There is a sentence in the componentless upload class used by Dynamic Network that is written like this:
filename=formPath&year(now)&month(now)&day(now)&hour(now)&minute(now)&second(now)&ranNum&\\".\\"&fileExt
This filename is the file name of the saved file generated by the program. The key to detecting a string in a computer is to see if it encounters a '' character. If so, it is considered that the string is over. That is to say, when we construct the path to upload the file, we just need to deceive the computer and make it think that path parameters like "" have ended, and we can achieve our goal.
This is the analysis of the principle of this vulnerability. Many uploads now have this vulnerability. It is too tiring to catch the packet first and then submit it manually. Daniel recommends that you use some upload vulnerability exploit tools online to reduce the burden.
Let’s take a look at a loophole in My Power 3.51. Part of the code of its upload page Upfile_Soft.asp is as follows:
Fot i=0 to ubound(arrUpFileType)
If fileEXT=trim(arrUpFileType(i)) then
Enableupload=true
Because the upload class used by My Power can upload multiple files, we can see from the above code that if the extension of the N-1th file is illegal when uploading multiple files, and the extension of the Nth file is legal, it can pass the detection. So we just need to construct the page ourselves, upload two files, and the second extension can be uploaded by the program, that's fine. However, the My power system prohibits external submission of forms. How to bypass this restriction? Please see - the offense and defense of forms.
Tips:
1. Use the database backup and recovery function to turn legal and illegal.
After all, there are still many systems that do not have upload logic vulnerabilities, so how do we upload script *s? This trick requires you to log in to the background and the website system has the functions of backing up and restoring the database. Now, the * horse is renamed to a legal extension through legal channels, and then the uploaded file name is written in the backup and recovery path on the page of backup and recovery, and then restore it. Since the program stores the database with the asp extension, the * horse can also be parsed normally.
5. The offense and defense of the form
Some of the unsafe factors about forms in the program have been mentioned in some places in the previous article. Let’s summarize it now. For form attacks, the main idea is to save the page containing the form locally, modify and remove relevant restrictions, and complete the action submission address to the address on the website, and then submit it.
So it is not difficult to see that everything about the form is dangerous and untrustworthy if it is not verified again on the server side. It is recommended that programmers try to verify again on the server side while doing form legality checks on the client side and add corresponding code prohibited from external submission on the server side. :
<%server_v1=Cstr((\\"HTTP_REFERER\\"))
server_v2=Cstr((\\"SERVER_NAME\\"))
if mid(server_v1,8,len(server_v2))<>server_v2 then
\\"<br><br><center><table border=1 cellpadding=20 bordercolor=black bgcolor=#EEEEEE width=450>\\"
\\"<tr><td style='font:9pt Verdana'>\\"
\\"The path you submitted is incorrect. Please do not mess with this parameter if you are prohibited from submitting data from outside the site!\\"
\\"</td></tr></table></center>\\"
end if%>
Let's think about the limitations of forms: Js legality check, hidden domain, and non-modified domain.
I don’t know if you still remember the forum group of the ofstar forum. It uses a readonly domain to display members of a certain group. We can download the web page, remove the readonly attribute, and then add the members you want to join this forum yourself, and then submit...
Tips:
1. Bypass the prohibition of external submissions:
You can write a socket program yourself to modify the value of http_referer, but this method is more troublesome, so I will introduce a simple one.
This trick requires you to upload images. When IE opens an image, if the image contains html code, it can run its code just like a web page. In this way, we can change the constructed page to an image, upload it, access this page and submit it on the server side. (Note: When constructing the page, you must write all basic tags such as <html>.)
Example 5-1: Vulnerability to upload to any directory in Jiuku Network’s personal homepage space management system 3.0:
After logging in, click the "Upload File" button and a web page pops up. There is a text box for uploading, and there is also a text box for uploading the directory, but it cannot be modified. Save this page in IE, and then find the 44th line of the file. The code is: <LI>Upload to: <INPUT class=INPUT style="WIDTH: 200px" ReadOnly…We delete this ReadOnly, then find the 37th line of the file, complete the value in the action attribute of the form tag (that is, add the website address), and then open the page locally. At this time, the "Upload" text box can be modified. We change it to:../, select file upload, and you can find that this file has been uploaded to the previous directory.
6. Vulnerabilities in the content of brute library and brute file
Everyone has heard of the %5c riot vulnerability. It is to change the address bar closest to the file name to "%5c" for the page that operates the database. If the following conditions are met, you can see the path of the database: the general error return page is provided by local IE, so we must first turn off the local error page. Specifically, in the menu item 'Tools->Internet Options->Advanced->Show friendly information'; if the other party's database is Access-type; the %5c riot requires a secondary directory, and the first-level directory cannot succeed; the other party's page has no fault-tolerant statements. The principle is quite complicated, please Google it yourself.
Some programmers like to write the page extension of include as inc, and many tutorials also suggest this, but this makes the program have a big vulnerability. Since inc is not parsed by default, it is displayed directly in text, so if others can directly access the page defined by your database (such as) and know the database address or SQL account password.
In order to prevent software downloads, some websites use a page to read the software and then send it to the client in the form of output stream. The file name parameters are usually attached to the address in GET. For example, /?path=, we can first guess the location of the data link file relative to the software library and change the value of the path parameter. If you are lucky, you can download the unresolved data link file.
Part III Summary and Postscript
It was early morning, the sun rose, and the sun shone on the earth. This article I spent about 3 days of spare time basically ended here, but I want to emphasize that non-SI loopholes in the website program are far more than this, and many unknown logical loopholes have not been discovered. Due to the limitations of space and time, this topic only briefly introduces some of the most commonly used methods at present. I hope Daniel can play a role in attracting everyone. If you really study the code of some programs on the Internet carefully, you can find that many loopholes that have not been discovered by others have appeared.
The loophole is not terrible, what is terrible is that programmers do not have a rigorous attitude and a complete and comprehensive thinking.
The old editor Tudou once asked me how I thought of this topic. In fact, I just feel deeply regretful and worried about the behavior of novices (including myself) who only know how to use NBSI to randomly bet on websites. Hackers who only know how to use tools are not hackers. We must learn to use our own ideas to discover vulnerabilities and patch vulnerabilities in order to achieve real technical improvements.