There is a lot of truth in saying that every tool can be used by good and by evil. There is no point in blocking the tools themselves as the attacker will turn to new tools and subvert the very familiar tools in unexpected ways. Now Google crawler bots were turned into such a weapon to execute SQL injection attacks against websites chosen by attackers.
The discussion of whether Google should or should not do anything about that is interesting but we are not going to talk about that. Instead, think that this is a prime case of a familiar tool that comes back to your website regularly subverted into doing something evil. You did not expect that to happen and you cannot just block the Google from your website. This is a perfect example of a security attack where your application security is the only way to stop the attacker.
The application must be written in such a way that it does not matter whether it is protected by a firewall – you will not always be able to block the attacks with the firewall. The application must also be written so that it withstands an unanticipated attack, something that you were not able to predict in advance would happen. The application must be prepared to ward off things that are not there yet at the time of writing. Secure design and coding cannot be replaced with firewalls and add-on filtering.
Only such securely designed and implemented applications withstand unexpected attacks.
It is often debated how Quality assurance relates to Security assurance. I have a slightly unconventional view of the relation between the two.
You see, when we talk about the security assurance in software, I view the whole process in my head end to end. And the process runs roughly like this:
- The designer has an idea in his head
- The software design is a translation of that into a document
- Development translates the design into the code
- The code is delivered
- Software is installed, configured and run
Security, in my view, is the process of making sure that whatever the designer was thinking about in his head ends up actually running at the customer site. The software must run exactly the way the designer imagined, that is the task.
Now, the software has to run correctly both under the normal circumstances and under really weird conditions, i.e. under attack. So the Quality Assurance takes the part of verifying that it runs correctly under normal circumstances while Security Assurance takes care of the whole picture.
Thus Quality Assurance becomes an integral part of Security Assurance.
TechRepublic has an interesting article “Website and app security tips for software developers” that talks in a very short space about a whole bunch of things, from the “shelf life of software developers” to the advice on security for the website developer.
It provides in particular an interesting insight into why a person thoroughly familiar with security made security mistakes again and again.
I know why I made those mistakes — it was either the hubris of “I can roll my own better than off-the-shelf,” or the idea that slapping something together quickly would be fine “for now” and I would pay the technical debt off later. I was wrong on both counts, every single time.
How often do we get trapped like that?