Extremely dangerous and common website security vulnerabilities and Solutions

Extremely dangerous and common website security vulnerabilities and Solutions

Recently, I handled two security vulnerabilities in the company's Internet project, which are common and dangerous.

I. reflected Cross-Site Scripting Vulnerability

Vulnerability risks:

Attackers can embed an Attack Script. Once the page is loaded in the user's browser, the script is executed. Attackers may steal or manipulate customer sessions and cookies, which may be used to mimic legitimate users, so that hackers can view or change user records and execute transactions as such users.

Example:

The parameters passed through program parameters are output to the HTML page. When the following URL is opened, a message is returned:

Http: // ***. com/xss/message. jsp? Send = Hello, World!

Output content: Hello, World!

This function extracts data from parameters and inserts it into the HTML code after the page is loaded. This is an obvious feature of the XSS vulnerability;

If this program does not have security measures such as filtering, it will be vulnerable to attacks.

Let's take a look at how to launch an attack. Replace the URL parameters of the original program with the code we use for testing:

Http: // www. ***. com/xss/message. jsp? Send = <script> alert ('xsss') </script>

The page output content is: <script> alert ('xss') </script>

When a user opens a browser, a message is displayed.

If the user has logged on to the Web system normally and obtained a cookie for session information, then open the page where hackers embed illegal scripts, then hackers can basically hijack user sessions through cookie information.

Solution:

1. Do not trust any user input for verification. If conditions permit, use the whitelist technology to verify the input parameters;

2. Escape the content provided by the user during output.

 

Vulnerability risks:

By constructing a URL, attackers can redirect users to any URL. This vulnerability can trick users into accessing a page, Trojan, password record, and downloading arbitrary files.

Example:

 

For example, after a single sign-on, you can jump back to the original page

 

Normally, it should be as follows,

Http: // www. ****. org/login. php? Jumpto = http: // www. Normal website. com

In this case, modify it as follows:

Http: // www. ****. org/login. php? Jumpto = http: // www. malicious website. com

After successful login verification, you will jump to a malicious website, which can be imagined as a threat.

Solution:

1. Verify user input;

2. Indirectly redirect to a third-party website by using post

3. Some websites can use a whitelist to make credible judgments on the domain names to jump

4. To ensure that all generated links come from our trusted domains, add uncontrollable tokens to the generated links to verify the generated links, this can prevent users from generating their own malicious links and making them available. However, if the function itself requires openness, some restrictions may be imposed.

The last two tools can scan for some vulnerabilities: IBM Rational AppScan and Acunetix Web Vulnerability compliance.

In the past, when I was a website, I seldom paid attention to security issues. The most important thing was SQL injection. After these two vulnerabilities were fixed recently, I found that there are still many differences between LAN projects and Internet projects, many security issues need to be considered.

Come on.