So some personal thoughts on some security issues. I must point out that I am not a security expert and in fact I suck at security aspect of developing a software, but if you read you might understand that I probably do not have to be security expert to write more secure applications as long as I understand some of the aspects of security vulnerabilities etc.
Two of the probably most common security issues are SQL inject and cross site scripting, XSS. Although they are two separate security issues I think they are basically almost the same, at least their fundamental idea is quite similar. On SQL injection attack the user types something into the user input which is then executed as part of the SQL query without any sanitation. In XSS the user is able insert something into user input that can be damaging or vulnerable if the input is rendered as is to other users for example. In this case too the user input is stored and/or displayed without sanitizing the input. XSS have more complex issues than that, but basically it usually comes down to the fact that an user, or attacker if you wish, is able to feed some input to the system that creates vulnerability.
The attacker can be seen as the root cause of the problem, but the system that presents these vulnerabilities are part of the equation and is actually the one to blame if something goes wrong. If the developer of the system is too naive about security issues it will increase the risk of posing vulnerabilities to the system and in that case it doesn’t help to say that you didn’t think that could happen. Actually these two play well together. If you expose your system to SQL injections or do not sanitize the input before storing it to the system you fail to protect your system from security issue which also exposes it to another.
A naive developer 1 stores the input to the persistence storage protecting it from SQL injections, but does nothing else to it. He assumes that the reader of the data knows what to do with it. Now naive developer 2 reads the data from persistence storage and displays it in a web page. Now he thinks that the data received from persistence storage is safe because it is their persistence storage not any third parties. Now do you see the XSS possibility here? But wait a minute that doesn’t sound right. I am smart enough not to do that. And that probably is true. But in the real world where you make real software in a real company you are up against other people and basically people are stupid. And there is almost always at least one bad apple in the basket. I know this by experience. You do your part correctly and neatly by the book, but the bad apple in the basket does not do it like that. And the fact that you probably are on a tight schedule you do not have time to look after other people. Or maybe you have given up because although you have tried to help the bad apple in the basket to get better your efforts have been useless. Once again one those issues that I know from experience. I have even been the bad apple in the basket in my past, but I hope I am not anymore. I have learned things and looked myself in the mirror. I can even identify the ravine in my development before the next plateau which I think I have recently achieved. I actually sometimes feel that I am approaching the next ravine already.
Ok back to security. Now trusting the user input can cause very unexpected issues. Might sound far fetched, but maybe it isn’t, or then again might be. Think of a software that has views that you can access based on your permissions. Now you try to access the administrator console, but you do not have the permission to do that. But the UI part of the application allows you to do things like embedding view into another view. Now in the naive approach you have tight security checks on the mechanism that loads the views through the normal path. But what if naive developer 1 and 2 have made the decision that that is enough and relies on that fact. Now you have some place where you have XSS vulnerability so that you just display the user input as is, for example when some error occurs. Now the naive developers are fine with what they have done, but they have not thought what the attacker might do. Ok the next part is part of the applications problem and part of the UI frameworks problem. The attacker causes an error which display his input. Now his input actually send AJAX call to fetch the content of some view and embeds it to the current view. The naive developers have not thought of this and the framework loads the content of the view trough insecure path. Now can you guess what view the attacker would embed into the current view through this security hole? If you guessed login view then you probably have read enough and can continue to find new funny cat videos from youtube. Well ok the attacker might embed login or personal settings or about view while sniffing out how the AJAX call would work.
Another example could also sound quite far fetched, but it isn’t and I have come across something that was very close to this. This is an Java example. And before I continue I can say that people do this sort of mistakes, inexperienced and even experienced programmers. Now think that the software would have this cool feature that you could extend the class path from where the classes are loaded just by modifying the persistence storage. You just add row to the persistence storage to inform what jar should be loaded and be accessible for the class loader. Nice cool feature yeah I know. Now another feature to display some handlers, for example in a tree on the UI, would be controlled with persistence storage. For example it could set the order of items to be displayed trough the persistence storage. Nice feature again you might think. And then use fully qualified class name for the items to be loaded and load them with Class.forName. Instead of using annotations. Like annotating the items that should be available to the UI, give them some id and control the order and visibility and so on through the persistence storage. No you have to do it using the cool features. Now I know this much that the application is not the only target of an attacker, but the persistence storage is too. Now in this scenario if the attacker would gain access to the persistence storage he could do quite a lot of tricks. For example add custom jar to the class path extending feature so the application would load the attackers jar. Now modify the fully qualified class names so that the attackers class gets loaded. Now a smart attacker would make his class behave in away that it would not affect the normal behaviour of the software. This would make it more difficult to detect that the system has been compromised and an attacker is doing his evil work. Taking it step towards the worse the class that attacker could change into his own would be some login component. Now the attackers component would send the user name and password into his server and the would continue as normal. Some attacker might even do so that his evil components are there for relatively short period of time and then everything would be restored to normal. This would further difficult the detection of the breach. Now the attacker would have some set of user credentials and he could use them as he wishes.
These both examples might be far fetched, but none of the less I think they are possible and I base my opinions on things I have seen, learned and experienced. Of course both of these example have places that when one of the points of vulnerability is blocked the whole idea would become impossible, but then again it might also open up new vulnerabilities to the system. As I mentioned in the beginning I am no security expert.
But how can I protect against attackers if I do not know how they do the things they do? Well maybe I shouldn’t do anything about it. Maybe someone else does. Or maybe not. As I would see it I think it is quite essential that you know the basic concept and idea behind the attacks and to know how to protect against some of the attacks. It does not matter if you can’t do the attack yourself, but it is very important that you understand what causes the security holes and to know how they could be possibly fixed. Once you get the hang of it maybe you start to half automatically write code that is more secure and the time it takes to hack into your system will become much longer.
You probably can’t write a system that is 100% secure from attackers. They are always at least one step ahead of you. And these “criminals” are not criminals in the sense the tv and media probably have made you perceive them. They are very smart and educated people and one might sit next to you right now without you knowing it. Some of them does do it for the money and do it with the intention to cause harm, but that is only part of them, only one side of the coin. Some of them do it for the fun of it. They do it because can. They do it because they want to test their limits. No matter what their intention is they are doing it right at this moment. And they are smart and they will always stay one step ahead of you. And they will be hundred steps ahead of you if you stay naive and do not care about security, rely on the fact that someone else will do it for you or that no one is trying to hack your system.
Google is very good place to start learning. Also OWASP can be a great resource specially if you do web stuff. You do not need to know how someone executes buffer overflow, but you should know how to protect against it. That is main point that some coders might miss. Read and learn and change your ways of working. No matter how you see it I can tell you that you do have points where you need to change the way you do things and develop towards the better. Even if you are the greatest of all in the whole universe and all existence you can still improve yourself.
This post is probably very narrow viewed on the aspect, but as I mentioned I am not a security expert. The idea is to let out some personal thoughts and hopefully get someone going.