XSS (Cross-Site-Scripting) Notes

Cross-Site-Scripting is also called a Cross-Site Scripting attack, which is usually abbreviated as XSS.
Or here to add knowledge: http://en.wikipedia.org/wiki/Cross-site_scripting
Due to work needs, we have recently studied some common attack methods and vulnerabilities to prevent and fix them. if you have not heard of this, you may need to read the following content to help you quickly enter the status.
XSS can be divided into three types: Reflected, Persistent, DOM, and so on. It is usually harmful, and there are many potential ways to use XSS in Web applications. Here are some of the descriptions and explanations from the internet. I hope you can read and think patiently, and it is better to start your work.
1. Cross-Site Scripting: Reflected
Abstract:
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation:
Cross-site scripting (XSS) vulnerabilities occur when:
1. data enters a web application through an untrusted source. in the case of Reflected XSS, the untrusted source is typically a web request, while in the case of Persisted (also known as Stored) XSS it is typically a database or other back-end datastore.
2. the data is wrongly ded 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 Deming other malicous operations on the user's machine under the guise of the vulnerable site.
Sample Code:
<% String id = request. getParameter ("id"); %>
<% = Id %>
Reflected XSS:
Hackers or malicious attackers can send URLs containing malicious scripts to connect to emails. Use social engineering to convince victims of these links and click. The script runs in the victim's browser and performs malicious actions. It may jump to the Trojan-mounted website, steal your important cookie information, and silently send it to the server specified by the attacker, possibly destroying the victim's computer ......
2. Cross-Site Scripting: Persistent
Abstract:
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation:
Cross-site scripting (XSS) vulnerabilities occur when:
1. data enters a web application through an untrusted source. in the case of Persistent (also known as Stored) XSS, the untrusted source is typically a database or other back-end datastore, while in the case of Reflected XSS it is typically a web request.

2. the data is wrongly ded 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 Deming other malicous operations on the user's machine under the guise of the vulnerable site.
Sample Code:
<%
While (rs. next ()){
String str = rs. getString ("content ");
%>
<% = Str %>
<% }%>
Persistent XSS:
Malicious scripts are submitted to the server database of the victim mode. When the victim accesses the data in the database and displays the data in the browser, the contents (malicious scripts) are extracted from the database) it is parsed as a script by the browser and executed on the victim's computer. The script runs in the victim's browser and performs malicious actions. It may jump to the Trojan-mounted website, steal your important cookie information, and silently send it to the server specified by the attacker, possibly destroying the victim's computer ......
3. Cross-Site Scripting: DOM
Abstract:
Sending unvalidated data to a web browseer can result in the browser executing malicious code.
Explanation:
Cross-site scripting (XSS) vulnerabilities occur when:
1. data enters a web application through an untrusted source. in the case of DOM-based XSS, data is read from a URL parameter or other value within the browser and written back into the page with client-side code. in the case of Reflected XSS, the untrusted source is typically a web request, while in the case of Persisted (also known as Stored) XSS it is typically a database or other back-end datastore.
2. The data is stored in dynamic content that is sent to a web user without being validated for malicious code. In the case
DOM Based XSS, malicious code gets executed as part of DOM (Document Object Model) creation, whenever the victim's browser parses the HTML page. 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 Deming other malicous operations on the user's machine under the guise of the vulnerable site.
Sample Code:
<SCRIPT>
Var pos = document. URL. indexOf ("eid =") + 4;
Document. write (document. URL. substring (pos, document. URL. length ));
</SCRIPT>
Dom xss:
The DOM object is directly used in the server code to dynamically write the content obtained from the request to the page. However, if the request parameter is a script maliciously constructed by an attacker, the malicious script will be parsed into a script by the browser and executed. The script runs in the victim's browser and performs malicious actions. It may jump to the Trojan-mounted website, steal your important cookie information, and silently send it to the server specified by the attacker, possibly destroying the victim's computer ......
Common XSS solutions:
1. Contextual output encoding/escaping of string input, Safely validating untrusted HTML input:
Verify, translate, or recode the input and output content. (In addition, the labels of Struts 1.x and Struts 2 both encoding and escaping for input and output, so Struts is a good choice ).
2. Disabling scripts: Disable JavaScript in the browser (by modifying browser settings, but it is not a good way to disable javascript)
3. Cookie security: bind the cookie of the logon session to the specified ip address.
4. Miscellaneous
XSS recommendation links:
Knowledge1 https://www.owasp.org/index.php/XSS
Knowledge2: http://en.wikipedia.org/wiki/Cross-site_scripting#Contextual_output_encoding.2Fescaping_of_string_input
Knowledge3: http://www.iseclab.org/papers/xss_prevention.pdf
Solution1: Decode the input or output string (use tld Tag Library Descriptor) or Add a filter
Http://www.ibm.com/developerworks/tivoli/library/s-csscript/
Solution2: http://today.java.net/article/2005/09/19/handling-java-web-application-input-part-2
Character entity references in HTML
Http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML
Struts Tag Explain1:
1. Bean tag
Http://struts.apache.org/1.x/struts-taglib/tlddoc/bean/tld-summary.html
Http://struts.apache.org/1.x/struts-taglib/tlddoc/bean/parameter.html
If no request parameter with the specified name can be located, and no default value is specified, a request time exception will be thrown.
2. Logic tag
Http://struts.apache.org/1.x/struts-taglib/tlddoc/logic/tld-summary.html
Http://struts.apache.org/1.x/struts-taglib/tlddoc/logic/present.html
But considering the network limitation, we can also download the tld files and put them into our project. so that the struts tag can work
If you have any questions, please forgive me. If you have other perspectives and ideas, please contact us. ^_^
--- EOF --


From Michael's Blog