The principle of the hottest SQL injection attack

  • Detail

The principle of SQL injection attack and its preventive measures

asp programming threshold is very low, and novices are easy to get on the road. In a short period of time, novices often have been able to create a perfect dynamic station. In terms of functions, novices can do what the veteran can do. So there is no difference between novice and veteran? There is a big difference, but it is difficult for laymen to see it at a glance. The friendliness of the interface, the running performance and the safety of the station are the three focus points that distinguish novices and veterans. In terms of security, the most easily overlooked problem for novices is the problem of SQL injection vulnerability. Scan some ASP stations on with nbsi 2.0, and you can find that there are SQL injection vulnerabilities in many ASP stations. Such vulnerabilities are more common in some stations of internal institutions of colleges and universities in education. Maybe this is because most of these stations are made by some students. Although they are all very smart, they have no experience after all, and are in the process of learning. It is inevitable that there are many vulnerabilities. This article mainly talks about the preventive measures of SQL injection. To understand the use of these preventive measures, we must first explain in detail the process of SQL injection vulnerability intrusion. Novices see

a large number of programmers fail to judge the legitimacy of user input data when writing code, which makes the application program have potential security risks. If this is a normal address http://localhost/lawjia/show.asp?ID=444 After submitting this address to the server, the server will perform a query similar to select * from table name where field = &id (ID is the parameter submitted by the client, in this case 444), and then return the query result to the client. If the client intentionally submits such an address here: http://localhost/lawjia/show.asp?ID=444 And user>0. At this time, the server runs a query such as select * from table name where field =444 and user>0. Of course, this statement cannot run. There must be an error, The error information is as follows:

· error type:

microsoft OLE DB provider for ODBC drivers (0x80040e07)

[microsoft][odbc SQL Server driver][sql server] a syntax error occurred when converting nvarchar value 'sonybb' to a column with data type int

/lawjia/p, line 47

but people with ulterior motives can get the following information from this error message: the station uses MS SQL database, connects with ODBC, and the connection account name is sonybb. The so-called SQL injection is to deliberately submit special code from the client to collect the information of the program and the server, so as to obtain the desired data, taking advantage of the programmer's lax or non detection of the legitimacy of the user's input data. Usually, the goal of those with ulterior motives is to obtain the account and password of the station administrator. For example, when a person knows that the station administrator account exists in the login table, the administrator account name is admin, and he wants to know the administrator password, here he submits such an address from the client: http://localhost/lawjia/show.asp?ID=444 And (select password from login where user_name='admin ')>0, the error information returned is as follows:

· error type:

microsoft OLE DB provider for ODBC drivers (0x80040e07)

[microsoft][odbc s protection and use costs are also much higher than the varchar value'! @ Syntax error converting admin 'to column with data type int

/lawjia/p, line 47

did you know? The red part above is the password of the administrator account admin! Although it's very complicated and people can't remember it after watching it for several times, it is displayed in front of you. At this time, you can use this account and password to take over people's stations! At this time, you may also say that if he does not know in advance that the administrator account exists in the login table and that the administrator account is admin, he cannot obtain the administrator password. You are wrong. As long as someone is willing to spend more time trying, he will be able to get all the information within the database connection account permission! For the specific process, please refer to the above article: full access to SQL injection vulnerabilities

of course, this process is cumbersome and takes a lot of time. If SQL injection intrusion can only be carried out manually, many ASP stations with SQL injection vulnerabilities will be much safer. It is not that the vulnerability does not exist, but that the cost of using this vulnerability to invade is too high. But if we use special hacker tools to invade, the situation will be very different. It takes at least half a day, one day or even many days for SQL injection intrusion to be carried out manually. However, it only takes a few minutes to use special tools to invade (depending on the speed). Then, using the obtained management account and password, upload an ASP backdoor program downloaded from the top, and you can easily obtain the management authority of the entire station, even the management authority of the entire server. The most important SQL injection intrusion tool that can not distort the specimen name is nbsi 2.0, which has been released to version 2.0. However, the official name of others is not SQL injection intrusion tool with higher tear sound toughness and high impact strength, but station security vulnerability detection tool. With this so-called detection tool, the invasion of ASP stations with SQL injection vulnerabilities has become a children's game. Those young men who neither know ASP nor SQL can often invade more than ten ASP stations in one day, so that they can obtain great satisfaction in their hearts. They also seem to pay great attention to professional ethics, and often do not damage the station data and system. Most of the common ways of destruction are simply to change the station's home page and leave a "good warning", such as: your station has SQL injection vulnerabilities, please take preventive measures! He also stated that "I have not damaged data and systems", and some even took the opportunity to release his advocacy: "do not invade domestic stations, and have the ability to invade little Japan!", Finally, signing his name is a necessary procedure

in most cases, such a great achievement can be achieved with the mouse. Open the latest version of nbsi 2.0, as shown in Figure 1: enter the address in area A. note that the address must be the one with transmission parameters. Click the detection button on the right to display the information in area B. It shows that the current user is sonybb, the permission is public, and the current library is lawjia. It's a pity. If it is sa permission, it can be injected across databases. However, this permission is enough to obtain the station administrator account and password. Click the auto guess button in area C to display the various tables in lawjia of the current database. Wow, the login table must contain the administrator account and password, right? Select it, and then click the auto guess button under area D to immediately display the column names in the login table. As expected, it stores the user name and password. It's great! Tick the box quickly and click the auto guess button under area e impatiently. The exciting moment is coming. I saw all the accounts and passwords come out. The rest is to identify which account is the administrator

Figure 1 (the example in the figure runs on the author's local computer)

I wonder how ASP programmers who have not paid attention to SQL injection vulnerabilities feel about the example above? Do you think the so-called station security vulnerability detection tool SbSI 2.0 is simply MS_ What about SQL enterprise manager? It's just that people can view all the information in your database without an account and password. If your station is invaded without any effort, will you vomit several liters of blood? Perhaps you have made great efforts for system security, including installing patches, firewalls, anti-virus software, and cleverly configuring IIS and database user permissions, but you just didn't notice the SQL injection vulnerability, so "the Bank of thousands of miles collapsed in the ant nest". Firewalls and anti-virus software can not prevent SQL injection, because SQL injection intrusion is no different from ordinary web page access, so it is often not very well prevented. Moreover, there are often many stations placed on a server, so the server administrator cannot review whether there are SQL injection vulnerabilities station by station and page by page. So how to prevent SQL injection intrusion? What should I do as a server administrator or a station programmer? The server administrator mainly needs to configure IIS and database user permissions, while the station programmer mainly needs to prevent SQL injection intrusion in programming. The following is a detailed description:

by the way, the server administrator, since it is impossible for you to check whether there are SQL injection vulnerabilities in each station one by one, here is a unique trick. This unique skill can effectively prevent SQL injection intrusion, and "it saves both worry and effort. The effect is really good!" SQL injection intrusion is based on the ASP error prompt information given by IIS. If you set IIS to give only one error prompt information, that is, HTTP 500 error, no matter what kind of ASP error occurs, people will not be able to invade. Please refer to figure 2 for specific settings. Mainly change the default prompt page c:windowshelpiishelpcommonp of the 500:100 error to c:windowshelpiishelpcommonm. at this time, no matter what error occurs in the ASP operation, the server will only prompt the HTTP 500 error

Figure 2. IIS error information setting

but a bad thing about this setting is that when the code written by the programmer makes an error, the server does not give detailed error prompt information, which will bring great inconvenience to the programmer. However, the server is not the place to test the code after all, and it should adhere to security and stability first. This setting is understandable. In fact, many server error messages are set in this way

the server administrator should also set the execution permission for each station in IIS. Do not give other static stations the "script and executable" permission. Generally, it is enough to give a "pure script" permission. For those directories where files uploaded through the background management center are stored, it is even more stingy. Set the execution permission to "None". This is to prevent others from uploading ASP Trojans. The execution permission is set to "None". If there is a lot of dust on the measuring instrument, SP Trojans cannot run. Generally, the SQL injection vulnerability only involves the security of a station. If someone uploads the ASP Trojan horse through this vulnerability and runs it, the whole server will be lost. Therefore, far sighted and intentional server administrators should miserably configure the IIS execution permissions

the same stingy attitude should be applied to the permission configuration of database users. Of course, the database here refers to MS SQL, and access does not have the step of user permission configuration. If the public permission is enough to use, never give any higher permission. Do not give sa level permission to others casually. The so-called station security vulnerability detection tool nbsi 2.0 has the function of SQL injection across databases. If you give sa permission to a library with SQL injection vulnerabilities, other libraries will not be protected! A fire at the city gate will bring disaster to the fish in the pond. And people can call XP_ The cmdshell command gets the highest privileges on the system

next, let's talk about the preventive measures for programmers. The program mainly needs to do two things. Of course, the most important thing is to carefully detect the variable parameters submitted by the client. Variables submitted to the client

Copyright © 2011 JIN SHI