

Ask HN: How much abuse does your web app get, how much prevention do you put in? - scootklein

I'm about to launch my first web startup and am wondering how concerned I should be about abuse -- both from account holders and the public at large.<p>Background: our app is free to sign up and upload all of your content (URL is in my profile). The pay wall comes when you want all of that content to go live and be available to your users.<p>Example Concerns:
1. An account holder can upload unlimited content, but the common use case will only be what they have (on the order of 100MB most).
2. A user could feasibly switch their billing plan unlimited number of times.
3. The RESTful interface to the content requires no authentication and isn't throttled (it does do some header checking) and links to large media files are raw, source of request is unchecked on server end.
4. DDOS, general "script kiddie" stuff, dictionary attacks on root pw to servers (i use a non-standard port)<p>Everything that can be considered "harmful" would eventually be caught (woe be to my bandwidth bill) and dealt with, but possibly not before some "damage" has been done - namely a huge distraction and time sink to find and correct the issue/perpetrator.<p>How much "abuse" does your web app take?
How aggressive are you in preventing such behaviors?
======
patio11
The amount of effort you have to spend on this varies greatly with the
attractiveness of your service to trolls, thieves, hoodlums, and the like. One
of my apps has almost total trust for users, because exploiting the app itself
gets nothing that someone on 4chan would enjoy. Another of my apps makes phone
calls, and I put non-trivial effort into securing that from abuse.

You're in a content business. Bad news: technically inclined people enjoy
stealing content. You probably have to plan on them using your service to
facilitate theft of content unrelated to you. "Unlimited uploads" sounds like
something that will draw this type of pathological user like flies to honey.

With regards to security: standard best practices are pretty adequate for most
of us in non-regulated industries. I don't know why you'd let root be able to
log in, but that is probably minor.

------
justin_vanw
1\. Very little. 2\. Very little.

I've was the primary developer on an at-one-time popular site, and have been
working at web startups for awhile. I don't recall a single malicious user on
either (there were quite a few stupid users or users angry at me, but not
messing with the site). Until you get big, people won't mess with you. Until
you get big, you have little to lose if they randomly do mess with you.
Writing robust secure apps is harder. Unless you deal with money or credit
cards, just figure it out when it is actually a problem. (Protip: you will
probably never be big enough for it to be a problem. I would spend all your
effort figuring out how to get big, and then welcoming malicious users and
script kiddies as one of the trimmings of success).

------
nitrogen
I've had spammers looking for open e-mail relays on a contact form on a
personal site that gets one or two legitimate visits a month. Small sites can
be an ideal target for spammers, as they're less likely to have time and money
for intensive security analysis.

Just use common sense measures to avoid things like SQL, JavaScript, or HTML
injection and external abuse (such as from spammers, pirates, or script
kiddies looking for an untainted host for their malware), have a DMCA
procedure in place in case a user does find a way to host illegal content on
your site and you're in the USA, and deal with any other issues as they
happen.

------
Rust
1) I would definitely implement a cap here - but something reasonably high...
maybe 2GB is free, pay for more?

2) An app I wrote allowed this. We put a limit in that prevented more than 4
changes to occur within 10 minutes. If the user attempted a 5th change, they
would get a message asking them to wait a few minutes.

3) Implementing a public/private key here is relatively trivial - any reason
not to do it?

4) Hardware firewalls will help with a large portion of this. I had a server
that would get brought to it's knees about twice a week from that fracking SQL
worm. Added a hardware firewall instead of relying on the "non-standard" port
and hard-to-remember password, and problem pretty much solved.

For applications that I write or control, I would put reasonable effort into
"shaping" the worst possible abuses. For example, point #2 above - there's no
real reason the user will ever change their plan more than a few times in a
few minutes, so introduce a delay once a certain limit is reached. It won't
cause any problems and will prevent confusion at the administration side.

~~~
chronomex
If you still want to offer "unlimited space", make it a soft cap -- "You're
using a lot of space, if you need more please email us".

------
dennisgorelik
When you are just starting -- there is no abuse, because nobody knows about
you. If you keep working on application and monitor it, you would be able to
notice the abuse, fix it manually, and add features that would prevent it in
the future.

