Webgoat learning-cross-site scripting (XSS ))

Cross-site scripting (XSS ))

XSS (Cross Site Script) cross-site scripting attacks. Attackers insert malicious HTML code into the attacked web page. When a user browses this page, the HTML code embedded in the page is executed to achieve the Special Purpose of the attack. XSS and csrf (Cross Site Request Forgery) are collectively called Web killer combinations. Hackers penetrate the page logic to display the input content as expected, so as to fool or attack users. Common XSS attacks include stored XSS attacks and reflected XSS attacks.

Stored XSS (stored XSS)

Stored XSS is the most widely used vulnerability that may affect the security of web servers. Hackers upload attack scripts to Web servers, this makes information leakage possible for all users accessing this page.

Figure 1 stored XSS attack example

1. User A modifies personal information and sends threatening JS Code as personal information to the server;

2. User data is stored on the server without filtering;

3. User B can view User A in the friend list and user a's personal data;

4. The server extracts user a's data and returns it to the Web Front-end;

5. the front-end is displayed according to pre-rules, including the front-end executable code of user a with HTML tags and JS, so that user a can execute any threatening code preset by user B on the machine B.

For example, if user a modifies user remarks to <SCRIPT> alert ("Haha"); </SCRIPT>, run the code on user B's page according to the preceding procedure.

For example, a hacker preinvestigates the code logic of a BBS post to display the content, and then posts a post:

After submission, it appears in the post list:

When other users click to view the post, the tragedy occurs:

Okay, it's just a prank.

Solution

1. perform XSS filtering to escape or filter some unreasonable tags (for example, <> %/). XSS filtering before storing the tags in the database is more effective than XSS filtering before display.

2. restrict user input characters, such as: Code only allowed \ s = whitspace: \ t \ n \ x0b \ f \ r, \ W = word: a-zA-Z_0-9

Reflected XSS (reflected XSS)

If the server does not filter input parameters or the filtering is incomplete, the user's input data may be returned to the front-end page. When the Web Client uses the server script to generate the page to provide data for the user, if unauthenticated user data is included in the page without HTML Entity encoding, the client code can be injected into the dynamic page.

Figure 2 reflected XSS example

1. User A constructs a parameter value with a JS Code URL and sends the URL to friend B to inform him that he can participate in the activity;

2. After receiving the request, friend B finds that the request is an official URL. Then, click the URL;

3. If the server does not strictly verify the request parameters, the parameters are directly returned to the front-end page;

4. The JS Code in the parameter is returned to user B's browser with HTML and executed.

For example, after a website inputs user information, the server verifies that the input is incorrect, returns the error page, and displays the error content to the user "friendly". For example:

The user uses an aggressive URL as the input source. For example, , the server jumps to the corresponding error page, as shown below:

In this way, malicious Js in www.xxx.com will be executed.

Hackers can package or directly expose the URL of the submitted request. users usually see that the URL of a trusted website does not have any preventive clicks, resulting in losses, for example, the above can be exposed to the user URL:

Http: // localhost: 8080/webgoat/attack? Screen = 31 & menu = 900 & qty1 = 1 & qty2 = 2 & qty3 = 2 & qty4 = 1 & field2 = 1111111 & field1 = % 3 cimg + SRC % 3d % 22www.xxx1.com % 22% 2f % 3E & submit = purchase

Solution:

Same storage type XSS attack.