Building for the bad guys
Often times, while still in discussion on how to go about a client’s project, they always lay emphasis on the security of the app. They would recommend you install the “strongest bad-guys-fighting-software”, and I’m always quick to respond that “security is a process.” If they fail to do little on their part to ensure the security of the application, irrespective of whatever security plugin that was installed, it could be compromised.
It would be of no use of installing cool security software and neglect some simple security measure like using a dumb password or even storing passwords in plain text.
Before I proceed, I would like to define who a bad guy is in the context of this article. A bad guy is simply someone who looks for the slightest means to compromise your application through any loopholes found in the system.
From the get-go in software development, we plan for the worst and expect it. We assume our attacker is smarter than we are, not leaving any chances for a weak link in the chain.
So, I will be discussing a few simple ways a developer could avoid being caught in the net of bad hackers.
Input field sanitization
This is obvious and most common means of creating an avenue for attack. As a matter of fact, expect the worst wherever there is a form field in your application, a possible outcome is one trying to run JavaScript on your page. That is what’s called an XSS, cross-site scripting.
So I’m saying basically, treat anyone having access to any of your input fields as a suspect. Anyone with bad intention could put malicious code in those inputs and the rest would be history if the developer of such an app is not security conscious.
There are tons of great libraries one could leverage on to sanitize HTML, for instance, https://github.com/cure53/DOMPurify
However, all I have mentioned about input sanitization is for the frontend of the development. It is also good to double check it on the server side too because JavaScript could be manipulated on the frontend.
Authentication
Authentication is the process of determining whether someone or something is, in fact, who or what it declares itself to be.
During authentication, credentials provided by the user and are compared to those on file in a database or any other means of storage. If the credentials match then the authenticated user is authorized to use the restricted resources. This leads to my next point; Authorization.
Authorization
It is granting access to authenticated users. The access could be in different roles (privileges and preferences). The privileges and preferences granted for the authorized account depend on the roles’ permissions. The settings defined for all these environment variables are set by an administrator.
Software updates
One needs to be alert and stay up to date with the latest security patches for the libraries or frameworks they are using.
With one command, one could update any third party plugin they have installed. This is where the use of package managers shines. With simple commands such as npm update for Node packages and composer update for PHP packages etc. one would have any outdated third-party library updated.
Hashing algorithms
Simply put, A hash algorithm is a function that converts a data string into a numeric string output of fixed length. Hackers today have access to powerful inexpensive computing resources that can be used to conduct high-speed password guessing. Salting is the coding technique needed to help defeat such attacks and de-duplication of password hashes since hashing algorithm like MD5 alone is not enough.
Conclusion
All the points I have mentioned, are just the basic way one could adhere to in order to avoid stories that touch. There are pretty much points I did not cover. I would be expecting your contributions on any issue not discussed here.
This article first appeared here
