Analysis and utilization of 21 storage type XSS in DVWA system

A storage-type cross-site can write XSS statements directly to the database, making it much more valuable to use than reflective cross-site.

Select the XSS stored in Dvwa, here is a page with a type of message book.

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m00/78/cf/wkiol1adoiybt8r5aabke9qxwrs573.png "height=" 138 "/>

We first look at the low-level code, which provides the $message and $name two variables for receiving the data submitted by the user in the message and name boxes, respectively. Both of these variables are filtered through the mysql_real_escape_string () function, but this only prevents SQL injection vulnerabilities.

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m01/78/d2/wkiom1adohdipykraacun_ynjsm524.png "height=" 161 "/>

As you can see, both the name and message text boxes have cross-site vulnerabilities at the low level, but because DVWA limits the length of the name box to allow only 10 characters to be entered, we enter the cross-site statement in the message box "<script >alert (' Hi ') </script> ", anyone who accesses this message page in the future can trigger a cross-site statement to implement a bullet box.

Of course, the frame is not a goal, one of the main uses of XSS is to steal cookies, which means that users ' cookies are automatically sent to hackers ' computers.

Below we prepare a Web server (IP address 192.168.80.132) with a PHP environment, where a Web page named getcookie.php is created with the following code:

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m01/78/d0/wkiol1adoi_aw-sfaadrtwz0vok349.png "height=" 135 "/>

Then enter the following XSS statement in the message box, noting that there is no line break in the middle:

<script>document.write (' ');</script>

Once submitted in Dvwa, a file named Cookie.txt is generated in the directory where the getcookie.php Web page is located, which contains the cookie that was stolen:

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m02/78/d0/wkiol1adojhcrxdvaacpmmvl9i0629.png "height=" "/>"

So how do we make use of the stolen cookie? Since this cookie is created as an administrator, some websites have a cookie that directly contains the administrator's account number and password, although the cookie does not have a password, but we can use this cookie as a fake administrator to perform certain operations.

For example, in the previous CSRF test page can change the administrator's password, we will copy the URL of this page: http://192.168.80.1/dvwa/vulnerabilities/csrf/, and then open a new browser window, Paste the URL in the past direct access, because this page only access to administrator rights, so this will automatically jump to the Dvwa login interface.

Now that we have stolen the administrator's cookie, we can bypass the authentication and go directly to the CSRF page. Of course, there are some tools that can be used to modify cookies, and many penetration tools provide similar functionality, such as Classic d. In the "Scan injection point" in the "Detection url" to enter the URL to access, and then click on the far right of the "cookie Modification" button, in the text box below to enter the stolen cookie, click the Edit button, and then click on the "Open page" button, you can directly as an administrator to access the page.

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m00/78/d2/wkiom1adohbcpd6oaaghew8xjlc095.png "height=" 335 "/>

After analyzing the medium level code, we can see that the variable $message is filtered with the Htmlspecialchars () function so that the message input box does not have an XSS vulnerability, but the name box still has a vulnerability. However, due to the length of the name box Dvwa, only allow up to 10 characters, so the XSS attack here is a bit difficult, there are many online how to shorten the length of the XSS statement data, but I did not find the appropriate attack method, this problem can only be shelved temporarily.

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m01/78/d2/wkiom1adohuqhzhkaadttcn-750743.png "height=" 206 "/>

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

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m02/78/d2/wkiom1adohyj6ix4aadzuek4mhi254.png "height="/>

This article from "a pot of turbid wine" blog, reproduced please contact the author!

Analysis and utilization of 21 storage type XSS in DVWA system