Simple exploration of Xss

Simple exploration of Xss
In the previous content, I introduced some basic XSS cross-site scripting concepts. I believe that you have some knowledge of cross-site scripting. Next, we will describe how to discover some simple XSS vulnerabilities.
The example below may be relatively simple. To learn more about exploring and testing XSS technologies, please follow the official APTSec blog.
Build a test environment
Before exploring xss, you must first build a local Web server. For simplicity, you can use AspServer.
AspServer is a green ASP server that can be used to conveniently develop and debug ASP programs. Its download and installation process is relatively simple and will not be described here.
After the environment configuration is complete, you also need to download a set of Web programs for testing. Here we take the "ok3w news publishing system" as an example. After the program is downloaded, compress the related program files to the root directory of the website, start AspServer, and then open http: // localhost or http: // 127.0.0.1 in the browser to access the site, 1.
Now, we will start to explore and test the XSS vulnerability in the *** news publishing system. There are several security testing methods. Here we use the gray-box testing. What is a gray-box test? To understand this concept, you must first understand the black box test and white box test, that is, to know the internal structure of the program, that is, to test the software when the source code is obtained; the black box is the opposite; the gray-box test is between the two.

Discover reflective XSS

As we all know, cross-site scripting is the easiest place for data interaction (that is, input/output). Therefore, we can focus on testing the input box and URL parameters of the website. Of course, all content from cookies, POST forms, and HTTP headers may generate XSS.

Go to the *** news publishing system page and you can see the "intra-Site Search" function in the upper-right corner, as shown in figure 2. Enter XSS <XSS> 'in the search box, and click Submit. Observe the returned results on the page, as shown in 3.

"XSS'' "search result>

As shown in figure 3, <XSS> In the entered XSS test code is not displayed. In this case, the test code may have been filtered out by the program, it is also possible that the program accepts but does not display it, because in the HTML language, <> indicates the HTML tag, which is not directly displayed by the browser and can only be seen by viewing the corresponding source file. Therefore, we need to view the source file of the page and search for the keyword XSS. Then we will find the code snippet 4:

As you can see, the entered <XSS> is indeed completely written into the page, which proves that the *** news publishing system does not filter <> and other key characters. Then we can directly inject a complete <scept> label to generate an XSS.

Return to the search box, enter the complete XSS Code <script> alert (/xss/) </script>, and click search, then, an XSS dialog box is displayed on the browser interface, as shown in Figure 5.

Careful readers may have discovered that the link in the browser's address bar has changed:

Http: // 192.168.1.100/search. asp? Keyword = % 3 Cscript % 3 Ealert % 28% 2 Fxss % 2F % 29% 3C % 2 Fscript % 3E & Submit = % CB % D1 % CB % F7

 

Therefore, we can confirm that the news publishing system has a reflected XSS.

After the black box technology is used to discover the cross-site scripting vulnerability, we also need to use the white box technology to analyze the cause of the vulnerability. Find the relevant program file search. asp and find the following code:

<% Set Page = New TurnPagekeyword = inclusafelikesqlstr (Request. QueryString ("keyword") If keyword = "ThenCall MessageBox (" enter the keyword to be queried .","") End If %>

In the above Code, the keyword variable represents the input query content, and then the program uses Request. QueryString () to directly obtain the variable, and then it is only processed by the javassafelikesqlstr () function. CmdSafeLikeSqlStr () has a definition in APPCode/fun/function. asp. You can find this file to understand its role:

Function CmdSafeLikeSqlStr(Str)Str = Replace(Str,”‘”,”””)Str = Replace(Str,”[“,”[[]”)Str = Replace(Str,”%”,”[%]”)Str = Replace(Str,”_”,”[_]”)CmdSafeLikeSqlStr = StrEnd Function

The function of the above Code is to replace '[% _ and other characters in the query variable with' [[] [%] [_]. Obviously, the filtering of key characters such as <> is ignored here. As a result, users can inject HTML tags to trigger XSS.

Discover persistent XSS

By analyzing the source code, we have a better understanding of the cause of the vulnerability, but before exploring XSS, black box testing is obviously better than white box testing, the combined use of these two methods of gray-box testing technology can greatly improve the efficiency of XSS mining.

 

Next, we will continue to test whether there are other cross-site vulnerabilities in the "*** news publishing system. No other information is found in the system. The page address is http: // 192.168.1.100/guest. asp. Here, users can enter messages at will. If the program does not carefully filter the messages, a persistent or stored XSS vulnerability may occur.

 

6. On the message page, enter the following content:

<Script> alert (/xss/) </script>

Figure 6 enter an XSS statement in the message content

Click Submit. Do not worry, because the message submitted by the user is usually displayed only after the background Administrator review, as is the case in the news publishing system. After submitting the XSS code, log on to the background as an administrator to view the message. The logon address of the background management is:

Http: // 192.168.1.100/admin/ad_login.asp

Open this page, enter the default Administrator account and password admin, as shown in 7, and then log on.

Figure 7 logon to the background

After logging on to the background, click the "wait for review message" link in the "message/Comment management" column. The page displays content 8.

Figure 8 view messages in the background

We can see that the XSS statement we entered was not successfully executed, but was directly displayed by the browser. In this case, it is very likely that the program escaped the XSS code and checked the source code of the current page, as shown in figure 9.

 

Figure 9 source files on the message page

After a round of analysis, it is found that the entered XSS code is not filtered, but has been successfully inserted into the webpage content, so the code is not executed, the reason is that the XSS code is embedded in the <textarea> label and then directly displayed by the browser. Therefore, when constructing XSS code, you need to close the <textarea> label and re-Modify the XSS code:

</Textarea> <script> alert (/xss/) </script> <textarea>

The two <textarea> are respectively used to close the front and back <textarea> labels. Submit this code, and then view the message as an administrator. A dialog box with XSS content is displayed, as shown in 10.

Figure 10 XSS is displayed successfully

The above is a typical persistent XSS, which is triggered only when the Administrator checks the message. This type of XSS scenario can provide a lot of space, because it attacks the background administrator, and the attacker can use this XSS to hijack the Administrator session and perform any operation, for example, modify the password, add news, backup data, etc. (attack method: Call XSS platform, Xss platform site: http://xssec.cc /!)

Finally, analyze the cause of the vulnerability and find the program file *** 3w_Guest.asp that processes the message. The related code is as follows:

'Receive form

Private Sub GetFormData () UserName = Trim (Request. form ("username") Mail = Trim (Request. form ("email") Homepage = Trim (Request. form ("homeurl") Content = Trim (Request. form ("content") QQ = Trim (Request. form ("qq") TypeID = Trim (Request. form ("TypeID") If TypeID = "Then TypeID = 1 TableID = Trim (Request. form ("TableID") If TableID = "Then TableID = 0 AddTime = Now () Ip = Request. serverVariables ("REMOTE_ADDR") IsPass = 0Ad_ask = "" End Sub "Update record set Private Sub UpdateRs (ByRef Rs) Rs (" UserName ") = UserNameRs (" Mail ") = MailRs ("Homepage") = HomepageRs ("Content") = ContentRs ("QQ") = QQRs ("TypeID") = TypeIDRs ("TableID ") = TableIDRs ("AddTime") = AddTimeRs ("Ip") = IpRs ("IsPass") = IsPassRs ("Ad_ask") = Ad_askEnd Sub

The above Code only uses Request. the Form () function is used to obtain the Form data, including the user name, email address, and message content. Then, the blank spaces on both sides are removed and the message information is directly written into the database, the program does not filter any harmful characters, resulting in the generation of a persistent XSS.

It can be seen that XSS cross-site scripting is always the most vulnerable and overlooked security vulnerability in Web applications.

Finally, let's talk about how to use xss to launch APT attacks.

Q: What Can Xss be used?

A: The use of XSS technology is flexible and changeable. It can hijack browser users' sessions, steal customer service Cookies, phishing, and other vulnerabilities in specific scenarios, more powerful!

So I will share with you one idea. Compile a JS virus script to force remote control of the victim to download and run the trojan. Finally, use XSS to run the script. (Hijack a user's browser session) after the victim's computer runs a Trojan, we can do whatever we want on his computer. So we can regard this as an APT attack method! Of course, this idea is not easy to implement. You must first consider whether the victim's browser is vulnerable to script injection. If so, how can we bypass it? This is a question worth thinking about. For writing such a script, the small Editor is not very familiar with JS scripts, and it will be very difficult to write, but the small editor will be compiled as soon as possible, add the script to the XSS module.