Security Vulnerabilities [http://luoluo.cnblogs.com /]

Every day, when we open the Bugtraq email list, new vulnerabilities are constantly discovered, so we are dazzled: Buffer Overflow, SQL injection, XSS cross-site scripting ......, As a result, black hats began to analyze vulnerabilities, write attack code, and test the published details. White Hats also need to analyze these vulnerabilities and Write vulnerability scan rules or prevention rules. The attack code of the black hats will soon spread on the Internet, and the script boys are also getting busy. They are tired of using these vulnerabilities to gain control permissions on vulnerable hosts around the world, sometimes virus and worm writers will join in and make attack code into viruses and worms and spread on the Internet.

As an application developer, I don't seem to be so concerned about these network security events. We follow our rules and keep repeating in our circles, can we catch up with this progress? How can we use better methodologies and models to improve our development process. In our opinion, the people mentioned above are just some volunteer code reviewers. We will still try to copy the strings sent by users to our own variables without checking them. We will still construct our SQL query statements by concatenating strings for our queries, it does not take into consideration whether the content submitted by the user in the page will add some special effects to our webpage. Nothing is more important than simply and effectively completing your tasks. It is simply thankless to think about so much, it may even lead you to lose your bonus or the trust of your leadership.

After talking about this, it seems that I have deviated from the topic I want to write this article. Now I am back to the question: security vulnerabilities. How can security vulnerabilities become security vulnerabilities? Through the complicated technical analysis, we will find that vulnerabilities have common characteristics. The first is that the data submitted by the user is executed, and the second is that the data submitted by the user leads to changes in the program process. These two features can be used to summarize the major types of vulnerabilities that have been prevalent over the years, for example: the buffer overflow vulnerability is caused by the excessive amount of data submitted by the user, which overwrites some important pointers and redirects the program process. As a result, the data submitted by the user is executed, the cause of the SQL injection vulnerability is that the string entered by the user is executed as an SQL command. The XSS cross-site scripting vulnerability also allows the browser to execute the data submitted by other users.

Therefore, we found that the key to solving security vulnerabilities is to prevent data from being executed as code. The DEP Data Execution Protection of Windows 2003 Server is a targeted solution. For XSS vulnerabilities, we can use HTML encoding to encode the data submitted by users in the browser to prevent them from being executed in the browser. Finally, as a web programmer, i'll talk a little more about SQL injection. In database programming, the following code has almost become a classic method, and it is not uncommon in various books and materials:

Strsql = "select * from [users] Where [uid] = '" + struid + "'";
Execute (strsql );

This method is used to execute the query by splicing the SQL statement. If struid is input by the user, data may be executed as code, many articles have put forward the use of combing user input to prevent such vulnerabilities, the following example to filter single quotes into single quotes in the T-SQL Escape Character double single quotes:

Strsql = "select * from [users] Where [uid] = '" + struid. Replace ("'", "'' ") + "'";
Execute (strsql );

However, sorting user input does not conform to our fundamental idea of blocking Data Execution. To prevent user input data from being executed, we only need to abandon this method of splicing SQL statements, instead, we should pass user input as parameters to SQL statements, which is why stored procedures are more secure in many articles, because stored procedures generally pass user input as parameters, but stored procedures are not necessarily safe. If you splice SQL statements in the stored procedures, this is the same as the above program. See the following example:

Create procedure [DBO]. [test]
(
@ ID int,
@ Username varchar (30)
)
As
Declare @ strsql varchar (300)
Set @ strsql = 'select * from [users] Where [ID] = ''' + STR (@ ID) + ''' and [username] = ''' + STR (@ username) + ''''
Exec @ strsql
Go

Such a stored procedure violates the above principles, so it is also a stored procedure with vulnerabilities. In the end, as long as SQL statements are completely eliminated, the SQL injection vulnerability can be completely eliminated. Some people will ask what to do with common SQL queries and use stored procedures? No. Java and. Net both provide a parameter-based SQL statement query creation method. The following is an example of. Net code snippet:

Struid = request. querystring ["uid"]. Trim ();
Strsql = "select * from [users] Where [uid] = @ uid ";
Sqlparameter = new sqlparameter ("@ uid", sqldbtype. varchar );
Sqlparameter. value = struid;
Sqlcommand. Parameters. Add (sqlparameter );
Sqldatareader = sqlcommand. executereader ();

(Note: For Java programs, see java. SQL. preparedstatement Interface)

At first glance, there seems to be a loophole in the absence of filtering input. In fact, the injection environment has been completely eliminated here. If you don't believe it, try it out. :) You should develop a good habit from now on.

Xixi said it was a casual talk. As a result, it turned out to be an old topic to prevent SQL injection. I hope I can be inspired by the developers. In the end, we can see fewer bugs in Bugtraq. In this way, it seems to be a bit more positive. Black hats and friends should not take eggs at me. We can also use such features to review code mining vulnerabilities. Of course, for these things, you must be better at it than I do.

Screw blog