Application Security and Development checklist. That checklist is rather large, and covers the whole spectrum of application development. A good portion of the checklist is manual in nature; either looking at configurations, checking documentation, or interviewing the appropriate personnel with regards to the application. There are a few controls for which we run an automated tool looking for some of the major vulnerabilities (command injection, XSS, SQLi, limited buffer overflows, temp files, error messages, etc.)
I bought this book so I could understand the underpinnings of the SQL injection: why it exists, how to make it work, and to some degree, how to fix them. (I don't need to fix them, however, it's nice to be able to help the client mitigate open vulnerabilities.) I have prior SQL experience (coming from the DBA/DBD world) so the concepts of SQL are quite familiar to me. And of course, when most people think of SQLi, they think of the familiar ' or 1=1. I wanted to know more, and I wanted a more advanced knowledge. Sure, we run tools, but I wanted to be able to confirm our tool's output. And, I wanted the ability to perform the analysis manually. One other caveat worth mentioning, many of the systems I audit are CAC-enabled; which the tools we use do not handle too well. It's easy to manually log in, authenticate, and manually exploit/search for vulnerabilities.
I admit it, I bought the book mainly for chapters 2, 4, 5, 6, and 7. These chapters talk about testing for SQL injection, exploiting SQL injection, blind SQL injection, exploiting the operating system and advanced topics, respectively. And those chapters were great. I satisfied my objective to learn how to really accomplish the task of finding and somewhat-exploiting found inection-able fields. (We're not hired to pen-test, just audit....so we can't go nuts with a finding once we find it. The fact that the vulnerability is there is enough.) Chapter 7 discussed advanced topics, and contained a sub-section on finding second-order vulnerabilities. The topic presented made me think of this post, and other uses for SQL injection.
However, I got so much more from the book. Chapter 3 discussed reviewing code for potential SQL injection. What to look for, types of data, frameworks, and static code analysis tools were all discussed. This was extremely beneficial because while we do not do code reviews, I can better speak to the client on how they can make their code reviews better; and what they should be looking out for (at least in a general sense.)
Chapter 8 is a great chapter on how to remediate findings; fixing code, both in the application and in the database. Chapter 9 talked about platform-level defenses and remeditions that can be used to harden the servers and operating systems that house the data, web server or database server. Many of the points mentioned in Chapter 9 are controls found in the Application Security and Development checklist. These are issues that if employed will directly satisfy the requirement in the checklist. Finally, chapter 10 includes a great reference on SQL and SQL injection. As a former DBA/DBD, I could skip the SQL primer. The chapter also included some of the databases that the book did not delve into; namely PostgreSQL, DB2, Informix and Ingres. Finally, there were cheat sheets for the topics discussed throughout the book.
This is certainly one of the best books I've read in a bit. I really could not find much that detracted from the book. Go into the book knowing that the topics are geared towards MS SQL Server, Oracle, and MySQL; as they should be, they are the three widest-used databases. Be prepared to learn a lot. I'm looking for vulnerable web applications that I can install and use to reinforce the concepts so that I am better prepared when I go on audits. I highly recommend the book; whether you are an application/sql developer, an auditor or a pen-tester.