Today, I am sorting out some js files and added markdown support to the People's Network in May. However, the freedom of UGC means we need to take some measures to maintain it, such as anti-XSS attacks. I wrote an email in early September. The background at that time was that the markdown support was available on the same day, and it seemed that it was not right at night. As a result, XSS attacks began to be studied after. One difficulty is how to prevent XSS through external image links. My solution is briefly introduced in the original mail: There are many XSS methods, especially the image method. The viewad markdown support we released today can use img. src for external links, so you need to consider this problem. I will come back to study it later at tonight. It can be classified into the following types: src = "javascript: alert (1) "src =" jav ascript: alert (2) "src =" java & # x0script: alert (3) "src =" & #000 ....... "Src =" variant above 4 "src =" external execution script link "www.2cto. comGoogle has been around for a long time and has no ready-made tools. It is a waste of resources for 6th solutions. http://ha.ckers.org/xss.html According to the above summary, the analysis results show that the above types are supported for xss type detection in Markdown parser. Thanks to the Summary of ha. ckers, this function can be easily written: function imageXSS ($ img) {return preg_match ('/(?: Javascript | jav \ s + ASV |\&# \ d + |\& # x)/I ', $ img) ;}remove 6th XSS methods, judging external resources is the most troublesome. Google's conclusion: in general, we can use get_headers and stream_get_meta_data to obtain the content-Type. We need our server to request the content and analyze the source, which is determined by the content-Type, in this case, there will be some problems: the backend rendered data must be retrieved by the header, that is, after the image is loaded (there may be multiple and may be very large ), rendering is very slow and every image request is not cached. This wastes server resources. Even for a PX image on the flickr, it takes 49 ms to load it on my 20 M network. An accident may cause the server to crash (if there are more images and more visitors, this will not cache the image url ). After a long time, I finally thought of the preload image method. According to the test, only the loaded content in the browser is the real image, which triggers the onload event of the image, in fact, we can use onload to solve this problem. In this way, we can distribute requests to every user without any resources. In addition, this method also performs parallel loading, which even improves the viewad speed. The following steps are required: by default, the src of img is not loaded, but the data-xssimg = "image address" is set to detect the onload event of the image. If onload is not triggered, it is not displayed, however, when src is empty, Some browsers may affect the rendering speed of the website. Therefore, when an error is triggered, a permanently cached image is referenced: http://static.baixing.net/images/nopic_small.png . The code looks as follows (it has already become a jQuery component). Currently, this code has been put on github. You can view it here: imagesXSS. js :~ Function ($) {$. fn. imageXSS = function () {this. each (function () {var that = $ (this), url = that. data ('mdimg '), img = document. createElement ('img '); $ (img ). on ('load', function () {that. attr ('src', url) ;}) $ (img ). on ('error', function () {that. attr ('src ',' http://static.baixing.net/images/nopic_small.png ');}) Img. src = url ;}}$ ('[data-mdimg]'). imageXSS () ;}( jQuery); currently, you can only think of this point. Basically, all tests are normal. This version is currently supported online. Submit another version on Monday.