One thing that I’ve been thinking about is how secure the webserver in Go is. I’m guessing it’ pretty hard to hack, being so simple and low level, right?
I mean, compared to the beast of say Apache, which certainly has its security holes being so complex. I’m wondering if any security expert has actually tried to break Go’s webserver in some way?
And, I’m talking about the core part here, and not some application where someone is saving passwords in clear or something silly like that. No, I’m talking about the server itself. It’s just listening on a socket, so I’m guessing it’s almost as safe as it can be, no? I like that very much I must say. But still, curious as to how safe it really is.
Well, Go is supposed to be memory safe so you should be protected against buffer overflows and remote execution vulnerabilities ought to be quite tricky. I guess an exception would be if your program is racy and already corrupts memory on its own, then all bets are off but again exploiting this should be tricky and preventing it is relatively easy…
But then you have the other classes of exploits of web applications like the OWASP top ten which is mostly up to you to defend yourself against. It’s perfectly possible to write something vulnerable to all kinds of SQL injections, data exposure, cross site requests etc. in Go.
There hasn’t been a crypto audit. However most of crypto code was written by Adam Langley, who is a recognized expert.
Scott Piper has written about Go security 1 and 2, which Thomas Ptacek said he has pretty similar conclusions 3; who I can only assume, has viewed the code – not sure about trying to breaking it.
This doesn’t say anything about existence of security bugs, even the best make mistakes and reviewers miss things. Then again, if Ptacek says it’s pretty good, then it’s good enough for me
Yes, and to add to that I reviewed a CL, that ensures that copies are atomic for all pointers in structs/slices, which makes partial pointer values extremely difficult to generate, further minimizing that vector of attack.
I also agree on your point that vulnerabilities are much more likely to come from your own code than from the Go runtime.
