Web Development Tools You Should be Using to Protect Your Data

- Greg Gray, BOHH Senior Software Engineer

Someone recently asked me what web development tools I use to protect data. After some thought, I realized there that tools aren’t really the biggest part of the data security picture - data is protected by secure design practices and the processes that support them.

At the core is your server’s software. Keeping it up-to-date should be a primary concern. Bugs and security holes can quickly compromise your systems if you don’t keep the software patched with the latest fixes. If you are maintaining your own server network environment, you also need to pay attention to firmware updates for your network infrastructure, as exemplified by the recently revealed exploits (e.g., Slingshot) that can compromise your network routers.

Managing the configuration of your servers is also important. Restricting incoming traffic to just a few ports is a common practice, but it’s also important that other software, such as the database is also protected. Data breaches are regularly reported where the exploit is using the default root password on a system exposed to the Internet. Some database installation processes will suggest the changing of root passwords and will initially limit access to the network, but it’s up to you to ensure that these safeguards are maintained and not compromised for convenience. An even better practice is to not expose the database to the Internet at all, relying instead on application server access via internal network paths.

Additionally, all web servers should be configured with SSL certificates. Sorry, but the days of worrying about the loss of the extra CPU cycles to process secure requests are over. HTTP (insecure) access should be limited to allowing a redirect to the HTTPS (secure) processes. Browsers will soon be warning users when they are accessing sites that aren’t protected by SSL certificates. Lock them down and keep the SSL software up-to-date.

Most of the responsibility for data security is in the hands of the developer. I am constantly amazed that there continues to be reports of SQL Injection exploits when the simple practice of parameterized queries can solve the problem. Many databases can now be encrypted or use custom encryption routines on specific tables and fields. Password fields need to be stored with one-way hashing functions, preferably using per-user salts.

But encrypted databases won’t protect against an application that has been compromised. The application will, by design, have the mechanisms or permissions to decrypt the data. The application should only be allowed to do the tasks on the database that are required. For example, most end-user applications probably don’t need to drop tables or create scripts. If they don’t need a permission, they shouldn’t have it. If the app can’t do a particular function on the data, neither can someone attacking the data via the app.

Almost everything running at the web browser has the potential to be compromised. Those wonderful browser-based user experiences come at a cost by delivering the software to the browser in a human-readable form, ready for exploitation. Make sure your code doesn’t contain account names and passwords, or any other information that can be used to compromise your back-end server.

Form input validation should take place at both the browser and the server. Browser-based validation speeds the response to the user (a convenience) but server-based validation is needed to ensure the browser’s process hasn’t be compromised (a necessity).

Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) exploits have many attack vectors but mitigation is possible with the appropriate server checks in place. XSS exploits can occur anywhere your web application uses input from a browser within the output it generates without validating or encoding it. You must validate and escape/encode all input that comes from the wild. CSRF prevention begins with checking standard headers to verify that the request is “same origin” and using CSRF tokens. Developers will often disable the “same origin” checks during testing, and sometimes they forget to turn them back on. See the Useful References from the Open Web Application Security Project (www.owasp.org) at the bottom of this post for an overview of XSS and CSRF.

At the end of the day, how do you know if your carefully crafted best practices are actually being used and providing full coverage? Code reviews by staff not involved in the project are one solution. External audits of common and uncommon exploits are another solution and might be best done by third party software and service companies. Some good examples of such services include: Netsparker, SecurityHeaders, and Xenotix.

Website security cannot be taken lightly. Breaches have operational and legal ramifications. Good security design practices and a little help from outside agents can ensure a healthy web experience for your customers and your business.

Useful References

XSS (Cross Site Scripting) Prevention Cheat Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet