[HN Gopher] Show HN: Fuzz Map - a GUI fuzzer, interactive demo
       ___________________________________________________________________
        
       Show HN: Fuzz Map - a GUI fuzzer, interactive demo
        
       Author : jonathanyc
       Score  : 167 points
       Date   : 2022-08-24 12:11 UTC (10 hours ago)
        
 (HTM) web link (www.fuzzmap.io)
 (TXT) w3m dump (www.fuzzmap.io)
        
       | wongarsu wrote:
       | I imagine this would be a very useful tool to have if you want to
       | communicate about the design or user flow of an existing app, in
       | addition to the highlighted use case of finding unexpected
       | behavior and crashes.
        
         | fullstackchris wrote:
         | And, if you can save 'snapshots' of a given fuzzmap to detect
         | potential regressions and / or changes in general to the flow.
        
       | joeycodes wrote:
       | I am so excited to see this live! I always wanted something like
       | this for testing games and complex SPA's. UI's are particularly
       | problematic for writing tests -- there's usually much more churn
       | in that area of an application versus the business logic, and no
       | matter how many tests we did try to write, users (and ambitious
       | internal testers that clicked everywhere like crazy) would find a
       | creative way to break things. I think having UI fuzzing in the CI
       | pipeline will go a long way to deploying UI updates with more
       | confidence. Congrats on launching!
        
       | atemerev wrote:
       | Wow, that's really impressive. I'll probably start using this
       | right away.
        
       | thomasfromcdnjs wrote:
       | Wow.
        
       | blondin wrote:
       | so is this a fuzzer for generating GUI elements to see what works
       | or not? or one to generate input states that crash a GUI?
        
         | solardev wrote:
         | It runs GUI code (like React) and fuzzes the inputs not just to
         | generate possible crashes but to discover different code paths
         | and states.
         | 
         | The example they provide shows a simple food ordering system
         | and the fuzzer eventually discovers how to place an order, but
         | not before first encountering validation errors and fuzzing
         | past them.
        
         | michaelmior wrote:
         | I'm not sure what you mean by "see what works." My
         | understanding is that it's designed to automatically interact
         | with a GUI and identify the possible different states that the
         | UI could be in and the inputs required to enter those states.
         | (Presumably this includes the state of being crashed.)
        
       | terpimost wrote:
       | Wow, that is cool. How do you do code coverage? Console.log()
       | every function call?
        
         | jonathanyc wrote:
         | We add instrumentation at compile-time, just like conventional
         | fuzzers!                   if (e) a else b
         | 
         | becomes                   if (e) { hit(1); a }         else {
         | hit(2); b }
         | 
         | There's more detail in the writeup if you curious, just scroll
         | down!
        
       | stephendause wrote:
       | Very nice!
       | 
       | Does this tool have a state model that you can check the
       | application state against? In other words, does it have property-
       | based testing? Here[1] is a demo of what that looks like.
       | 
       | I
       | 
       | [1] https://medium.com/criteo-engineering/detecting-the-
       | unexpect...
        
         | jonathanyc wrote:
         | Thank you! I'd like to support property-based testing in the
         | future. For this demo I focused on visualization and more
         | exploratory testing.
         | 
         | I figured that'd make the demo more approachable to people who
         | weren't already into fuzzing or formal methods. But being able
         | to automatically discover non-crashing bugs using property-
         | based testing could be pretty powerful.
        
       | makach wrote:
       | wow! this is very cool. I wonder how this would work with
       | slightly more complicated UIs. Does it create too much noise?
       | Does anyone need this kind of verbosity?
        
         | jonathanyc wrote:
         | Thank you! Good question about complicated GUIs. Keeping the
         | map simple enough to be usable ended up being the most
         | interesting part of the project, engineering-wise--the end of
         | the write up touches on map simplification! There's a lot more
         | I'd like to do.
        
       | huhtenberg wrote:
       | > Here's a 5-second video of real-time fuzzing on my laptop.
       | 
       | The space where the video is supposed to be is blank. Clicking on
       | play instantly skips to 0:05 mark and nothing else happens.
       | Firefox on Windows.
        
         | solardev wrote:
         | Plays fine in my Firefox for Windows, FWIW. Also works in
         | Chrome desktop and mobile.
        
         | wongarsu wrote:
         | It's a bit pointless anyways imho (on Desktop). Just close the
         | popup and click Fuzz.
        
           | anarcat wrote:
           | i kind of like having the video. actually running the fuzzer
           | uses a lot of CPU: it makes my fan startup.
           | 
           | it works fine here on Firefox + Debian GNU/Linux 11
           | stable/bullseye.
        
       | solardev wrote:
       | Super cool, thanks for sharing!
        
       | kretaceous wrote:
       | > In the short term, I'd like to make a plug-and-play version of
       | Fuzz Map that supports end-to-end React fuzzing. You won't have
       | to change your build process or use a special browser--just run
       | ./fuzzmap localhost:8080 -p 9090 and start fuzzing or live
       | programming! A reverse proxy will add instrumentation on the fly.
       | 
       | Eagerly waiting for this. I _need_ this. I don 't write tests for
       | a certain React codebase [1], and this could be a life saver.
       | Amazing work!
       | 
       | 1: Before you hate, I'm not against tests and I advise on writing
       | them. There are certain situations in this case.
        
       | tpoacher wrote:
       | Why is this process called "Fuzzing"?
       | 
       | Isn't this a really uninformative/ misleading name?
        
         | WhitneyLand wrote:
         | Because it's a fuzzy representation of input, in that it's
         | partially valid enough so to be able to use the system, but
         | also invalid in a way that's designed to find bugs.
         | 
         | https://en.wikipedia.org/wiki/Fuzzing
        
       ___________________________________________________________________
       (page generated 2022-08-24 23:01 UTC)