Hacker News new | ask | show | jobs
by alwa 679 days ago
I’m really impressed at the number of times they say their counterparts responded to their report in under an hour, immediately took the affected site offline, then resolved the issue quickly.

That seems like an enviable operation.

5 comments

Seriously! I actually can’t think of any openly documented security incident with such impressive remediation timelines.

There’s a lot that has to go into fixing things on such a tight timeline too:

- oncall-level alerting for your security.txt inbox - your oncall needs to either be someone who can actually take corrective action on the system in question (not easy in a large company!) or able to route the issue to the right team - the service owners need to be empowered to treat security with the appropriate severity (taking the site down so quickly speaks highly to this)

Hats off to the points.com team. With any luck, this post doesn’t get too much traction and y’all won’t get flooded with bounty beggar spam.

> - oncall-level alerting for your security.txt inbox

Maybe the terminology is different in your company, but my employer has an 'operations' team which has several shifts of workers, who look after things that need 24/7 monitoring. They then triage and escalate as appropriate.

That's who you'd have monitoring the security inbox, if you want round-the-clock monitoring, so nobody's getting woken several times a night by spam.

We call that guy grafana alerts at ours
It's a strange disconnect between the quality of the incident response and the extremely basic nature of many of the bugs reported. I mean SECRET_KEY='secret'?! Seriously straightforward stuff.
Why? One depends on development practices, the other on security-team practices. You can have a team of donkeys building a product and the sharpest hackers guarding it. Ideally best practices would trickle down, but that's not a given.
> You can have a team of donkeys building a product and the sharpest hackers guarding it.

You could do but it's a pretty risky way to run a business. Obviously the real world often gets in the way, but a competent manager would look at that org structure and say "shouldn't we move some of those smart ppl on to the build team to catch issues before they're in prod? Seems awfully risky waiting until it's live to catch these bugs which could cause us massive financial harm"

From experience, a lot of talent security people really just don’t want to be developers, even if they’re good at it. It’s not always as simple as shuffling people around between teams.
Why would anyone even use such a predictable word for dev environment? I am baffled by this practice of not following the bare minimum security mindset even when you are just running it in a dev environment
Because it's dev. Does your bathroom door have a deadbolt and a key and you lock it firmly every single time when you're home alone?
Whilst you are being facetious, deadbolting a bathroom door is really really dangerous.

Bathrooms have a high risk of life threatening accidents and any locks should be bypassable indicators - this is why most have a coin unlock on the outside.

Many countries have regulations requiring bathrooms to be unlockable from the outside without a key, and the external doors to be unlockable from the inside without a key.

Deadbolting a bathroom is also pointless - there is nothing ti protect.

Using an effective password for dev environments is sensible; it holds no risk of meaningful loss and can prevent compromise due to a common mistake.

I guess I should go check if I can unlock my (regular lock) bathroom door from outside!

> Deadbolting a bathroom is also pointless - there is nothing to protect.

Pedantically, many people keep medicines in their bathroom and if you happen to have any recreationally-usable drugs, they'd be one of the first things to go in a lot of robberies. Or, sadly, be taken by your teenager or seemed-to-be-normal friend.

No, but the bathroom does have a lock that can be used from the inside. Not a door that has a window in it and a lock that can be controlled from both sides of the door.
I don't know if points.com was a startup at some stage with a build fast fix later attitude, I wonder if a lot of startups are in the same boat.
Makes me wonder if they (points.com) have some key-word alerts on incoming emails. I know for sure that at some companies, this would have taken hours (to days!) to detect, if the tip had come through a regular info@ or contact@ inbox.
The article mentions a security.txt[1] which doesn't seem to contain an email address but it does contain a link[2] to a disclosure program, I'm guessing that's how they submitted all their findings?

[1] https://www.points.com/.well-known/security.txt

[2] https://bugcrowd.com/plusgrade-vdp-pro

It seems they reacted before the team even sent over a report in one case:

> Before we could even finish sending our report or see if other endpoints were accessible (e.g. adding points to a customer rewards account), the points.com team had detected our testing and had completely shut down United's production points.com website. Bummer!

You almost have to pull the site to stroke bounty hunter egos when you could just push a change to prod instead.

If not, they are quick to bash you publicly.

There’s too much hubris in the “professional” web app bug hunter community.

Generally, their attitude is very “look at these stupid developers,” “developers suck at security,” or “a conspiracy is happening because company X didn’t take their app down within 10 minutes of getting my email.” It’s much more nuanced than that.

I’d like to see:

1) more bounties and better paid bounties

2) less ego and much more professionalism and patience from “researchers”

Both would be better for consumers.

> when you could just push a change to prod instead.

I wonder if there's an attack vector hiding where you induce a malicious bug via an illegitimate bounty and the developers' bias against inaction.

How about this one: https://hackerone.com/reports/745324

It's a $20k bounty for simply taking a cookie that a HackerOne employee accidentally pasted when responding to a different vuln report on HackerOne.

100%, hacking is as much technical prowess as it is social engineering.