4 ms·

This is why it's good to run fuzzers against any public API (especially an auth API), to verify its behavior on novel inputs. https://en.m.wikipedia.org/wiki/F

• capableweb 6y ago
  In general I agree with you that it's good to run fuzzers against any endpoints, public or internal (as you never know if someone can wrangle data to go from public -> internal somehow), but in this particular case, you'd only find a issue if the fuzzer somehow randomly used the ID of another user that was already created, and verified that it couldn't access it. In that case, you'd catch it way before even implementing the fuzzer. So in this case, I don't think a fuzzer would have helped. Some E2E tests written by humans should have caught this though.
  • danans 6y ago
    There's no reason that a fuzzer couldn't draw sample email addresses from a large pool of test valid email addresses to add as input. That would just require a fuzzer that allowed you to provide the sample population for a particular data type.
    • capableweb 6y ago
      My point still stands. If the one setting up the fuzzer is thinking about the condition that A) you're using a valid email that B) already existing in the system and C) cannot be used to authenticate with another system, you can easily check the code for this directly. The fuzzer won't add anything over a simple integration/E2E test here.
      • danans 6y ago
        Fair point! The question I have then is whether it's possible to create a tool that automatically detects bugs like this without needing to write an integration test for this specific cases.