Hacker News Reader

Comment by fizx | Hacker News Reader

Every competitor that has signed up for any service I've been involved with has tried to hack us. Whether it's something relatively benign like some querystring manipulation, or something interesting like an elasticsearch zero-day, they all try.

This is a good time to think about security. Can they find competitive information in your urls (you use sequential customer ids?)? Are there areas not locked down?

Remember their IP addresses and cookies, and do a scan of your logs in a month.

Still, it's not worth the trouble of kicking them out. Fake emails are a dime-a-dozen.

View on HN

Perhaps this is true in the hyper-competitive world of silicon valley startups where it's better to ask for forgiveness (from a judge) than permission, but outside of sv I have never, ever experienced a startup actively exploiting a competitor's systems -- I can't think of a single example. Signing up to a competitor to understand what they're doing, and sometimes cribbing ideas, sure, all the time, but hacking?

> Every competitor that has signed up for any service I've been involved with has tried to hack us.

That sounds wonderful; hand the evidence to Legal and go tear them to shreds in court!

There's only been one time that did real damage. Talked with a security firm, got an audit, and the bad guy did a good enough job of covering their tracks (did the recon with their account, actual attack over TOR) to make it hard to prosecute.

Another time, when one of our competitors was creating a bunch of spam accounts on our app, we just had our VC call their VC. They blamed it on an intern and stopped.

I was at a drinking event at a conference 3 years after an acquisition talk fell through, and an employee of the acquirer told me that they got our customer list from a specific endpoint manipulation, and that caused them to lose interest.

Everyone tries querystring and url manipulation. It's too tempting not to poke around.

In the real world, you can't prosecute any of this.

> they got our customer list from a specific endpoint manipulation

- Never use monotonically increasing IDs as the keys for GET endpoints of single entities. These can be enumerated. Only use tokens composed of random entropy for externally facing keys.

- Carefully consider what your list endpoints reveal. Scope them down to the minimum possible result set. As a bonus, encrypt your cursoring API so it doesn't leak information about your scale. This isn't hard to do. Send down an opaque encoding of pagination state that is server side encrypted and that the client code never needs to unpack. The client just sends the direction, sort key, and encoded token.

Many years ago found a data disclosure issue with a competitor's API. I immediately disclosed it to them and they fixed it.

If you have competitors that aren't giving you that courtesy you should submit a complaint to law enforcement.

Curious what space are you in?

Reply on news.ycombinator.com