Upping Your Web Security Game

Guy Podjarny sounds a sober warning during our festivities, and gathers some winter fuel to help secure your apps and users from the webs occasionally cruel frost. So mark his footsteps good, my friend, and tread thou in them boldly. Thou shalt find the hackers rage freeze thy site less coldly.

When I started working in web security fifteen years ago, web development looked very different. The few non-static web applications were built using a waterfall process and shipped quarterly at best, making it possible to add security audits before every release; applications were deployed exclusively on in-house servers, allowing Info Sec to inspect their configuration and setup; and the few third-party components used came from a small set of well-known and trusted providers. And yet, even with these favourable conditions, security teams were quickly overwhelmed and called for developers to build security in.

If the web security game was hard to win before, its doomed to fail now. In todays web development, every other page is an application, accepting inputs and private data from users; software is built continuously, designed to eliminate manual gates, including security gates; infrastructure is code, with servers spawned with little effort and even less security scrutiny; and most of the code in a typical application is third-party code, pulled in through open source repositories with rarely a glance at who provided them.

Security teams, when they exist at all, cannot solve this problem. They are vastly outnumbered by developers, and cannot keep up with the applications pace of change. For us to have a shot at making the web secure, we must bring security into the core. We need to give it no less attention than that we give browser compatibility, mobile design or web page load times. More broadly, we should see security as an aspect of quality, expecting both ourselves and our peers to address it, and taking pride when we do it well.

Where To Start?

Embracing security isnt something you do overnight.

A good place to start is by reviewing things youre already doing and trying to make them more secure. Here are three concrete steps you can take to get going.

HTTPS

Threats begin when your system interacts with the outside world, which often means HTTP. As is, HTTP is painfully insecure, allowing attackers to easily steal and manipulate data going to or from the server. HTTPS adds a layer of crypto that ensures the parties know who theyre talking to, and that the information exchanged can be neither modified nor sniffed.

HTTPS is relevant to any site. If your non-HTTPS site holds opinions, reading it may get your users in trouble with employers or governments. If your users believe what you say, attackers can modify your non-HTTPS to take advantage of and abuse that trust. If you want to use new browser technologies like HTTP2 and service workers, your site will need to be HTTPS. And if you want to be discovered on the web, using HTTPS can help your Google ranking. For more details on why I think you should make the switch to HTTPS, check out this post, these slides and this video.

Using HTTPS is becoming easier and cheaper. Here are a few free tools that can help:

• Get free and easy HTTPS delivery from Cloudflare (be sure to use Full SSL!)
• Get a free and automation-friendly certificate from Lets Encrypt (now in open beta).
• Test how well your HTTPS is set up using SSLTest.

Other vendors and platforms are rapidly simplifying and reducing the cost of their HTTPS offering, as demand and importance grows.

Two-Factor Authentication

The most sensitive data is usually stored behind a login, and the authentication process is the primary gate in front of this data. Making this process secure has many aspects, including using HTTPS when accepting credentials, having a strong password policy, never storing the password, and more.

All of these are important, but the best single step to boost your authentication security is to introduce two-factor authentication (2FA). Adding 2FA usually means prompting users for an additional one-time code when logging in, which they get via SMS or a mobile app (e.g. Google Authenticator). This code is short-lived and is extremely hard for a remote attacker to guess, thus vastly reducing the risk a leaked or easily guessed password presents.

The typical algorithm for 2FA is based on an IETF standard called the time-based one-time password (TOTP) algorithm, and it isnt that hard to implement. Joel Franusic wrote a great post on implementing 2FA; modules like speakeasy make it even easier; and you can swap SMS with Google Authenticator or your own app if you prefer. If you dont want to build 2FA support yourself, you can purchase two/multi-factor authentication services from vendors such as DuoSecurity, Auth0, Clef, Hypr and others.

If implementing 2FA still feels like too much work, you can also choose to offload your entire authentication process to an OAuth-based federated login. Many companies offer this today, including Facebook, Google, Twitter, GitHub and others. These bigger players tend to do authentication well and support 2FA, but you should consider what data youre sharing with them in the process.

Tracking Known Vulnerabilities

Most of the code in a modern application was actually written by third parties, and pulled into your app as frameworks, modules and libraries. While using these components makes us much more productive, along with their functionality we also adopt their security flaws. To make things worse, some of these flaws are well-known vulnerabilities, making it easy for hackers to take advantage of them in an attack.

This is a real problem and happens on pretty much every platform. Do you develop in Java? In 2014, over 6% of Java modules downloaded from Maven had a known severe security issue, the typical Java applications containing 24 flaws. Are you coding in Node.js? Roughly 14% of npm packages carry a known vulnerability, and over 60% of dev shops find vulnerabilities in their code. 30% of Docker Hub containers include a high priority known security hole, and 60% of the top 100,000 websites use client-side libraries with known security gaps.

To find known security issues, take stock of your dependencies and match them against language-specific lists such as Snyks vulnerability DB for Node.js, rubysec for Ruby, victims-db for Python and OWASPs Dependency Check for Java. Once found, you can fix most issues by upgrading the component in question, though that may be tricky for indirect dependencies.

This process is still way too painful, which means most teams dont do it. The Snyk team and I are hoping to change that by making it as easy as possible to find, fix and monitor known vulnerabilities in your dependencies. Snyks wizard will help you find and fix these issues through guided upgrades and patches, and adding Snyks test to your continuous integration and deployment (CI/CD) will help you stay secure as your code evolves.

Note that newly disclosed vulnerabilities usually impact old code the one youre running in production. This means you have to stay alert when new vulnerabilities are disclosed, so you can fix them before attackers can exploit them. You can do so by subscribing to vulnerability lists like US-CERT, OSVDB and NVD. Snyks monitor will proactively let you know about new disclosures relevant to your code, but only for Node.js for now you can register to get updated when we expand.

Securing Yourself

In addition to making your application secure, you should make the contributors to that application secure including you. Earlier this year weve seen attackers target mobile app developers with a malicious Xcode. The real target, however, wasnt these developers, but rather the users of the apps they create. That you create. Securing your own work environment is a key part of keeping your apps secure, and your users from being compromised.

Theres no single step that will make you fully secure, but here are a few steps that can make a big impact:

1. Use 2FA on all the services related to the application, notably source control (e.g. GitHub), cloud platform (e.g. AWS), CI/CD, CDN, DNS provider and domain registrar. If an attacker compromises any one of those, they could modify or replace your entire application. Id recommend using 2FA on all your personal services too.
2. Use a password manager (e.g. 1Password, LastPass) to ensure you have a separate and complex password for each service. Some of these services will get hacked, and passwords will leak. When that happens, dont let the attackers access your other systems too.
3. Secure your workstation. Be careful what you download, lock your screen when you walk away, change default passwords on services you install, run antivirus software, etc. Malware on your machine can translate to malware in your applications.
4. Be very wary of phishing. Smart attackers use spear phishing techniques to gain access to specific systems, and can trick even security savvy users. There are even phishing scams targeting users with 2FA. Be alert to phishy emails.
5. Dont install things through curl <somewhere-on-the-web> | sudo bash, especially if the URL is on GitHub, meaning someone else controls it. Dont do it on your machines, and definitely dont do it in your CI/CD systems. Seriously.

Staying secure should be important to you personally, but its doubly important when you have privileged access to an application. Such access makes you a way to reach many more users, and therefore a more compelling target for bad actors.

A Culture of Security

Using HTTPS, enabling two-factor authentication and fixing known vulnerabilities are significant steps in building security at your core. As you implement them, remember that these are just a few steps in a longer journey.

The end goal is to embrace security as an aspect of quality, and accept we all share the responsibility of keeping ourselves and our users safe.

About the author

Guy is the CEO & Founder of Snyk.io, a Web Security company. Before that, he was the CTO of Akamais Web Performance business, following its acquisition of Blaze.io (which he co-founded). He has spent over a decade working on Web Application Security, and more specifically the first Web App Firewall (AppShield) and the market leading Web Application Security scanner (AppScan).

He is also the author of Mobitest, an open-source mobile web performance testing tool, and is on the programming committee of the Velocity conference, and wrote Responsive & Fast, a short book about RWD Performance.

More articles by Guy