Any application that uses user-supplied data for database queries is a potential target for SQL injection attacks. Database administrators may not be able to completely block SQL injection attacks against their database servers, but administrators and application developers can do something to minimize the impact of these attacks.
What can a database administrator do?
Do not put the database and Web server on the same machine
Use a firewall or a routable IP address to block Internet access to the database. Once configured, packets from the database server will not be forwarded to the Internet. You need to add a route on the Web server to locate the database server.
Configure trusted IP access and access (for example, IPSEC) to control which machines can communicate with the database server.
Remove all sample scripts and applications from the database server.
Use a dedicated, low privileged account for each application's database connection account. Do not use SA, DBA, admin.
Do not allow users or applications to access database tables directly. To use an application role that has limited access to the database. If your application requires only read access, the access to the database is limited to read-only.
Remove unused stored procedures from the production database.
The access to the application is authorized only to the stored procedures created by the user.
Do not authorize the application's "_any_" to the operating system commands or system stored procedures.
What can the designer of an application do?
Program designers shoulder the important responsibility of securing Web applications. Strengthening security scrutiny during the design and coding phase is the key to eliminating procedural vulnerabilities. Generally, programmers should at least implement some of the following measures:
To create a specific generic error message that the application will generate. Because the default error message generated by the database during a SQL injection attack, an attacker can obtain valuable information, such as the names of tables and columns.
Verify the legality of user input before submitting the user Service input to the database. Accepts only the desired user input and limits its length. Note that whenever possible, use the whitelist list to check all user input. The application server firewall can be used to check all input and accept only those that meet the criteria.
During program development, use the Web Application Scan Tool to discover vulnerabilities in your code.
Isolate the Web application from the SQL database and place all the SQL required by the application on the database server.
Use static queries. If you need a dynamic query, use the prepared statement.
Use a secure interface, such as the command Object of ADO, to enable the application to execute stored procedures.
Detecting SQL injection Vulnerabilities and attacks
It is not easy to detect vulnerable applications because these vulnerabilities may exist in any user-facing application interface. Although not all SQL injection attack techniques are easy to detect, a database administrator or developer can do the following things:
Read the log for the Web server. In some cases, SQL injection attacks can easily be found in these logs, because there are many more log entries than usual.
Look for HTTP 404 and HTTP 500 error log entries and other error log entries that the program generates to check user input.
Use the Web Application Scan tool. These tools can be used to warn database administrators about where SQL injection is vulnerable in an administrator application.
Before you deploy your application, it is critical to examine the SQL injection factor.
In summary, a robust solution to the SQL injection attack should be to examine multiple aspects of development, deployment, management, and maintenance, and require security managers to keep an eye on the latest trends in SQL injection and to use practical tools to minimize the vulnerabilities of programs.