ứng dụng mã tạo ra lỗ hổng, sau đó nó thực sự không nên được hoàn toàn đáng tin cậy. Các tùy chọn thực hiện đầu tiên là để loại bỏ các lỗ hổng ứng dụng. Điều này thường là trách nhiệm của chủ sở hữu ứng dụng, nhưng đôi khi nó là phù hợp với bạn là chủ sở hữu cơ sở dữ liệu để được tham gia. | 158 Secure the database from SQL injection attacks application code creates vulnerabilities then it really shouldn t be completely trusted. The first implementation option is to remove the application vulnerabilities. This is normally the responsibility of the application owner but sometimes it is appropriate for you as the database owner to be involved. By now there are some good SQL injection guidelines for application developers such as the following All data entered by users needs to be sanitized of any characters or strings that should not be part of the input expression and all input field must be validated. SQL used to access the database from application code should never be formed using string concatenation. Strongly typed parameters usually in combination with stored procedures should be used wherever possible. Prepared statements parameter collections and parameterized stored procedures should be used wherever possible. Application login should be a function implemented within a well-validated stored procedure. Quotes should be added to all user input even to numeric data. These guidelines are for developers. If you have some leverage use it. Make developers adhere to these guidelines. If you are fortunate you can even require a code review in which you participate in this case try to look at the framework for managing the SQL that hits the database hopefully there is a framework and it s not just string concatenation all over the place . I want to stress the use of prepared statements. When you use prepared statements as opposed to string concatenation the SQL strings are distinct from the values that you get from the user and thus there is no mixing of SQL and parameters. This is therefore one of the simplest ways to combat SQL injection. Monitoring and tracking whether prepared statements are used is actually simple to do. If you use a network-based SQL inspection product you will see a difference in the SQL that travels on the network in the case
