Cross-site Scripting instances (AppScan scan results)

Recent job requirements address the vulnerability of web-based projects, and scanning vulnerabilities are appscan tools, many of which are about cross-site scripting issues. Let's share this piece of stuff.

Original articles, reproduced please specify

------------------------------------------------------------------

Test Type:
Application-Level testing

Threat Classification :
Cross-site Scripting

Reason:
Dangerous character cleanup is not performed correctly for user input

Security risk:
Customer sessions and cookies may be stolen or manipulated, and they may be used to mimic legitimate users, allowing hackers to view or change user records as that user and perform transactions

Affected Products:
This issue may affect various types of products.

Reference:
CERT Advisory ca-2000-02
Microsoft how to:prevent cross-site Scripting Security issues (Q252985)
Microsoft how to:prevent cross-site Scripting in ASP
Microsoft how to:protect from injection Attacks in ASP
Microsoft how To:use Regular Expressions to constrain Input in ASP.
Microsoft. NET Anti-Cross Site Scripting Library
Cross-site Scripting training module

Technical Description:

AppScan detects that the application does not properly manipulate the user-controllable input, placing it in the output that acts as a Web page. This can be exploited by cross-site scripting exploits.
Cross-site scripting (XSS) vulnerability occurs in the following situations:
[1] The non-trusted data enters the Web application, usually from a Web request.
[2] The Web application dynamically generated a Web page containing this untrusted data.
[3] During page generation, applications do not prohibit data from containing content that can be executed by a Web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, and
Activex.
[4] The victim accesses the generated Web page through a Web browser that contains malicious scripts that have been injected with non-trusted data.
[5] Because the script comes from a Web page sent by the Web server, the victim's Web browser executes a malicious script in the context of the Web server's domain.
[6] This actually violates the intent of the Web browser's Origin policy, which declares that scripts in one domain should not be able to access resources in other domains or run code in other domains.
Once a malicious script is injected, the attacker is able to perform various malicious activities. An attacker could transmit private information (such as a cookie that may contain session information) from the victim's machine to an attacker. Attack
A attacker could send a malicious request to a Web site as a victim, which could be particularly dangerous to the site if the victim has administrator privileges to administer the site.
Phishing attacks can be used to mimic a trusted site and induce the victim to enter a password, allowing an attacker to compromise the victim's account on the Web site. Finally, the script can take advantage of the Web browser
The fragility of the body may be the machine that takes over the victim (sometimes referred to as a "pass-through").
There are three main types of XSS:
Type 1: Reflected XSS (also known as "non-persistent")
The server reads the data directly from the HTTP request and reflects it back to the HTTP response. In the case of a reflected XSS exploit, an attacker could cause the victim to make a reference to a vulnerable web application
Content, which is then reflected back to the victim and executed by the Web browser. The most common mechanism for passing malicious content is to include it as a parameter in a public publication or sent directly to an
The victim's URL. URLs constructed in this manner form the core of many phishing schemes, whereby an attacker could defraud the victim of the trust to access a URL to a vulnerable site. At the station
After the attacker's content is reflected back to the victim, the victim's browser executes the content.
Type 2: Stored XSS (also known as "persistence")
Applications store dangerous data in databases, message forums, visitor logs, or other trusted data storage. At a later time, the hazard data will be read back to the application and included in the dynamic content
In From an attacker's point of view, the best place to inject malicious content is the area that is displayed to many users or users of particular interest. Users who are interested typically have higher privileges in the application,
Or they interact with sensitive data that is valuable to the attacker. If one of the users executes malicious content, the attacker may be able to perform privileged operations as that user, or gain
Access to sensitive data that belongs to that user. For example, an attacker could inject XSS into a log message, and an administrator might not handle the message correctly when viewing the log.
Type 0: DOM-based XSS
In Dom-based XSS, the client performs an operation that injects XSS into the page, and in other types, the injection is performed by the server. DOM-based XSS typically involves sending to a client
Trusted scripts that are controlled by the server, such as JavaScript that performs a sanity check on the form before the user submits the form. If the server provides a script that processes user-supplied data, then the data
Injected back into the Web page (for example, through Dynamic HTML), the DOM-based XSS is likely to occur. The following example shows a script that returns a parameter value in a response.
The parameter value is sent to the script by using a GET request and then returned in the response embedded in the HTML.

[REQUEST] Get/index.aspx?name=jsmith http/1.1

[response]http/1.1 OKServer:SomeServerDate:Sun, 2002 00:31:19 gmtcontent-type:text/htmlaccept-ranges:b Ytescontent-length:27<html>Hello JSmith</html  >

An attacker could exploit an attack that resembles the following:

[ATTACK request]get/index.aspx?name=> "' > < Script > alert ('PWND') </ Script > http/1.1

[ATTACK response]http/1.1 OKServer:SomeServerDate:Sun, 2002 00:31:19 Gmtcontent-type:text/htmlaccept-r anges:bytescontent-length:83<HTML>Hello > "' ><Script>Alert ('PWND')</Script></HTML>

In this case, the JavaScript code will be executed by the browser (> ' > section is not relevant here).

Cross-site Scripting instances (AppScan scan results)