[00:35:59.25] Yeah, so I’ve thought about this… At Atredis we’ve actually tested quite a number of Go applications. We do a lot of software security type of things, and so the things that I see – I was gonna go into that, this is actually a nice feature of Go… For example, say you wanna take JSON and you wanna move that into a struct that you eventually wanna insert into a database; this is a very common thing… The nice thing about Go is that you’re explicitly defining the fields that you want in that struct. So you’re not gonna get random fields.
For example, if you’re using something like Node, we see this a lot, where they basically take request.body, if you’re familiar with that, and they slam it into a database and now you’ve got real problems at hands.
So what I see is that actually works quite well, because now you know the objects that you want; “objects” in quotes. And now you’ve also defined the field types; you know that what’s coming in is gonna be a string. Sometimes it might cast an integer to a string depending on the library that you’re using, and that sort of thing, but you are defining at least the data types that you want coming in.
So the stuff that I see just from that end is sometimes you have a struct that represents something that’s in the database, a user item. If you serialize that directly into the database, directly from JSON, you’ve got something called mass assignment, where you’re basically not filtering the fields that you expect, because your form might take three fields to find the user; the first name, the last name and the email address. However, what if you have another field that’s like a boolean, “isadmin”, or something like this… Just because your form doesn’t provide that value doesn’t mean that the user won’t provide that. And when you serialize that JSON or that form value even into the struct, and then you put that struct in the database, you’ve got a serious problem on your hands now, because now they’re starting to modify objects, and things like this. So I see that quite a bit.
SQL injection – we don’t see that a lot. Cross-site scripting, we don’t see that. We’ve seen some really nasty bugs when people are writing their own templating engines; we’ve seen some particular nasty ones. One actually resulted in code execution…
This particular instance was basically they had a partial template that would load the user input from a database. Then that partial template would get rendered into a parent template. And because they took that value as trusted, you could put code in there, so you had this double eval type of situation.
But I think those are few and far between. I think most of the Go things that we’re testing, people aren’t actually using templates to render server-side anymore. They’re mostly using a JSON or other services. However, I would probably stick to the standard Go template, or at least something that wraps that pretty thinly. That’s just my opinion. But we don’t see a lot of that stuff.
We see that mass assignment issue… For whatever reason, when you’ve got cross-site request forgery, we see the protections implemented, but often incorrectly.