Xebia Essentials | Realisation - Develop for Security
I started my career as an enterprise software developer for a world-leading banking software product — Finacle E-Banking. Since Finacle (FEBA) is a system that will be the entry point for customers, it has to be very secure.
I have worked with multiple world-class banking products all of them had security as the utmost important feature to have.
But there is a problem in my previous statement, that many people fail to observe. Security is not a feature. It is not possible to invest a couple of sprints to make an insecure product secure. To get a secure product, security has to be thought from the very beginning.
An application is considered secure when the users of the application can use it with the intended use only. A secure application takes care of releasing information to intended users only, any unauthorized access to information makes the application less secure.
This means every secure application needs a user system and access control system, and that can be developed in a few sprints and applied to any system to make it secure. Isn’t it contradictory to what I said sometime back?
To answer that, let me share a real example.
Secure Requirements
Our product was ready, and a few customers had purchased the same. During customization, there was a requirement that during login, the user should be given 3 attempts before he gets locked when trying with an invalid password.
The UX suggested adding a counter in the error message so that the user is aware of the number of attempts left.
e.g. “That’s an invalid password, you have 2 attempts left before you get locked out”
So far so good. We developed that happily making the application more secure and released the software for security checks. And guess what, it failed security tests.
What we missed was looking at the bigger picture. We did not think like a hacker. Imagine, if a hacker wants to know the available usernames in the system (without having such permission), he just needs to try logging in with different usernames.
If he tries to login with invalid username and invalid password, he would see something like: “Your credentials are invalid”
If he tries to login with a valid username and invalid password, he would see something like “That’s an invalid password, you have 2 attempts left before you get locked out”
The hacker just needs to brute force different usernames, and he can know all the valid usernames in the system. This is a breach of security. The user (hacker) gets to know valid usernames of the system, which he is not authorized for.
Solution: Think thoroughly about security when defining requirements for the software.
Secure Development
Defining requirements is not the only time that you need to worry about, it is just the beginning. When writing software, a developer must be aware of validations, and who is allowed to do what.
Every method that is written, must validate all the inputs. All numbers must be checked to lie in the expected range, all strings must be validated to contain only the valid characters.
I would like to drill down more on my last line because it can be easily misinterpreted. Let’s say the requirement is defined as “A password must not contain SQL injection characters” because of obvious reasons.
A normal developer would develop the requirements something like the following
public boolean validatePassword(String password) {if(password.contains(“<”) ||password.contains(“;”)…){return false;}return true;}
He understands the requirements and implements them as dictated.
However, a developer must work as a second line of defense and should write the reverse conditions. The valid character set is almost always smaller than the invalid character set. When we take multi-linguality in pictures, there are uncountable characters that a user can input, and we never know which characters can be used to hack our secure system. Hence it is always better to validate with the characters that we want to allow, rather than validating the characters we don’t want.
And pattern matching is the best solution to achieve it.
Another amusing example that I remember focuses on another anti-pattern in secure programming called “security through obscurity”.
During security testing, one issue was assigned to me “The URL encryption logic is not correct, it is repeating a few characters in some pages.”
I was young, having never worked on encryption logic before I had to get this issue resolved.
I started with reading the encryption logic, (it was in an obfuscated jar). This was boring, and I did not understand anything.
Then I contacted the tester and tried to understand the problem again, and he showed me the detailed test reports, which clearly showed a few not-so-random characters repeating in the URL. The URL looked something like the one below
www.example.com/service.do?enc=abRdafhj$dja@fhdfjh&hfkAvbs=jja^kcbakOut of the blue, I decided to search for the repeated not-so-random characters and things became clear.
There was a developer, who didn’t know how to encrypt the URL parameters. But he required a value to be available in URL. The quick fix: simply name the variable and value with some random characters, without actually encrypting it.
Let’s observe the URL again
www.example.com/service.do?enc = abRdafhj$dja@fhdfjh&hfkAvbs = jja^kcbak
This clever “Jugaad” went unnoticed by all humans and was only detected by advanced security tools.
Unfortunately, hackers have access to these tools as well and hence such “cool” tricks might help you in getting pass through human QAs, but will not save your application from getting hacked.
Testing for Security
The previous example also emphasizes a need for extensive security testing. Before the application goes live, it must be passed through white hat hackers or security testers so that any security flaws can be determined and fixed before going to production.
Continuous Monitoring
Each progressing day, technology is changing. We are learning from our mistakes and writing new software. new researches are revealing security flaws in existing software dependencies, and new versions of these dependencies are being released.
To keep our software secure, we need to continuously monitor all the dependencies that we are using. And as soon as a new vulnerability is revealed in one of our dependencies, we should replace it with the fix.
Strong analytics is required to check who is accessing what, and preventive actions should be performed when unauthorized access is detected.
This also calls for active attention to recent hacks happening surround the world. OWASP Top 10 is such a project, which brings out the latest hacks and problems behind them.
Social Engineering
While all of the above were software solutions to security, social engineering is one of the most difficult to tackle.
Most hacks happening today require some kind of social engineering to gather information. Tailgating, overhearing conversations, honey trapping, reading information from papers spread across desks is a common form of social engineering.
Hence it is required that the developers are aware of the security measures to be taken, and they must revise the concepts now and then.
Back then, we were using JSPs to write our frontend, and it was common to comment on unused code, mark the comments, and leave the developer’s name for more details.
When inappropriate tags were used (using HTML comments, instead of JSP comments) the comments and unused code, along with the developers’ names were visible in the browser’s “view source” view.
This leaked the information about the developers, the technology, and code structures used in the code and other information that can be tracked.
If you have observed, a few years back it was a common practice, to use “security questions and answers” as a way to get reminders of the password. However with the advent of social networks like Instagram and Facebook, a lot of private information is available to stalkers. Social engineering on these accounts can give hackers access to “security questions and answers” leading to passwords, or eventually full account access.
As a summary, applying security is not a job of couple of sprints, it has to be well though-through. The team must be educated to write secure software and active attention must be given to activities happening surrounding the world.
Stay Safe and Keep Coding.. Securely.
