4 ms·
I don't like Java and I don't consider jobs where I'd be doing a nontrivial amount of Java. But the original comment I replied to said this class of bug is hard
by ndriscoll 3y ago
I don't like Java and I don't consider jobs where I'd be doing a nontrivial amount of Java. But the original comment I replied to said this class of bug is hard to avoid, and it's not. Use any statically typed language, and it can't happen. Java's the obvious choice. C# is probably fine too.
Same with something like SQL injection or log4shell. These are also preventable using string formatting macros. If `DatabaseConnection.run` takes a `SqlQuery`, not a `String`, and you can only make a `SqlQuery` through a safe API, and your escape hatch is a macro that does query parameterization instead of string substitution, then your users can't get it wrong. This is how Scala libraries actually work and have worked for years. Similarly if you build your logging library to take MDC objects that are built with format macros. These are solved problems.
- tptacek 3y agoThis is a logic bug, not a typing bug. One clear way you know this is: this bug occurs in both Java and C# applications, routinely. But that's OK! I'm not going to dunk on you for using C#, even though it is practically the ground spring from which all web app vulnerabilities have emerged (you'd think it'd be PHP, but C# has a better claim to the title).
- neonsunset 3y agoCan you show examples of such bug in these two languages? (I'm in particular interested in how it could manifest with EF Core)
- tptacek 3y agoRight now I'll just say that from 2005-2015, Java and C# applications were literally the bread and butter of every application security shop (house accounts for web appsec firms were Fortune 100 companies that built all their line of business apps in those two languages), and password reset bugs wereo one of the first place you'd look. I think I even included password reset in a "Seven Deadly Features" blog post I wrote at Matasano. None of that is a reason to avoid C#! I'm not trying to say that using the two most fertile sources of web application security vulnerabilities over the last 20 years is per se a bad decision!
- blackoil 3y ago> that from 2005-2015, Java and C# applications were literally the bread and butter of every application security sho That is because that is what enterprise uses, I don't think it would have changed a lot now.
- ndriscoll 3y agoTyping bugs are just logic bugs that you were able to encode into the type system, and therefore the checker is able to reject for you. Types are propositions and values are proofs. This is not just an academic fact; my SqlQuery example is a direct practical application.
- tptacek 3y agoThe claim here being that C# and Java apps rarely have SQL injection vulnerabilities?
- ndriscoll 3y agoThe claims being SQL injection is a problem with a known solution, that Scala does it right, and that it's an example of turning logic errors into type errors.
- neonsunset 3y agoPlease do not put C# into the category of languages that have issues with SQL injections - pushing raw unparametrized SQL through EF Core in the past required going out of your way to use explicitly discouraged API prefaced with warnings. Today, it has been superseded by FromSql which uses string interpolation API so that it is transformed into safe parametrized queries without any explicit action from the user.
- ndriscoll 3y agoGood to hear. Java also recently added the ability to make custom string interpolators with that exact use-case in mind. I know C# has LINQ, which is similar to query monads in Scala, but IMO using string interpolators tends to be cleaner for more complex queries.