Your SaaS app is an attack target
by Alex Yumashev ·
Jan 16 2017
I'm really pissed.
I just spent a week fighting some spam bots that were registering fake trial accounts in my app. Tens of thousands or trial signups.
I tried blocking their IP-subnets, but they started using TOR. I blocked the TOR exit nodes - they switched to VPNs. Etc.
Your SaaS will get attacked
Once your app gets big (well, not "big" big, let's say "relatively recognizable") you will be attacked. This is just a question of time. Don't be fooled by that "who on earth would be interested in hacking a small bootstrapped app like mine" mantra. You're right. No one. No one is interested. They just need some random service to test their new scripts against. It's not about you.
Kids will run macros, bots, scripts, test your server for known holes, they will even use real people from cheap-labor countries to register thousands of fake trial accounts, abuse your app, XSS your app, DDoS your app, etc.
This sucks. Even if no data was lost and even if your server has handled the stress well... Still. Your AB-test results will get distorted. Your metrics will be ruined. Your conversion rates will go crazy. And you will spend hours trying to figure out why on earth did your trial-2-customer rate just dropped to 0.1%...
Email-based apps are at most risk
If your app is based around email - for example, it's an email marketing app, a helpdesk software app, a CRM/Sales app, a project-management app, or just a community/social service where people exchange comments via email - ANY app that has some sort of inbound/outbound email bridge - your app is at most risk. Attackers will send tens of thousands of emails to your app's inbox, will DDoS your MX/SMTP server, use fake relays to spoof "gmail/aol/yahoo" addresses and bomb you with crap. They will then spoof YOUR domain mailbox to spam other apps.
Example abuse scenario: register a trial account - add a user into the app - send a spam email to that user.
What the f do I do?
Here's some useful stuff
- Validate email-addresses on your signup page - and by "validate" I don't mean just the format. First - the format. Then validate the MX servers. Then actually connect to the freaking MX server on port 25 and send
RCPT TO <firstname.lastname@example.org> If the server says "OK" - everything is good, disconnect without sending an email, and proceed. If there's an error - don't register the trial. Otherwise it will ruin your metrics and AB-tests.
- Block TOR exit nodes - if you're a B2B app, you won't lose any sales, probably not even in B2C (not sure). TOR exit nodes are used for hacking a lot. There's a simple method to check if an IP address is a tor-node, just run a special DNS query... Google for "127.0.0.2 detect tor" to find out more.
- Tune your inbound email server - use a strict SPF policy (email coming from an IP that is not permitted for this domain? block then ban). Use rate limits (like, "not more than X emails per minute per address", set up throttling - i.e. "slow down" abusive clients)
- Use a CDN with a web-firewall, like Cloudflare or Incapsula. They help a lot. They're priced around $20/30 month but you save a lot more on your AWS traffic bills, so it's basically free. AND you get their automatic protection against suspicious activity and known attacks. They have gathered comprehensive statistics that "rates" IP-addresses and subnets on how risky they are.
- Protect your app from "cross-instance" hacking - like, when executing
DeleteItem.php?ItemID=321 make sure that "item 321" actually belongs to the current user. Of course, not needed if you spawn a new DB for every new cusomer, but that's rarely the case
- Try to make the app unabusable - that's a tough one. But the most effective one. Instead of protecting the app from the outside, make it useless for an abuser from the inside. Like, limit the number of users one can import from CSV. Or limit the number of inbound emails per minute for trial accounts. Or make a trial-account inactive, if no one has ever logged in into it. Etc.
- Ask white-hat hackers and "security researchers" for their realname and address when someone starts blackmailing you with "I found a hole in your app" emails, asking for a reward. The best response to blackmail is: "sure, we'll send you the money, please provide a formal invoice with your real name, address and bank-account #." You won't hear from them again. If they do provide one - you have their location... And if he/she continues to blackmail you - hire a local lawyer on a freelancer-lawyer site to send cease-desist/subpoena ($100-200 tops). This will scare them away. But if they actually report a real security hole - pay them and don't be a dick.
- Back up needless to say. Tip to AWS-users: backing up databases or files exhausts the servers i/o performance, so back up "from the outside" using EBS snapshots. They have no effect on performance and even use a separate network interface. The snapshots are smart enough to make "diffed" backups so they're ridiculously fast (100gb drive in under 10 seconds). API calls are free, so you can back up, like, every 1 minute, who cares. Clean them up once in a while to save $$$.
P.S. I have just been interviewed by Toss C3 on the latest SaaS challenges, see here