1. 3
    gavinmiller avatar gavinmiller 3 years ago | link | on: The Safest Way to Constantize...

    @swifthand You’re completely correct re: never trust the client and such. I’m a big fan of this quote by thomas ptacek:

    I am wary of software security advice that leads with “don’t trust user input”, or revolves around “validate user input”. That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to tstart by acknowledging that the verb “trust” is situational, and that in some circumstances virtually all user input is “trusted” somehow. You could phrase this less tactfully as “Validate user input? No shit? Now what?”

    The security industry has banged the drum of sanitize everything and yet this stuff still slips by! And I’m in agreement with you that the majority of code bases aren’t written like the example I posted, however I’ve seen variations of that pattern in live code bases. Shitty code exists everywhere! Likely not written by those that read these types of posts on reddit / lobsters / et al.

    1. 1
      epidemian avatar epidemian 3 years ago | link

      Agreed. I am perplexed about String#constantize’s docs not having a big warning about it being a possible code injection vector, instructing that the string should always be validated. Or at least being tagged as “insecure/unsafe” in some way.

      Skimming through the Rails docs, it seems that these security matters are not given the importance they should. Even ActiveRecord’s where only says:

      Note that building your own string from user input may expose your application to injection attacks if not done properly. As an alternative, it is recommended to use one of the following methods.

    1. 6
      lmm avatar lmm 3 years ago | link | on: A Tale of Security Gone Wrong

      Why would you ever think this was a good idea? I guess non-security folks see the world differently?

      This is a good example of the not-immediately-obvious ways types can help. Represent the password as a “zomg sensitive” type such that anything derived from it is also zomg sensitive (using a free-monad-like type). The only function that makes something not zomg sensitive is the password hashing function (and you enforce this). That at least forces you to ask the question “is this password-derived value somehow not sensitive?” when writing code to store it in the database.

      1. 2
        gavinmiller avatar gavinmiller 3 years ago | link

        Quoting Thomas Ptacek:

        Most of the industry’s worst security problems happened because smart developers approached security code the same way they did the rest of their code. The difference between security code and application code is, when application code fails, you find out right away. When security code fails, you find out 4 years from now, when a DVD with all your customer’s credit card and CVV2 information starts circulating

        From talking with my friend, he expressed how they were working to enhance their system’s security. I think many an error in crypto / authentication occurs because devs ignorantly try to make their systems more secure. Wherein the above quote is applicable, they don’t realize that they’ve actually harmed the system, and have no immediate feedback until they get owned.