Website Security-XSS vulnerability attacks and Preventive Measures

In website development, security is a top priority, especially for SQL injection, XSS vulnerability attacks, etc. If it is not done well, the website will have great risks.

XSS vulnerabilities are the most common types of website vulnerabilities. At least most of today's websites exist. It is rumored that only Gmail is the only one that does not exist at all, or that attackers have not discovered the vulnerabilities, it may be because the XSS vulnerability does not seem so harmful, so it is basically not paid too much attention, as a result, so many websites have some XSS vulnerabilities that can be easily discovered, in this blog, I am a layman of website security to guard against XSS vulnerability attacks and preventive measures.

The emergence of the XSS vulnerability is simply to enable the execution of Rich Text in areas that do not support rich text. For example, the title of a blog does not support rich text, however, due to the absence of processing during page display, the title can be embedded in plain HTML like text, color change, and so on. Of course, attackers can embed malicious JavaScript, for example, you can obtain the javascript: document. cookie and so on. The other is that the area that supports rich text does not filter malicious JavaScript, such as the blogArticleAttackers can obtain malicious javascript such as cookies embedded in the content.CodeThese two types of phenomena are too many. On the contrary, the rich text area will be better, for example, UBB used in most forums. In addition, everyone will pay more attention to the rich text, however, in the non-Rich Text area, it is easy to ignore the XSS vulnerability.

The above seems to be a little too abstract. For example, the title of a blog is stored directly in the text box of the blog title when it is stored in the database, use $ blog directly when displaying. to display the title, you only need to enter <SCRIPT> alert (document. cookie); </SCRIPT>, and then save it. When it is displayed, the JavaScript code will be executed normally. Although this seemingly has no major harm, however, attackers will not take this simple method. For example, they can directly give you a URL encoded string, the XSS vulnerability of the website is used to send your cookie information to a website that records cookies of attack nature, or you can use the XSS vulnerability of the website to embed a hidden IMG to embed such a URL. Then, your cookie will be stolen without knowing it, however, most websites now use cookies to represent users' identities. In this way, when attackers obtain cookies, they can impersonate your identities. The website has been opened.

The above is a typical case of XSS vulnerabilities, and another typical case is Dom XSS. In this case, most of the attacks directly close tags, attackers can execute malicious JavaScript code. For example, if there is a text box in the page, the content of this text box will be recorded and displayed in the text frame of the result page after submission, assume that the text box in the second page is written as follows: <input type = text value = "$! Prevpage. sometext ">, enter"> <SCRIPT> alert (document. cookie); </SCRIPT> the content is displayed on the second page: <input type = text value = ""> <SCRIPT> alert (document. cookie); </SCRIPT> the attacker closes the input tag to execute malicious JavaScript code. Similarly, if your JavaScript code also reads URL parameters, content submitted on the previous page, or content in the database, attackers may exploit this closed Tag Method to launch attacks.

In this way, it seems that there may be many XSS vulnerabilities. After talking about the above, we may still feel that the XSS vulnerabilities are useless even if they are exploited. Indeed, maybe the XSS vulnerability can only be used to steal a user's cookie for play, but once it steals the cookie, it then integrates some other attack methods, such as csrf, it is very likely to cause very serious consequences. The MySpace attack in that year originated from this, not to mention the theft of user identities is not a good thing for most websites.

Therefore, it is necessary to prevent XSS vulnerabilities. Based on the reasons for the XSS vulnerability described above, for non-Rich Text areas, in fact, you only need to encode the HTML code, and for rich text areas, it is relatively troublesome. You need an effective way to filter the HTML code of the attack nature, however, it is really difficult to prevent malicious HTML code by 100% because there are too many ways to write malicious HTML code, such as URL encoding, annotation, and hexadecimal, however, most of the XSS vulnerabilities on websites are not rich texts. If you have taken precautions against these vulnerabilities, at least it can increase the threshold for website attacks to a large extent, so as not to be attacked by some simple attack means. For example, in the freemarker template, HTML encoding of variable characters can be directly supported, such as $ {user? HTML} is a simple method ,:).