7 Common Website Security Mistakes
February 9, 2015
Heartbleed: The computer bug that shook the world of the internet was the result of a coder’s mistake. So was the Internet explorer’s zero-day vulnerability. The massive effect of these bugs, especially Heartbleed was all to see…and the question arose, once again about the security protocols followed by developers. Is it mere carelessness on part of the developers? Or are we making a lot of hues and cry about something that cannot be controlled?
We are sharing with you a list of top 7 website security mistakes that if avoided by coders, can save many sleepless nights. With no ulterior intentions whatsoever, we will be calling them:
The 7 Commandments a coder should follow:
1) Trust thy fellow developers…Never!
It’s a commonly known fact that more often than not that an application is built by using proprietary code that is written by other coders or is third party software. You might want to believe that they are secure and do not contain any vulnerability and not give another thought to check them twice for security holes. And while you will spend time securing the app you built, the past vulnerabilities remain finally leaving your app exploitable.
So what developers need to do is that either they try writing code from scratch (hold on, don’t hang us yet!) or ensure that the third party software that you intend to use follow the latest guidelines as per OWASP/industry standards. If you have the source code of the third party software, it must be checked for static and dynamic analysis.
2) Thou shall forbid hard-coded passwords
You were working on the code, did some testing and with so much to do, forgot to remove the hard-coded passwords…I mean, it’s understandable, right? There is ‘n’ number of things to be done, and how big deal can it be that you forgot to remove some hard-coded passwords. You didn’t notice it, so who else will…right? Maybe no one will.
Or maybe someone might!
In 2011, a hard-coded password was found in Siemens industrial control systems by a security researcher, which could let attackers reprogram the systems with malicious commands to sabotage critical infrastructures and even lock out legitimate administrators. Hard-coding is very easy for programmers… but it is more difficult to change if it later becomes necessary. If one has used the same password across all software and is found out by malicious elements, then every customer becomes vulnerable and since it is difficult to fix, the repercussions can be long felt.
You can get your code reviewed by a fellow programmer or a team to ensure that hard-coded passwords are not present in the code.
3) Thou shall not commit adultery…and keep backdoor accounts
Do not keep backdoor administrative account openings in your codes. You might say you kept it there and forgot about it…but you cannot shake off your responsibility by saying that. You think no one will find it, but someone always does.
Eric Schmidt, the former CEO and current chairman of Google, had said: “If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.”
So if you don’t want people knowing about your backdoor entries, don’t keep them there in the first place.
Many companies are accused of keeping backdoor entries in their app. Apple is the latest to join the list and is indicted of calculatedly installing security backdoors in around 600 mn iOS devices, which could have led to the access of all the sensitive data of the user. You never know that the person who will find that hidden door will be a friend or foe and hoping that no one will take interest in your application or its security features is rather imprudent.
4) Thou shall fulfill your duty and check all inputs
Make sure that your inputs are valid. Do not trust all inputs and allow minimum privileges needed. Be very strict about what comprises a user’s name. For instance, if you expect numbers, do not input letters. Incorrect input validation can be exploited by hackers, by modifying the inputs in unexpected ways.
The other thing that you can do is to HTML-encode all input when it is used as output. Insufficient output encoding is the foundation of most injection-based attacks.
SQL injection topped the list of OWASP top 10 vulnerabilities two times in a row. It is one of the most dangerous security vulnerabilities around, with most of the recent breaches attributed to it. Do not trust inputs blindly from external sources like Web-based input. The SQL query thus submitted can be exploited to perform an action which is not desirable.
It’s understandable that coders can’t check every data input and it can be very time consuming but that is what they essentially have to do. A code acts as a door for your software, and it’s the duty of the coder, no matter how exhausting, to ensure that only valid inputs are passed in.
5) Thou shall not forsake your duty of securing your data
After covering the topic of input handling, we move to data security. SANS Institute’s list of the 25 most dangerous programming errors and OWASP Web application security problems Top 10, place securing data on 8th and 6th place respectively.
Coders should be using encryption more often than they think they should. Especially in the present times, when the user’s personal information comprises of extremely sensitive details like financial data, identity data and much more. While using encryption everywhere possible, seems such a no-brainer to us, it is still not prominently used due to the very obvious reason of it adding one more step to the whole process. It’s so much easier to find errors in plain text as opposed to encrypted, but for the same reason, encryption is necessary. We would not want our data handed in a silver plate to the hackers…and encryption prevents that from happening.
Encryption, with proper implementation, can help in keeping data secure.
6) Honor the people you build code for- do not ignore layer 8
You might take care of all the factors but still, fail because you forgot to consider the most important one…the people who will be the end users. We are not saying that coders are to be blamed here. Users have a mind of their own…you might be saying something but for them, it might mean something totally different.
What coders can do about this, you ask. A lot! Think like the end user, see if the error messages and prompts intended for users are as clear cut as you presumed they are. Do not assume that the user will always understand what you meant. Do you give them a warning message, when they are trying to change something that they are not supposed to? Most of the time, the commands that you think are self-explanatory will make no sense whatsoever to the user!
7) Thou shall build proper walls and authorize only what is deemed necessary
It is very difficult for a coder to exercise appropriate control. Too much control and the software users feel suffocated. Too less, and they land in soup…they expect you to protect them. So they want all the advantages of being in gated security, but do not want to subscribe to the security standards that come with it. Many users tend to bypass the basic security measures to such an extent, that they stick to the default credentials unless forced to change them.
And you, the coder will always be contemplating how much leash to be given to the users. If you make things hard to do, users will complain and render the software user-unfriendly…you make it easy for the user, the action reciprocates itself for the attacker.
Segregating few operations such as ones requiring financial data input can be a way out. Having a two-factor authentication here solves the purpose of not allowing hackers the chance to take advantage of lax security measures.
As an example, in an application that does payment using a credit card, are you going to store the credit card numbers in a cash or even on a server? What about the name and address associated with the credit card? CVV number? From a strict security point of view, which are the critical components here? The trade-off here is about convenience to the user as against security.
