This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Cross site scripting also known as XSS work when a web application gathers harmful data from a user. The cross site scripting data mostly use in web link which store a harmful information and within it. When the user click on the this type data, web link or other instant message from the other site user or just reading the display e-mail message so that cross site scripting activate on the user system. Usually the attacker will send the harmful data in Hexadecimal so the request is less suspicious looking to the user when clicked on. After this procedure the data is collected by the web application, it creates an new output page for the user this new page containing the dangerous or harmful information or data that was originally sent to it, but the attracter make the originality for the other user this a valid content from the web site. Many popular companies' guestbook and forum programs allow users to submit theirs comments with html and Java Script coding. If for example I was logged in my mail box in as "john" and read a message by "Joe" that contained harmful or dangerous information in Java Script in it, then it may be possible for "Joe" to hijack my system just by reading his message which is display in front of me.
The following rules are indeed protect all XSS in the application. While these rules do not allow absolute freedom in putting unfair data into an HTML document. Here is some rules to organize the data or protect the data from XSS. Mostly organizations may find that allowing only Rule # 1 and Rule # 2 are sufficient for their needs.
Rule # 1 Never Insert Untrusted Data Except in Allowed locations.
This rule describe that do not put untrusted data into your HTML documents. Most
Rule # 2 HTML Escape Before Inserting Untrusted Data into HTML Element Content.
This rule describe that when we put untrusted data directly into the HTML body somewhere.
This includes inside normal tags like div, p,b, td etc. Always beware the special characters in
HTML entity encoding such as script, style, or event handlers.
Rule # 3 Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes.
For putting untrusted data into typical attribute values like width, name, value. This attribute
values not used for complex attributes like href, style. Accept the alphanumeric character ,
escape all character with ASCII values less than 256 with the (&#xHH;) format to prevent
switching out of the attribute.
to put untrusted data into these event handlers as a quoted "data value". Expect for alphanumeric characters; escape all characters less than 256 with the \xHH format to prevent switching out the data value into the script context or into another attribute. Do not use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first.
RULE # 5 - CSS Escape Before Inserting Untrusted Data into HTML Style Property Values.
When we put the untrusted data in CSS file or style tag.CSS is powerful and can be used for numerous attacks. Therefore its very important that we only use untrusted data in a property value and not into other places in style data.
(Q3) What are the similar threats?
Disclosure of arbitrary data (entered ) in HTML forms
Disclosure of all test typed in an entire web application
File system reconnaissance
File content disclosure
Application reconnaissance (spidering)
Exploit pushing (GET and POST requests to any Web server)
Digital identity theft
Digital identity forcing
Hoaxes (Script code can change HTML content at runtime)
Phishing (Attackers can embed false content in a web page)
File content manipulation (File store LAN and attacker modify the content on LAN)
Server / Device reconfiguration (Port scanning detection)
Malware distribution (Attacker create a new virus file with Active X commands)