Web App Security Part 1: An Introduction

Dan Ivovich -

We hear about it all the time, another company is infiltrated and data is stolen. Many times these are complex social engineering attacks on the employees of a company or malware on desktops that enters via email or document sharing. While these attack methods are serious and need to be addressed, don't forget about your web applications.

Over the next three weeks, in this 3-post series on web application security, I'll be discussing the basics (this post), I'll talk about understanding your risk, additional security, and what provides a false sense of security, and then I'll share with you the ways in which we here at SmartLogic make security part of our everyday work.

Important Vocabulary

  • Client - The browser (Chrome, Firefox, Safari, Internet Explorer, etc) or your own mobile app for iOS or Android. This will interact with your Application.
  • Application - Your server side code with which your clients communicate.
  • Developers - The people you employ, either directly or indirectly, to write your application and client code.

Gimmes

These are the obvious security concerns that are mostly solved by the frameworks and tools developers use. But that doesn't mean there can't be mistakes, either by the developers of the framework or the developers of your application. It remains important for your developers to understand these items and be aware of how they are solved by the framework they are using.

  • Cross Site Scripting - This would allow another application (a malicious one) to execute scripts via the client while a user is using your system, stealing data or manipulating data without the user's consent.
  • Cross Site Request Forgery - This would allow another application (a malicious one) to invoke actions on behalf of your user without their consent, while your user is using the other application.
  • Buffer Overruns - This is the original gold standard of software bugs. This is how many common viruses and worms gain access to desktop computers. Often these are not considered relevant to web-based applications or the modern languages they are written in, but they are always something to be aware of. Be sure the tools your application uses are up-to-date.
  • SQL Injection - This is a fancy way of saying that it could be possible to ask your application database to save something, but that something contains other code that the database shouldn't run, but will run if the original request wasn't formatted correctly. Most frameworks handle this, but it is very important for an application's developers to understand this problem and be sure they use the tools correctly.

Obvious Problems

The items listed below shouldn't happen, but sometimes they do, so we make sure to look for them whenever we evaluate an existing codebase a client brings to us.

  • Invent-Your-Own Security - Most common security problems are solved and solved well. Your application is probably not unique enough to require something different. Use common libraries and tools; don't invent your own. There will be a mistake.
  • Strange Password Requirements - Any limit on password length is a huge red flag. Modern password storage methods should never require an application to limit the length of a password.
  • Security via "Secrets" - Just because you won't publish some secret that your application uses on your blog doesn't mean it will stay secret. Anything secret must stay on the server.
  • Misuse of Cookies - Cookies are useful for saving state and making life much easier for your application's users. It is important that they be:
    • Encrypted
    • Not blindly trusted
    • Used only for simple session state
  • Form Manipulation Issues - This one is hard to find but important for your developers to be thinking about. Make sure that your users can't manipulate the page in such a way that they can change what the application does with their request to do something they don't have permission to do. A common example is letting them register as an administrative user by allowing a flag to be sent with a form to set an administrative permission, despite it not being available in the original form.
  • Not Using HTTPS - At this point, you absolutely must be using HTTPS. If you don't need to prove who your business is to the user, then you can do this for free. If you do want to authenticate that your business is the owner of the application, then it has a cost, but you should still consider it required.
  • Password Recovery - Can a system tell you what your password is? Nothing should know your password but you! If a system can email you your password if you forget it, then it isn't a secure system. However, email can be reliably used for password resets: use a one-time usable link that will expire if you don't use it quickly.
  • Dependencies Out-of-Date - It is extremely unlikely that your development team will write 100% of the code in your application. Leveraging open source frameworks and libraries--or even closed source options--will add reliable and necessary code to your application. These frameworks and libraries are not without flaws, and it is important that your team keep the dependencies updated so the latest fixes are a part of your application.

It's Not Rocket Science

The items we've reviewed here aren't hugely complex, but they do require constant attention. The fact is that security and technology are constantly moving, so you must always be vigilant in your understanding and dedication to always be improving. Keeping these items in mind will help greatly. Don't try and outsmart the "bad guys" with complex security; work within the well-known parameters of these problems, and put in the effort to be educated and up-to-date on these topics.

Next week we'll review the real risks you may face and some ways to layer on extra security for you and your users.