I think of this type of vulnerability as kind of poke the bear and see what happens. This type of vulnerability is all about seeing how you can make the target act in an unintended fashion. I found proxying the traffic and examining what comes through critical. I would also want to map out functionality in a real-life scenario. One of the drawbacks of these labs in relation to real-world pen testing is knowing what the likely vulnerable area is and the type of vulnerability involved. There are some ways around it like the portswigger-academy-hard-mode by Staubfinger (use at your own risk), but it’s something you should keep in mind while doing the labs. I think this is partly where the practice exam comes in but thinking about how you would find the issues in apps without the prior knowledge. Depending on your experience with app development, I’d probably save this section for later. I think it fits fine here, but without some familiarity with development, some of the things in this might make less sense. The labs are very doable with the solutions, and there are some definite benefits to going through the labs to learn about this class of vulnerabilities.
Reading through the content on Portswigger, the OWASP material, and the Web Application Hacker’s Handbook on logic vulnerabilities does give a pretty good grounding in the class. That plus the labs should give a solid starting point, but I think this is one of those areas where you just kind of have to play around and see what you can find.
I didn’t do much scripting for these labs. There were some places where scripting made sense – like testing a specific parameter or a string generator – but for the most part, using Burp just made more sense. I like scripting out the labs, but it just didn’t make a lot of sense to invest the time for these labs. Other sections I could make a script that I could easily tweak to target other applications, and targeting a parameter was this type of thing. But overall, I think when you get to this point, you are manually poking and prodding to see what happens. And scripting isn’t necessarily the best way to do that. Especially when you have tools that can automate some of that for you.
Overall, valuable section but one that is a bit more complicated. It’s a class of vulnerabilities that will likely always be there, but possibly also a class where many times the effort won’t be worth the reward. I’d look at scripting out testing the parameters for things like string concatenation and exceeding maximum value to become a negative to automate some searching for logic issues. Looking for possible logic vulnerabilities while testing other classes would also be beneficial.