Deb’s been recovering from an operation recently. During her convalescence, I have been designated as her nurse and carer.
Careful planning was required prior to the op. She promised not to over do things, and I promised to attend to her every need.
“I should have a little bell so I can ring when I need you”, she opined. “After all, that’s what they do in Downton Abbey”.
We don’t have a bell. Fortunately Deb did have something that would do the job. Last Christmas, a thoughtful relative had given her a toy gun, a replica of the sort that was in the Despicable Me films.
Yes, when my presence was required, Deb simply had to fire the Fart Gun.
In order to attempt to retain a little of the Downton aura that she had been so keen to capture, I did make a point of saying “You rang M’Lady”, in my best Parker-from-Thunderbirds voice whenever I was summoned by the sound of electronic flatulence.
It seems to have worked out OK in the end. Deb is now up and about, having survived a week of my cooking.
When not attending to my nursing duties, I did have the chance to catch up with the unfolding story about the latest TalkTalk cyber attack.
Things that, in retrospect, are quite obvious were rather less clear at the time they were reported.
To begin with, the report was of a Distributed Denial of Service (Ddos) attack which had resulted in a loss of customer data.
Was this some fiendishly clever variation on the theme of a Ddos attack ? As far as I knew, such an exploit was designed solely to take down a site, not to obtain data.
Further “clarification” followed. It was reported that there had also been a “Sequential Attack”. I’ve never heard of one of those.
Just before I ran off to do some research, this was finally translated into techie – it was actually a SQL Injection (SQLi) attack.
Later, it was reported that TalkTalk have estimated the cost of this attack at up to £35 million.
Whilst it’s easy to laugh at the efforts of a CEO struggling with the terminology around this topic, it’s worth bearing in mind that the responsibility, ultimately, lies within the IT Department. But where ? with the Network Admins, Architects, the DBAs ?
As a Database Developer, you may well be feeling confident about security at this point.
After all, your code is sitting on the database server. Access to that server is probably restricted to a White List of machines, which will include the Application Server.
If you’re working with a public facing web application, the Application Server will be sitting behind a firewall.
Additionally, it may well be the case that the Application has been designed to implement the Data Access Layer pattern. Any database calls from the Controller layer are made to your PL/SQL packages which have been written to the Transactional API (XAPI) pattern. So, you don’t even need to wonder whether your Web Developers have used prepared statement calls.
On top of that, the application only connects to the database as a minimally privileged database user. The Application Owning schema itself is actually locked.
What we’re going to cover here is a Database Developer’s eye view of how such an application might look.
We’ll also look at just why these multiple layers of security provide no protection whatsoever against a SQL Injection attack.