Security via obscurity...
ORA-01400: cannot insert NULL into ("ASK_TOM"."WWC_ASK_QUESTION_ACCESS_LOG$"."DISPLAYID")
Their comment was “isn’t it a good practice to never give detailed error messages to end users”. I was curious – was this about ‘user interface’ issues (some people do not want to give out the error message for aesthetic reasons) or was this about ‘security via obscurity’.
Turns out it was ‘security via obscurity’. They said “I now have some basic information for SQL Injection attacks”. The thought was - that by having knowledge of a column name – an application would be more SQL Injection attackable.
To me – it is more of a binary thing, either your application is subject to SQL Injection attacks or it is not. It is sort of like data integrity – you either got it or you don’t (it isn’t like hull integrity on Star Trek, data integrity is either 100% or 0%).
Knowledge of the program should never be a cause for alarm. The names of the tables, their columns, the SQL used, the program flow, the algorithms and so on – if they are “protected from prying eyes because of security concerns – knowledge of them makes us subject to attack” then you have a problem. You are already subject to attack, it is merely a matter of time. There are valid reasons for protecting these things from prying eyes (intellectual property reasons mostly), but security isn’t one of them.
If by looking at my application code, logic, schemas, whatever – you can attack it, you could attack it already. It must be vulnerable in the first place. You cannot hide SQL Injection vulnerabilities (you should read this most excellent paper on the topic – it is obvious to me that the people that put together this video read it, they used the techniques outlined there. I picked up that video from Pete Finnigan’s blog).
Beware when someone says “no, you cannot show that for reasons of security”. That almost certainly means there is a bug lurking there just waiting to be exploited.
On asktom – I do not use string concatenation to build my SQL, I bind all strings, numbers and dates using either bind variables or application contexts. That means the end user cannot change the meaning/intent of my SQL.