In general, the risk of storage type of XSS is higher than reflective XSS because the storage type of XSS is saved on the server, which may exist across pages. It does not change the page URL of the original structure, which sometimes can escape some intrusion detection systems. For example, XSS Filter and Firefox Noscript Extension in IE8 will check whether the address of the address bar contained XSS script. The cross-page memory-type XSS may bypass these detection tools.
From the attack process, the reflective XSS generally requires an attacker to convince a user to click on a URL link containing XSS code; while in the storage-type XSS, you only need to allow the user to view a normal URL. For example, in a web page E-mail message body there is a storage-based XSS vulnerability; when the user opens a new message, XSS payload will be executed. Such a vulnerability is extremely subtle, and in the ambush in the user’s normal course of business, the risk is high.
From a risk perspective of the user interaction between the pages, it is possible to initiate the attack XSS Worm in place. According to the different pages at PageView level, you can also analyze which pages are subject to XSS attacks after the impact is even greater. For example, in Home, XSS attacks occurred, certainly better than the website partner page XSS attacks, which were much more serious.
XSS vulnerability patching encountered one of the biggest challenges—too many loopholes, so developers may be too late, or are not willing to fix them. From a business risk perspective to reposition each of the XSS vulnerabilities, it has an important significance.