4 ms·

> The restrictions were all client-side. :-( I've been in this industry since 1996. Must every programmer make this mistake for themselves before they learn?

• vxNsr 4y ago
  Yea this was a surprise.
• jgrahamc 4y ago
  It wasn't mean to be client-side only, it was meant to be client-side and server-side. Unfortunately, the server-side check wasn't happening in the way intended allowing Albert to find this vulnerability. We have a special document that describes bug classes that need special attention and this particular incident has been added to it.
  • OJFord 4y ago
    I think you're giving too much weight to this angle - if OP had happened to be in the beta, that part wouldn't have been found or mentioned at all. Bypassing a beta feature toggle isn't really a vulnerability IMO, it just allowed OP to find one in this case.
    • mox1 4y ago
      What!? So nobody here can think of any possible scenario where bypassing a server-side check for 'Account X can access Feature Y' could directly lead to a security issue? This is absolutely 100% a vulnerability - insomuch as that CloudFlare should have an explicit policy that ALL account features are enabled / verified server-side, not client side. Think of all the spam that would have happened, had this been discovered on underground black-hat forums.
      • OJFord 4y ago
        Do you want to offer some? It's not clear this even bypassed payment that should have been due. That would be worse, and still not really a vulnerability. > Think of all the spam that would have happened, had this been discovered on underground black-hat forums. What spam would have happened as a result of early access to a new Cloudflare feature, that's independent of any (other) bugs/security flaws in that feature? (Also, even with the actual vulnerability here, what 'spam' would have happened? This hijacks recieving. Worse, yes, but I don't see how it helps spammers.)
        • BeefWellington 4y ago
          Accessing functionality you should not otherwise have access to is by definition a vulnerability. CF apparently agrees since they paid out a bounty for it.
          • OJFord 4y ago
            > CF apparently agrees since they paid out a bounty for it. Not really, it was mentioned as part of a report of the main, much more critical issue of 'hijacking email with Cloudflare Email Routing' - note that's the title itself, not 'accessing a cloudflare beta feature'...
    • systemvoltage 4y ago
      jgc is just responding to the OP, don't strawman him. OP is the person focusing on the client-side beta check, so jgc is responding to that particular thing. Has zero bearing on the overall issue.
      • OJFord 4y ago
        I'm not 'strawmanning' him, I'm saying responding to that line of argument (or at least in the way that he did, accepting the claim it's bad and defending on the back foot) lends it undeserved credence. I agree it 'has zero bearing on the overall issue'. That is pretty much my entire point.
  • js2 4y ago
    How was this feature able to ship to production w/o the server-side check being tested? Does CF have a launch process for new features? Does that process include reviewing the special document and testing the new feature against the various bug classes?
  • ffhhj 4y ago
    》We have a special document that describes bug classes that need special attention Sounds like manual testing that should be automated.
  • btown 4y ago
    It occurs to me that this speaks to a more fundamental pain point in software testing. It's so common to write tests that say, in one block of code, "these are the inputs, a function or endpoint is called, and these are the expected outputs." But in theory, every single one of those tests should have variations like "if this exact same input was provided, but with a user with different permissions, as well as a non-logged-in user, the endpoint should fail with a permission error." But then you get into a quandary: if you want to be able to customize your test code granularly, or have your inputs and outputs generated at runtime, you need to be able to write your test setup code as code, not [{ input, endpoint_name, output }] configurations. But if you need code, then you can accidentally run code that calls things directly without the abstractions that would run it with the extra variations. At a certain scale, this speaks to needing either static analysis of your testing code, or extremely diligent review processes, beyond simple code coverage. Does anyone have go-to libraries that deal with this at scale?
• deanc 4y ago
  Because we are humans and we make mistakes. Not everyone is an expert at every one thing and whilst this is a pretty bad bug and should have come up in the planning phase when considering security risks, or a security review before hitting production, shit happens. Get off your high horse.
  • dcow 4y ago
    This type of response makes me think you don’t actually understand how important security is during the product development process and to customers. And that GP is on the mark being critical. Someone messed up and humans are humans, everyone gets that. But that doesn't absolve CF of some due explanation to people who are rightfully very concerned. CF got really lucky that a bad actor didn't find this. I don't like high horses either but you could also use a dose of humility.
    • deanc 4y ago
      I very much do understand the important of security in product development. I’ve been part of numerous security audits amongst other things I shan’t get too deep into here as it’s not the point. The point is that software is developed by humans. Humans make mistakes. Find me a single Fortune 500 company that hasn’t had an embarrassing security issue due to human error. As I said, shit happens. The response time for fixing this and everything else entailed in a big bounty process looks good to me. I’m sure whatever team worked on this feature will learn from it.
  • groffee 4y ago
    It's literally the most basic shit imaginable, never trust user input.
  • js2 4y ago
    We put processes in place because not everyone is an expert and because humans make mistakes. Shipping new features at a company of CloudFlare's maturity and scope should have a launch checklist. That checklist should include verifying the security of new API endpoints. This was a big goof up and I think my criticism is warranted, though I could have worded it more charitably.
• freedomben 4y ago
  Sadly, yes :-( At this point I'm nearly an old man yelling at a cloud, but anytime a junior engineer starts I try to go over a handful of basic security things. Seems that most people coming out of school are aware of SQL injection and XSS, but the concept of client-side security is no security is not sinking in, even after it's been explained. I've spent a lot of time trying to figure out why, and the best I can come up with is that they just think something like the following myths: * Nobody would ever do that. * Nobody would ever hit the API directly. * It would be too hard to do that for somebody who isn't the developer. * The need for an auth token would make it impossible to hit it with curl or another client. * Nobody can change the client code because it's obfuscated and unreadable for humans. Doing it on the server side is harder and a pain in the ass, so there's a lot of incentive to do it on the client and not worry about the server. It particularly doesn't help that as an industry now we're obsessed with speed and quality be damned. We can always fix it/do it right later (spoiler alert: you never do and you never have time because there will always be important new features that are high priority).
  • BeefWellington 4y ago
    There's a bigger problem in that schools are doing a terrible job of teaching programmers proper development practices. If you're lucky, as a student, your school might have an add-on course for secure development. The problem is, secure development practices shouldn't be an afterthought but rather a baked-in core philosophy.
  • Kalium 4y ago
    I think the simplest explanation is that it doesn't occur to many developers that if they can develop a client, someone else can too.