Keep Thinking Like a Hacker

What happens if a hacker breaks through your app, and gets to your server? You missed one tiny thing, and now the hacker is doing whatever they want on your server… How do you stop this from turning into a catastrophic event?

When we think about web app security, we immediately think of writing secure code, but that’s only half the story. We also need to secure our servers. We need to make sure that if a hacker breaks in, we can limit the damage they cause.

So in this talk, we’re going to assume the role of a hacker who has broken through the code, and has access to the server. We’ll go from there, hacking our way around, seeing what we have access to. While at the same time, adding layers of defence (as the site owner) to try and stop an impending catastrophic breach. The goal is to keep thinking like a hacker so we can build and deploy secure apps on all levels.

Presented At

Security Checklist For Securing Your Server

  1. Always use a different database and user for each app.
    This prevents someone who gains access to the database in one of your apps from accessing your other apps.
  2. Scatter Canary Tokens in your configuration files and on your server.
    Canary Tokens are API keys and interesting sounding files that will send you an alert whenever someone hacker tries to use/open them. This gives you a fantastic early warning system if someone is snooping around your apps/servers.
  3. Always provision apps in their own user accounts on your servers.
    This prevents someone who gains access to the files or command line in one of your apps from accessing your other apps too.
    This is done in Laravel Forge through the “Add Website Isolation” option when creating a new site.
  4. Never disable the sudo user password!
    If someone gains access to your account with password-less sudo access, they’ll have full root powers. If this user has any apps running from it, anyone breaking into your apps can become root and take over your server.
  5. Be careful trusting internal networks your web-facing servers have access to.
    If someone can compromise your app, they can access the internal network and potentially exploit your internal services.
  6. Always use Deploy Keys when deploying code, rather than adding the server SSH key into your source control user.
    If the user SSH key allows access to all repositories in your account, an attacker can check out and modify any of your code.
    If this code is private, you could lose valuable Intellectual Property.
    If this code is a public package with thousands of installs, malware could be added to infect your user’s apps… 
    If that were something on the scale of laravel/framework, the damage some injected malicious code could cause is immense!