Which is to say, the low hanging fruit won't be exploitable type safety problems, but rather application logic issues: SQL injection (Go's database integration is still the wild west), failure to properly authorize RPCs or HTTP endpoints, SSRF, and stuff like that. I'm probably not going to use property testing to find an SSRF, or to spot a static nonce, or something like that (somebody feel free to put me my place over that! maybe I should use more property testing!)
It's interesting that the strategies described in this post lean so heavily on theoretical program correctness; as I read it, it felt super useful to me as a Go developer, and less directly applicable to my assessment work.
Relatedly, this post was circulating on Twitter yesterday, and it is great: a race condition in Go code exploitable for RCE:
I probably had your attention with that summary! Race conditions in Go code could be a broadly exploitable bug class! Except: not so much, no: the conditions making that bug exploitable are both contrived and outlandish enough that no security reviewer, even one unfamiliar with Go, would have been comfortable with that design.
It's an artifact of the type of clients we tend to get: microservices, blockchain software, and Kubernetes (itself an amalgamation of many loosely connected components). These tend to be easier to test (less code, less state) and require higher assurance so we hit correctness properties a lot more commonly than, say, a monolithic web application.
> (somebody feel free to put me my place over that! maybe I should use more property testing!)
There is a part 2 to this blog post that you will enjoy! =D
Could you elaborate on this? I thought you were safe if you used the '?' parameter replacement.
I'm not going to go into a fresh Django project optimistic about my chances of finding SQLI, but a database-heavy Go program, that's one of the first things I'm going to take a whack at.
Now, instead of being able to quickly see a query in one place what commonly happen is people breaking down all things and creating "helper" functions in strange ways to select, limit, order, and any other stuff, and ending up with something so complex you waste a lot of time to understand and only the original writer knows where to find anything. For me, this adds way more issues than any security concerns you might have related to learning SQL properly, too – and if you are using an ORM chances are you already know how SQL works anyways (and you can use static analysis tools to reduce the errors, plus the reduced cognitive load in using vanilla SQL).
It’s much less common in SaaS environments.
Is something like this prone to SQL injection ? I am very new to Go and still learning how to interact with databases (I am not a big fan of ORMs).
stmt = "UPDATE users SET last_login = $1 WHERE id = $2"
_, err = services.DB.ExecContext(ctx, stmt, time.Now(), id)