Analysis of XSS cross-site scripting attacks

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. The Cross-Site vulnerability exploitation mentioned here mainly includes cross-site scripting attacks and Cross-Site Request Forgery and other same-origin attacks. These attacks are currently very common attacks, same-origin attacks mainly involve several attack methods: cross-site scripting attacks, Cross-Site Request Forgery, cross-site request tracking, website cache poisoning, HTTP Response Splitting, HTTP Request Smuggling, HTML and JavaScript web scanning. XSS is a security vulnerability that allows malicious code to be injected into webpages. This type of attack is mainly used for A, phishing, or cookie Stealing to access restricted information. B. Attacks to spoof, target other websites, or conduct social engineering attacks C. Attacks that execute malicious code on the client of the website can be carried out by using the IMG mark, for example, close the user's browser window, open a window with neither menus nor toolbar, and play some spoof sounds.1. Attack principles and typesSo how is this attack carried out? In general, it is divided into two types: one is a reflection-type attack, which tracks the identity authentication of a website through cookies. Such websites are generally not safe and vulnerable to cross-site scripting attacks. Use social engineering (for example, tell the user "you have won the prize !"), If the target user is spoofed and the attacker clicks a link that injects malicious code into the standard HTML code, the attacker can access the user's cookie information (Session and authentication information ). The second is storage-type attacks. The principle is: if a website uses a backend database as the source of information for searching web pages, hackers do not inject malicious code into normal pages, instead, it injects SQL code into such a database. Therefore, every time a query result is returned from a backend database, the malicious code of the attacker is contained. It can be imagined that this attack is not targeted at any client, but infected with the user group of the entire forum and infected with a large number of easy-to-trust victims. 2. The most important thing to prevent is to protect the code. You should restrict the display of user input information, implement filtering, and only display absolutely required information. We recommend that you verify and clear all forms of data, data sources, and URL parameters that you cannot directly control. A practical technique is to use HTML entities (such as &) to replace special characters. To reduce the number of specific HTML characters, you must restrict user input and only allow valid code segments for the website. For example, many forums use the {B} mark to enable users to input uppercase characters. However, in typical cases, these sites do not allow you to add your own forms, so you should not allow the form. In addition, if these tags have specific syntaxes and values, you should only allow values that are consistent with their syntax (for example, the font color is a value that contains only three or six characters of the letter A-F or number 0-9, so if you allow the user to enter the entire SQL statement, that's worse .) In addition, most cleanup routines use tags to replace carriage returns and line breaks, and some harmful words, such as "scripts", which depend on specific applications, however, many websites have reasons to use this word, so these measures are difficult to popularize. Below are several unsafe examples: the Python example: print "" ASP example: writing this text directly to HTML will result in: here you can see that the HTML is legal, so it will be processed: The following is a few safe examples: Python: print cgi. escape ("") ASP:Cross-Site Request ForgeryCross-Site Request Forgery is another same-origin policy attack, which aims to trick victims into loading a webpage containing malicious requests and require users to enter their accounts and passwords. This spoofing relies on users' trust in their identity information. Users generally think that they are only executing different tasks, but only using an HTTP request. Attackers use the user's browser to send attacks to the target site. 1. Principles of Cross-Site Request Forgery: first, attackers can publish links to malicious websites to target websites. Then, some trust users can browse malicious websites to become victims, what's more, it will become an accomplice. When a user is tricked into submitting a form to the original target website (a website with a malicious link implanted initially), the user will become an accomplice of the attacker. Because the user has passed the authentication, the target website will accept the form submission request and allow the user to modify sensitive data, such as the user's own password or obtain key information from the website. 2. Protection Code first, you must check the REQUEST link REQUEST to restrict access to POST or Web applications. Note: Some browsers have an empty link request, which should also be blocked. Therefore, mutual authentication is generally a token-based authentication request. That is, if a data packet contains an appropriate confidential value, the data can be pasted. This security mechanism is also enhanced by implementing the write process or validation page in multiple steps.SummaryThe same-origin policy is a concept implemented in most browsers, but it can be exploited by XSS attacks (it exploits a user's trust in a website or application ), XSRF can also be used (It exploits the trust of websites or applications on users ). In short, our strategy is: Never trust anyone! Think of trust as a two-way street: You will never know which direction there will be traffic. Anyone can dive into the trust relationship and abuse this trust relationship.