Checklist for Securing your home-grown IT applications

A software application is a program or multiple programs that help end-users. Most applications use network resources, database resources, storage, and other cloud resources, to function. This connectedness is vital to keep in mind, not only how your end user may interact with the application, but also how vulnerable the application may be to malicious actors. One may use several different methods to protect the application, but a determined attacker with sufficient resources may access your application. So, how can we secure your home-grown IT applications?

The Essentials

Before giving access to others, secure the application by locking down its network ports and IP ranges, so that only intended users can access it. If you have a well-defined user group, use a VPN. Locking down access makes sure that others cannot find your application (except developers) until it is ready for end users. Always encourage multifactor authentication and the use of strong passwords.

Once you are ready to allow access to end users, also remember to encourage them to use strong passwords and multifactor authentication. It would be best if you also used a logging tool in the application, to track the various activities (such as login attempts). This allows you to block suspicious IPS and monitor other activities outside the norm.

Taking a deeper look

• If you need random numbers, obtain them from a secure/cryptographic random number generator. Humans are inherently bad at coming up with random numbers.
• For every action or retrieval of data, always check access rights.
• Avoid unnecessary file uploads.
• Ensure that files uploaded by the user are not interpreted as script files by the webserver. You can do this by checking the file extension (or whatever means your web server uses to identify script files).
• Ensure that files cannot be uploaded to unintended directories (directory traversal).
• Use prepared statements to access the database.
• Use stored procedures to access the appropriate language/library methods or prepared statements.
• Always ensure the DB login used by the application has only the rights that are needed.
• Escape anything that is not a constant before including it in a response as close to the output as possible (i.e. right in the line containing the “echo” or “print” call)
• If not possible (e.g. when building a larger HTML block), escape when building and indicate the fact that the variable content is pre-escaped and the expected context in the name
• Avoid XML if possible.
• When you do have to use XML, use well-tested, high-quality libraries, and pay close attention to the documentation. Know your library – some libraries have functions that allow you to bypass escaping without knowing it.
• If you parse (read) XML, ensure your parser does not attempt to load external references (e.g. entities and DTDs).
• For other internal representations of data, make sure correct escaping or filtering is applied. Try to use well-tested, high-quality libraries if available, even if it seems to be more difficult.
• If escaping is done manually, ensure that it handles null bytes, unexpected charsets, and invalid UTF-8 characters to name a few, in a secure manner.
• Ensure proper access control to the API.
• Do not forget that you need to correctly escape all output to prevent XSS attacks. Data formats like XML require special consideration, and that protection against Cross-site request forgery (CSRF).
• Use standard data formats like JSON with proven libraries, and use them correctly. This will probably take care of all your escaping needs.
• Thoroughly filter/escape any untrusted content.
• If the allowed character set for certain input fields is limited, check that the input is valid before using it.
• If in doubt about a certain kind of data (e.g. server variable), treat it as untrusted.
• Data coming from HTTP headers is untrusted
  • Referer
  • X-Forwarded-For
  • Cookies
  • Server name (!)
• All POST and GET data is untrusted, including non-user-modifiable input fields like select.
• For applications with high-security requirements where you expect users to use outdated browsers with JavaScript disabled, consider requiring users of older browsers to enable JavaScript.

Understanding your use case

Not all home-grown IT applications are built the same or for the same functionality. By understanding what your tool needs to do, who will be accessing it, and how, you can create a security plan that best fits the application.

Did you enjoy this content? Follow our linkedin page!