Application security is often overlooked. Perhaps this is due to a lack of understanding, or perhaps a focus on features and aesthetics is more alluring for developers. But given the inherent risks involved, I proclaim to you, “Overlook no further!” A modest data breach can render valuable data vulnerable, and can cripple customer trust in your application. The following article based on advice from Scott Arciszewski of the Paragon Initiative should provide you with a broad understanding towards general methods used to breach security and some tips on how to remedy them.
- Separate Data From Instructions: Or, in other words, prevent data from corrupting instructions. Hackers use methods like stack and heap overflows or SQL, LADP, Xpath, or Command injections whereby entered data can commandeer or overwrite your application. These approaches cover the majority of cyber attacks, so knowing how to protect against these in respect to your specific application is paramount.
- Proper Application Logic: By having sound application logic you can prevent your application from blindly accepting non-validated data, users skipping steps in a given process, or allowing steps to proceed without validating previous step outcomes. By making sure input validation occurs, or by incorporating sever to server API integration, you can protect your application from a broad range of attacks.
- Understand Your Environment: One conceptual mistake developers make is thinking that their application exists in a closed system. In reality, your application relies on a variety of outside elements such as operating systems, hardware components, network connectivity, Web browsers, third-party libraries, etc. Close any security gaps between your application and its environment. This includes keeping your software updated.
- Leave Cryptology to the Experts: Cryptology is hard, and unless you are an expert, leave it alone. Poor cryptology can leave applications vulnerable to a plethora of cyber attacks such as remote timing attacks. If you choose to write your own cryptology do so at your own risk; the worst part is: you won’t your code is bad until it’s too late.