لطفا منتظر باشید ...
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to and click on the form. You will alsogain access to thousands ofotherFAQs at ITFAQnet.com.1. | Does SQL injection affect all databases or just SQL Server? Is any database more secure than another. |  |
2. | Are there any quick black box tests I can run to see if my application is vulnerable to SQL injection? | |
3. | When choosing a SQL Server authentication strategy, when should I use Windows Authentication and when should I use Windows and SQL Server Authentication (mixed)? | |
Answers
1. | All database servers are vulnerable to SQL injection to some extent. The actual risk depends on many factors, including server features, default configuration, complexity, documentation, etc. SQL injection is more of a code issue than a database issue. If you properly filter input and follow the best practices covered in this chapter, the capabilities or vulnerabilities of the backend database should have little consequence. |
2. | It is much more difficult to fully identify SQL injection vulnerabilities from the outside, they usually require a thorough code review. However, there are some checks to quickly identify SQL injection vulnerabilities. Find some form of user input, such as a web form, a query string parameter, or a cookie, and try inserting invalid characters such as a single quote or a semicolon. If you see an actual database error, chances are it is vulnerable to SQL injection. Another favorite is entering the string ‘ or 1=1-- into a web login form. Poorly written login code will sometimes accept this and log you in as the first user listed in the database. |
3. | As a general rule, using Windows Authentication provides far more benefits, including a more robust authentication and authorization infrastructure, the ability to keep credentials out of connection strings, and the administrative benefits of not having to maintain a new security model (SQL Server’s native authentication and authorization mechanisms). You can simply grant SQL Server access to any Windows group(s) that need access and apply permissions accordingly. A common argument for using the mixed security model is that connection pooling is defeated when users have their own security context. Connection pooling is the ability to recycle established database connections, thus increasing connection speed for newer connections. However, in Web-based applications, it is likely that all users will share a single user context anyway when performing data access. It makes no difference from a connection pooling perspective whether the account performing the data access is a single Windows account or a native SQL Server account. |
