7 ms·

Does go have a bad security reputation? I get that anything can be insecure and its a constant battle as this article suggests, but i thought it was quite secu

Does go have a bad security reputation? I get that anything can be insecure and its a constant battle as this article suggests, but i thought it was quite secure and stable generally (say on a par with .net or any other tool you may use to make a web app at least?)

wbl 2y ago
You can write SQL injection in any language.
jiehong 2y ago
You can use outdated dependencies in any language.
valbaca 2y ago
> i thought it was quite secure and stable generally It is, but security isn't a "given" anywhere. XSS, SQL Injection, Dependency etc can be done by any language, regardless of how "secure" it claims to be. The headings are all pretty general (versioning, tooling, scanning, testing) but the contents are Go-specific. It's a pretty good article IMO and could/should be replicated for other languages as well.
jerf 2y ago
No. Ironically, a flip side of the complaints about how Go lacks power is that a lot of the "standard" security vulnerabilities actually become harder to write. The most obvious one is lacking the "eval" that a dynamic language has; more subtle ones include things like, there is no way to take a string and look up a type or a method in the runtime, so things like the Ruby YAML vuln are not assisted by the language level. To write something like that into Go, you'd have to actually write it in. Though you can, if you try hard enoough. But, as sibling comments point out, nothing stops you from writing an SQL injection. Command injections are inhibited by the command only taking the "array of strings" form of a command, with no "just pass me a string and we'll do shell things to it" provided by the language, but I've dispatched multiple questions about how to run commands correctly in Go by programmers who managed to find []string{"bash", "-c", "my command with user input from the web here"}, so the evidence suggests this is still plenty easy enough to write. Putting the wrong perms or no perms on your resources is as easy as anything else; no special support for internal security (compare with E lang and capabilities languages). And the file access is still based on file names rather than inodes, so file-based TOCTOUs are the default in Go (just like pretty much everywhere else) if you aren't careful. It comes with no special DOS protection or integrated WAF or anything else. You can still store passwords directly in databases, or as their MD5 sums. The default HTML templating system is fairly safe but you can still concatenate strings outside of the template system and ship them out over an HTTP connection in bad ways. Not every race condition is automatically a security vulnerability, but you can certainly write race conditions in Go that could be security vulnerabilities. I'd say Go largely lacks the footguns some other languages have, but it still provides you plenty of knives you can stab yourself with and it won't stop you. I've been running govulncheck against my repos for a while, and I have seen some real vulnerabilities go by that could have affected my code, but rather than "get arbitrary execution" they tend to be "didn't correctly escape output in some particular edge case", which in the right circumstances can still be serious, but is still at least less concerning than "gets arbitrary execution".
- Smaug123 2y ago
  > I'd say Go largely lacks the footguns some other languages have With the glaring exception of "I forgot to check the error code", which you need a linter (e.g. as provided by golangci-lint) for. It's critically important for security that you know whether the function you just called gave you a meaningful result! Most other languages either have sum types or exceptions.
  - tptacek 2y ago
    No it's not. This is what I meant, cross-thread, when I suggested being wary of arguments trying to draw significant distinctions between memory-safe-language X and memory-safe-language Y. Error checking idioms and affordances have profound implications for correctness and for how you build and test code. Programmers have strong preferences. But those implications have only incidental connections to security, if any. Nevertheless "security" is a good claim to throw into a "my language is better" argument.
    - Smaug123 2y ago
      I don't even use Golang, I maybe read two Golang repos a year, I find these errors in almost every repo I look at (probably because of the selection effect: I only look at the code for tools I find bugs in). One of them I remember was a critical vulnerability of exactly this form, so :shrug: Perhaps I'm just grotesquely unlucky in the Golang projects I see, but that makes maybe 10% of the Golang error-handling bugs I've found to be security bugs.
      - tptacek 2y ago
        Sounds memorable. Say more about this critical vulnerability?
        Smaug123 2y ago
        I'll gesture at it. It's not an open source tool, so I can't point at the code (and in fact I just checked and I don't have perms to see the Jira ticket I caused to be raised!), and I am wary of describing security bugs in company-internal code. But in general terms it was a service that attempted to check whether a request was allowed, and it ignored errors from that check. (I just searched history for a bit to find the error in the absence of any actual details about it, but it was a while ago and I failed.) Sorry this is not a very satisfying answer.
perryh2 2y ago
> Does go have a bad security reputation? Depends on who's behind the keyboard.
- Cthulhu_ 2y ago
  Reminds me of when SQL injection was the hot security problem, which was mainly caused by PHP, but not the language itself but reams and reams on low quality online tutorials trying to keep things simple by just concatenating GET parameters straight into an SQL query.
tptacek 2y ago
It has essentially the same security properties of all the modern non-C-languages (ie, C, C++, ObjC), with the added bonus of largely being designed after the deserialization pandemic that especially hit Java, Python, and Ruby. ~All these modern languages are fine for security (though: be careful with serialization formats in anything but Go and Rust). Arguably, Rust and Go are the two "most secure" mainstream languages, but in reality I don't think it much matters and that you're likely to have approximately the same issues shipping in Python as in Rust (ie: logic and systems programming issues, not language-level issues). Be wary of anyone trying to claim that there are significant security differences between any of the "modern" or "high-level" languages. These threads inexorably trend towards language-warring.
- quietbritishjim 2y ago
  What is the "deserialisation pandemic"? It doesn't have obvious web search results, and I'm struggling to imagine what about deserialisation what be common between Java and Python (except that, in both cases, I'd surely just use protobuf if I wanted binary serialisation).
  - kibwen 2y ago
    See https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell , but also historically the mess that is pickling/unpickling in Python (see the big scary warning at the top of https://docs.python.org/3/library/pickle.html#pickle-python-object-serialization https://docs.python.org/3/library/pickle.html#pickle-python-... ), and more broadly any dynamic language that exposes `eval` in any capacity.
    - tptacek 2y ago
      For many years, these were the most widespread serverside RCE vulnerabilities; Rails YAML might be the best-known, but there were a bunch of different variants in Java serialization, and a whole cottage subfield of vulnerability research deriving different sequences of objects/methods to bounce deserializations through. It was a huge problem, and my perception is that it sort of bled into SSRF (now the scariest vulnerability you're likely to have serverside) via XML deserialization.
deleted 2y ago
[deleted]

wbl 2y ago

You can write SQL injection in any language.

jiehong 2y ago

You can use outdated dependencies in any language.

valbaca 2y ago

> i thought it was quite secure and stable generally It is, but security isn't a "given" anywhere. XSS, SQL Injection, Dependency etc can be done by any language, regardless of how "secure" it claims to be. The headings are all pretty general (versioning, tooling, scanning, testing) but the contents are Go-specific. It's a pretty good article IMO and could/should be replicated for other languages as well.

jerf 2y ago

No. Ironically, a flip side of the complaints about how Go lacks power is that a lot of the "standard" security vulnerabilities actually become harder to write. The most obvious one is lacking the "eval" that a dynamic language has; more subtle ones include things like, there is no way to take a string and look up a type or a method in the runtime, so things like the Ruby YAML vuln are not assisted by the language level. To write something like that into Go, you'd have to actually write it in. Though you can, if you try hard enoough. But, as sibling comments point out, nothing stops you from writing an SQL injection. Command injections are inhibited by the command only taking the "array of strings" form of a command, with no "just pass me a string and we'll do shell things to it" provided by the language, but I've dispatched multiple questions about how to run commands correctly in Go by programmers who managed to find []string{"bash", "-c", "my command with user input from the web here"}, so the evidence suggests this is still plenty easy enough to write. Putting the wrong perms or no perms on your resources is as easy as anything else; no special support for internal security (compare with E lang and capabilities languages). And the file access is still based on file names rather than inodes, so file-based TOCTOUs are the default in Go (just like pretty much everywhere else) if you aren't careful. It comes with no special DOS protection or integrated WAF or anything else. You can still store passwords directly in databases, or as their MD5 sums. The default HTML templating system is fairly safe but you can still concatenate strings outside of the template system and ship them out over an HTTP connection in bad ways. Not every race condition is automatically a security vulnerability, but you can certainly write race conditions in Go that could be security vulnerabilities. I'd say Go largely lacks the footguns some other languages have, but it still provides you plenty of knives you can stab yourself with and it won't stop you. I've been running govulncheck against my repos for a while, and I have seen some real vulnerabilities go by that could have affected my code, but rather than "get arbitrary execution" they tend to be "didn't correctly escape output in some particular edge case", which in the right circumstances can still be serious, but is still at least less concerning than "gets arbitrary execution".

Smaug123 2y ago
> I'd say Go largely lacks the footguns some other languages have With the glaring exception of "I forgot to check the error code", which you need a linter (e.g. as provided by golangci-lint) for. It's critically important for security that you know whether the function you just called gave you a meaningful result! Most other languages either have sum types or exceptions.
- tptacek 2y ago
  No it's not. This is what I meant, cross-thread, when I suggested being wary of arguments trying to draw significant distinctions between memory-safe-language X and memory-safe-language Y. Error checking idioms and affordances have profound implications for correctness and for how you build and test code. Programmers have strong preferences. But those implications have only incidental connections to security, if any. Nevertheless "security" is a good claim to throw into a "my language is better" argument.
  - Smaug123 2y ago
    I don't even use Golang, I maybe read two Golang repos a year, I find these errors in almost every repo I look at (probably because of the selection effect: I only look at the code for tools I find bugs in). One of them I remember was a critical vulnerability of exactly this form, so :shrug: Perhaps I'm just grotesquely unlucky in the Golang projects I see, but that makes maybe 10% of the Golang error-handling bugs I've found to be security bugs.
    - tptacek 2y ago
      Sounds memorable. Say more about this critical vulnerability?
      - Smaug123 2y ago
        I'll gesture at it. It's not an open source tool, so I can't point at the code (and in fact I just checked and I don't have perms to see the Jira ticket I caused to be raised!), and I am wary of describing security bugs in company-internal code. But in general terms it was a service that attempted to check whether a request was allowed, and it ignored errors from that check. (I just searched history for a bit to find the error in the absence of any actual details about it, but it was a while ago and I failed.) Sorry this is not a very satisfying answer.

perryh2 2y ago

> Does go have a bad security reputation? Depends on who's behind the keyboard.

Cthulhu_ 2y ago
Reminds me of when SQL injection was the hot security problem, which was mainly caused by PHP, but not the language itself but reams and reams on low quality online tutorials trying to keep things simple by just concatenating GET parameters straight into an SQL query.

tptacek 2y ago

It has essentially the same security properties of all the modern non-C-languages (ie, C, C++, ObjC), with the added bonus of largely being designed after the deserialization pandemic that especially hit Java, Python, and Ruby. ~All these modern languages are fine for security (though: be careful with serialization formats in anything but Go and Rust). Arguably, Rust and Go are the two "most secure" mainstream languages, but in reality I don't think it much matters and that you're likely to have approximately the same issues shipping in Python as in Rust (ie: logic and systems programming issues, not language-level issues). Be wary of anyone trying to claim that there are significant security differences between any of the "modern" or "high-level" languages. These threads inexorably trend towards language-warring.

quietbritishjim 2y ago
What is the "deserialisation pandemic"? It doesn't have obvious web search results, and I'm struggling to imagine what about deserialisation what be common between Java and Python (except that, in both cases, I'd surely just use protobuf if I wanted binary serialisation).
- kibwen 2y ago
  See https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell , but also historically the mess that is pickling/unpickling in Python (see the big scary warning at the top of https://docs.python.org/3/library/pickle.html#pickle-python-object-serialization https://docs.python.org/3/library/pickle.html#pickle-python-... ), and more broadly any dynamic language that exposes `eval` in any capacity.
  - tptacek 2y ago
    For many years, these were the most widespread serverside RCE vulnerabilities; Rails YAML might be the best-known, but there were a bunch of different variants in Java serialization, and a whole cottage subfield of vulnerability research deriving different sequences of objects/methods to bounce deserializations through. It was a huge problem, and my perception is that it sort of bled into SSRF (now the scariest vulnerability you're likely to have serverside) via XML deserialization.

deleted 2y ago

[deleted]