Building a secure web application has multiple layers to it. In previous posts I’ve spoken about some design concepts relating to building a secure container for your app, and hinted that some of the same concepts could be used for building VMs as well.
You also need to build secure apps. OWASP is a great way to help get started on that. I’m not going to spend much time on this blog talking about application builds beyond some generics because I’m not really a webdev. When I wrote Java we didn’t have modern IDEs, tree structures, “factories” and the like, and I never kept up with that. Other people can go on about specifics a lot better than me ;-)
However a strong OS base and a strong app doesn’t mean much if your
web server is weak. An important step is using SSL TLS for your
communication channel.
TLS (“Transport Layer Security”) is the successor to SSL (“Secure Socket Layer”). SSL was created by Netscape in the mid 90s (I remember installing “Netscape Commerce Server” in 1996). When you hear people talk about SSL and TLS they pretty much use the terms interchangeably. You can think of it as a progression SSL2, SSL3, TLS1.0, TLS1.1, TLS1.2 with each version better than the previous.
Why use TLS at all? Isn’t this just paranoia? Unfortunately not; if you are on a mobile network or using a WiFi hotspot then the network, itself, may insert adverts into the browser; Verizon have added tracking cookies on their mobile network.
By using TLS you are helping to prevent this, and so give your users the site you want them to see, untampered by third party injected adverts. It also helps protect your users from malware that has hit major Ad networks.
Now, obviously, any login that takes credentials (username/password/whatever) should be over TLS to stop the password being passed in plain text over the network. But what isn’t necessarily so obvious to people is that the form that people type into should also be TLS enabled. Why? Because otherwise an attacker could modify the form; as far as the user is concerned they’re entering the data into their normal login screen but the bad guy now takes a copy and then logs them in, as normal. Oops!
What’s even harder for some people to grasp is that any protected page should also be TLS enabled. A typical login process may require you to enter your details into a form, submit these details. If you’ve entered the right data then the server will send back a cookie. This cookie is a token that the rest of the site actually uses to verify you have an authenticated session. If the site is over HTTP then this cookie is passed in plain text and can be stolen. This is a form of session hijacking.
So we have some important use cases:
- Prevent network advert injection (and risking malware injection)
- Create secure login pages
- Login submission pages
- Any protected page
Between them all this should be screaming “use TLS everywhere!”. Every page should be via TLS and not by HTTP.
With the advent of Lets Encrypt, allowing for free automatable certificate granting, even a lowly blog like this can be TLS enabled.
This blog is served over https for these reasons; there’s no confidential information, no passwords, no secure data… but I don’t want my content hijacked by network providers. I don’t want my (counts on fingers) 5 readers to risk malware infection because they wanted to read my stuff.
There are some “gotchas” with TLS (make sure you’ve disabled older protocols, weak ciphers, ensure users can’t be downgraded to non-TLS sites, etc) which I’ll get into in a later post. That’ll be more “hands on” and describe how to configure Apache in order to get an A+ SSL rating.