Shulou(Shulou.com)06/01 Report--

Storage cross-site can write XSS statements directly to the database, so it is more valuable than reflective cross-station.

Select XSS stored in DVWA, where a page of type guestbook is provided.

Let's first look at the low-level code, where two variables, $message and $name, are provided to receive the data submitted by the user in the Message and Name boxes, respectively. Both variables are filtered through the mysql_real_escape_string () function, but this only prevents SQL injection vulnerabilities.

It can be seen that at the low level, both Name and Message text boxes have cross-site vulnerabilities, but as DVWA limits the length of the name box, only 10 characters are allowed to be entered, so here we enter the cross-site statement "alert ('hi')" in the Message box, as long as anyone visits this message page, it can trigger a cross-site statement to achieve a pop-up box.

Of course, the pop-up box is not the purpose, one of the main uses of XSS is to steal cookie, that is, to automatically send the user's cookie to the computer.

Let's prepare a Web server with PHP environment installed (IP address 192.168.80.132), and create a web page called getcookie.php with the following code:

Then enter the following XSS statement in the Message box, and notice that there is no line break in the middle:

[xss_clean] ('

')

Once submitted in DVWA, a file called cookie.txt is generated in the same directory as the getcookie.php page, which contains the stolen cookie:

So what do we do with the stolen cookie? Since this cookie is created as an administrator, the cookie of some websites will directly contain the administrator's account and password. Although the cookie here does not have a password, we can use this cookie to impersonate the administrator to perform some operations.

For example, in the previous CSRF test page, you can change the administrator's password. We copy the URL of this page: http://192.168.80.1/dvwa/vulnerabilities/csrf/, and then open a new browser window and paste the URL to access it directly. Because only the administrator can access this page, it will automatically jump to the login interface of DVWA.

Now that we have stolen the administrator's cookie, we can bypass authentication and go directly to the CSRF page. Of course, you need to use some tools that can modify cookie, and many * tools provide similar features, such as the classic D. Enter the URL you want to visit in the "scan injection point" of the "Detection URL", then click the "cookies modify" button on the far right, enter the stolen cookie in the text box below, click the modify button, and then click the "Open Web Page" button, then you can directly access this page as an administrator.

Looking at the medium-level code again, you can see that the variable $message is filtered with the htmlspecialchars () function, so that there are no XSS vulnerabilities in the Message input box, but there are still vulnerabilities in the Name box. However, because DVWA limits the length of the Name box to a maximum of 10 characters, the XSS*** here is somewhat difficult. There is a lot of information on how to shorten the length of the XSS sentence on the Internet, but I have not found a suitable * method, so this problem can only be shelved for the time being.

At the high level, there is no doubt that both $message and $name are filtered so that cross-site vulnerabilities are completely blocked.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.