用FireFox的插件XSS Me來檢測網站代碼的XSS問題

又是pci compliance的事，改進之後，先自測。

<a href="https://www.owasp.org/index.php/cross-site_scripting_%28xss%29">https://www.owasp.org/index.php/cross-site_scripting_%28xss%29</a>

cross-site scripting (xss) attacks occur when:

data enters a web application through an untrusted source, most frequently a web request.

the data is included in dynamic content that is sent to a web user without being validated for malicious code.

the malicious content sent to the web browser often takes the form of a segment of javascript, but may also include html, flash or any other type of code that the browser may execute. the variety of attacks based on xss is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. the victim then retrieves the malicious script from the server when it requests the stored information.

reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. when a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. the browser then executes the code because it came from a "trusted" server.

xss flaws can be difficult to identify and remove from a web application. the best way to find flaws is to perform a security review of the code and search for all places where input from an http request could possibly make its way into the html output. note that a variety of different html tags can be used to transmit a malicious javascript. nessus, nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. if one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

also, it's crucial that you turn off http trace support on all webservers. an attacker can steal cookie data via javascript even when document.cookie is disabled or not supported on the client. this attack is mounted when a user posts a malicious script to a forum so when another user clicks the link, an asynchronous http trace call is triggered which collects the user's cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. this is easily mitigated by removing support for http trace on all webservers.