The most common software security mistakes
Through my humble experience with software development I’ve seen developers making fetal security mistakes without even feeling that they are doing something wrong. So I’ve decided to gather these common mistakes in a list so it would be easier to avoid. Through this article I will give examples regardless to the used technology but the concepts applies to all technologies. So here we go
1. Don’t hide confidential information within your code: whatever you do don’t rely on hiding information within your code because as long your code is distributed to the client then the client might do with it as s/he wishes, which includes disassembling or decompiling your code and obtaining your confidential information. The kind of confidential information that you shouldn’t hide within your code might include but is not limited to passwords, user names, connections strings, IP addresses, domain names, symmetric encryption algorithms and of course symmetric encryption keys. And of course don’t rely on obfuscation.
2. Don’t forget to validate user input: sounds obvious but most developers think that user input is only limited to the user controls like text boxes and submit buttons but that is not true. User input might include but not limited to server requests, browser cookies, query strings and post requests. If you are expecting a zip code entered by the user then the user won’t need special characters like (!@#$%^&*()”’;:<>) so your application must not accept them. If the user will send you a request with an integer id in the query string then you don’t need negative values so your application must not accept them. SQL injection attacks and privileges escalations might happen through cookies if you don’t validate its content properly before processing it.
3. Don’t validate input at the client side: for example in web applications don’t validate user input using java script because the user might disable java script in his/her browser. In case of windows applications the user might be able to reverse engineer the application and reverse the validation algorithm to pass the unwanted input.
4. Don’t send confidential information to the client side: if you send any confidential information like network credentials to the client side then the user might be able to intercept it using any means like packet sniffing and analyze it to use it to access your resources unauthorized.
5. Don’t send user confidential data on a network without encryption: if you are sending your user credentials or any other critical data on any sort of network you better encrypt the whole connection so no one would be able to intercept the connection and extract the confidential information from it. For web applications SSL would be sufficient for non critical applications.
6. Don’t send data to host without confirming it’s the legitimate host: for example don’t authenticate on a server without confirming it’s the legitimate one because it might be just a trap to gather your users’ credentials. Basically this is easily done with the use of Active Directory as a 3rd party to authenticate both parties and confirm for each one that the other party is the legitimate one.
7. Don’t save any confidential information at the client side: if you saved user passwords on his/her machine and it got compromised then the attacker would obtain the user passwords with ease, so you should always encrypt any confidential data when saving it at the client side to avoid this from happening.
8. Don’t be selfish and protect your user not only your system: most developers think always that the users are always the bad guys whom are trying to penetrate and bring down the system but it’s rarely when you find developers that think of users as victims whom might get attacked with the use of there system. XSS attacks proves this.
9. Don’t be optimistic: don’t remove security validations because the current part is only accessed by admins, the admin account maybe highjacked and used to control the whole system that is running your application.
10. Be paranoid: always think the worst. The more your system is critical and you want it to be secure the more you must be paranoid. Always plan for the worst, for example consider if your servers got compromised so how are you going to protect your users confidential data? What if your servers got flooded or your connections were down? What if your users got hacked and there credentials were stolen? What if your network was penetrated and what if your traffic was filtered? You must always ask your self the worst questions while designing the security schemes of your application.
Thanks for reading and I wish you have enjoyed this article. I would like to hear your opinions so your comments and feedbacks would be really appreciated.
