This is the 29th day of my participation in Gwen Challenge
What is XSS?
Chinese name Cross Site scripting attack, English full name Cross Site Script, the original abbreviation is CSS, but in order to distinguish with cascading style CSS, so changed to XSS. An XSS attack, usually an attack in which a hacker tampers with a web page through “HTML injection “and inserts arbitrary scripts to gain control of a user’s browser while they browse the page. In the beginning, the demonstration case of this attack was cross-domain, so it was called “cross-site scripting”, but due to the power of JS and the complexity of web applications, cross-domain is no longer important, but the name XSS has been retained for historical reasons.
XSS has long been ranked as the number one enemy in client-side Web security. Because XSS is so destructive and creates so many complex scenarios, it’s hard to solve all at once. Here’s an example of what XSS is.
Suppose a page outputs user input parameters directly to the page. Normally, get requests and user-submitted data are displayed on the link, but if the submitted HTML code (xxx.php? Params =), and the server does not do any processing to return the parameter, you will find that the current page is executed, you will see the source code sparams already in the HTML code, this is definitely not the developers want to see, the above is the first type of XSS, reflective XSS.
XSS can be divided into different types based on effects:
1. Reflective XSS
This simply reflects the user’s input back to the browser. This means that hackers often need to induce users to click on a link in order to succeed, also known as non-persistent XSS.
2. Storage XSS Storage SXX “stores” the data entered by the user on the server. This XSS is very stable. A common scenario is that a hacker writes a blog post containing malicious JS code. After the post is published, all users who visit the blog post will execute the malicious JS code in their browsers. The hacker saves the malicious script to the server, so this KIND of XSS attack is called stored XSS. Also known as persistent XSS.
In fact, this type of DOM Based XSS is not classified according to whether the data has a server or not. This type of DOM Based XSS is also reflective in effect. It is classified because it was formed for a special reason and was specifically proposed by the security expert who discovered it. XSS is formed by modifying the DOM node of the page, so it is called DOM Based XSS.
XSS Payload
After an XSS attack succeeds, an attacker can implant malicious scripts on a user’s page and control the user’s browser. These malicious scripts are called XSS Payload. It’s actually a JS script, so anything that a JS script can do, XSS Payload can do. One of the most common types of XSS payload is a Cookie hijacking attack that reads a browser’s Cookie object. Cookies generally encrypt and save the login credentials of the current user. If the Cookie is modified, it often means that the user’s login credentials are lost. In other words, an attacker can log directly into a user’s account without using a password.
Cookies are generally the user’s login credentials, but all requests initiated by the browser will automatically bring cookies. If cookies are not bound to client information, when the attacker steals the cookies, he can log in to the user’s account without password. The HttpOnly identity of cookies prevents “cookiejacking”. Cookie hijacking does not work all the time. Some sites may plant HttpOnly identifiers on critical cookies during set-cookie, while others may bind cookies to client IP, rendering the cookies stolen by XSS meaningless.
For example, if we want to delete an article via XSS, what do we do?
For an attacker, only the id of the article is needed to delete the article with a request. An attacker can initiate a GET request by inserting an image. The attacker simply asks the author of the article to execute the image code and the article will be deleted. Of course, you can do something similar with a POST request.
Therefore, after XSS attack, the attacker can not only implement Cookie hijacking, but also operate the user’s browser by simulating Get and Post requests. This can be useful in some isolated environments, such as when Cookie hijacking fails, or when the target user’s network cannot access the Internet.
XSS fishing
XSS is not a panacea. Everything I’ve talked about is done through JS scripts, without user interaction. For example, there is a function for users to change their passwords, so they need to change their old passwords. Is that enough to limit XSS attacks? The XSS Payload can be used to read the page content and send the image URL of the verification code to a remote server. An attacker can bypass the verification code by receiving the current verification code in the remote XSS background and returning the value of the verification code to the current XSS Payload. Changing passwords is a little more complicated. To steal passwords, an attacker can combine XSS with “phishing.”
The implementation idea is very simple: use JS to make a forged login box on the current page. When the user enters the user name and password in the login box, the password will be sent to the hacker server.
Construction tips for XSS
- Use character encoding, such as our common user name, password character verification;
- Bypassing length restrictions, such as password length;
- Use the hosting tag, which defines the hosting address of all the “relative path” tags used on the page;
- Window. name, which is a strange object, is assigned to the window.name object of the current window without any special character restrictions. Because the Window object is a browser form, not a Document object, it is often not shown by the same origin policy and can be used by attackers to pass data across domains and pages.
XSS defenses
1. HttpOnly
Httponly was first proposed by Microsoft and implemented in Internet Explorer 6. It has become a standard that the browser will prohibit the page JS from accessing cookies with the HttpOnly attribute. However, it is not a panacea. Adding HttpOnly does not solve the XSS problem. XSS attacks not only bring Cookie hijacking problems, but also steal user information, simulate user identity to perform operations and many other serious consequences. The attacker uses Ajax to construct HTTP requests and performs operations with the user’s identity without knowing the user’s cookies. There are subject XSS attacks using Httponly, but other solutions are still needed to address XSS vulnerabilities.
Input check input check logic, must be in the server-side code to achieve, if only in the client using JS input check, is easy to be bypassed by the attacker. The js input check of the client can prevent most normal users from misoperating, thus saving server resources.
3. Output checking In general, in addition to rich text output, you can use encoding or escaping to prevent XSS attacks when variables are output to HTML pages. Use whitelists instead of blacklists when dealing with rich text. For example, only allow safe tags such as A, IMG,div, etc. When dealing with CSS, you should forbid user-defined CSS and style as much as possible.
conclusion
In general, the risk of storage XSS is greater than that of reflection XSS. Because storage XSS is stored on the server, it is possible to exist across and across. It does not change the original structure of the page URL, so it can sometimes escape detection by SOME IDS.
In terms of the attack process, reflective XSS generally requires the attacker to induce the user to click on the URL link containing an XSS code. With non-storage XSS, you only need to show the user a normal URL.
From the perspective of risk, users’ own interactive pages are likely to launch XSS worm attacks. According to the height of pageView of different pages, it can also be analyzed that those pages will be more affected by XSS attacks.
Gentlemen, you’re making a fool of yourself again!!