5 ms·

Things today are a LOT different than they were 10 years ago. Not only are ORMs encouraged out of the box, which are (pretty much) immune to SQL injection unles

by morrbo 7y ago

Things today are a LOT different than they were 10 years ago. Not only are ORMs encouraged out of the box, which are (pretty much) immune to SQL injection unless you consciously run native SQL. There is also a HUGE amount of documentation, warnings, etc. on almost everything - got a few links at the end. You could argue that the major source of insecure code these days is old answers on stackoverflow which show vulnerable examples. Though, i believe there was an initiative to go back and change old answers which posted vulnerable code but not sure if that ever took off. Some URLS: As you said SQL server, i literally googled microsoft ado.net example, first result is showing how to use parameterized queries: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-code-examples https://docs.microsoft.com/en-us/dotnet/framework/data/adone... Googled the same with sql injection/security: huge article on it all https://social.technet.microsoft.com/wiki/contents/articles/36264.sql-protect-your-data-against-sql-injection.aspx https://social.technet.microsoft.com/wiki/contents/articles/... As an (ex) security professional myself, i definitely agree with the guy above saying that these days in general you do see a lot less of the "schoolboy" vulnerabilities. Definitely still out there though, even in tier 1 public-facing websites of global banks, but certainly not widespread, and certainly not ubiquitous. I'd say this is due to a combination of hand-holding in frameworks, and better education all round.

bigtex 7y ago
I am fairly certain dotNet has been pushing parameterized queries since .net 2.0 in 2005. I know at my current employer we have been doing it since 2008.
henvic 7y ago
Indeed, ORM is encouraged out of the box in many ecosystems... and sure enough, it is viewed as a silver bullet by many developers and this is a pity. Some ORMs are powerful and even have subsets of language for data transformation, and so on... And now you have even another problem: another layer of abstraction that might fail or have their own bugs and security issues. I miss writing pure and simple SQL queries whenever I'm forced to use an ORM. This is one of the things I enjoy in the Go ecosystem: if you want SQL, probably go with database/sql and write SQL directly instead of any fancy ORMs out there.
- 6thaccount2 7y ago
  I don't write anything user facing, but write plenty of scripts that query a database, return a dataset, create a data frame, and then do statistical analysis on it. The SQL is all pretty straightforward with no ORM and is really easy to understand and use.
  - henvic 7y ago
    Yeah. Most of the time I see people complaining about SQL, I identify that they are trying to build complex nested joins and other stuff likewise for no good reason besides risky premature optimization... And they end up creating little monsters that will haunt them sometime in the future. Then, what happens next? They might end up hating SQL for no good reason and embracing the 'NoSQL' flag with any kind of non-relational database out there and make the very same mistakes they were complaining about SQL, only this time it'll be probably in JSON instead. And they will probably notice earlier the errors and end up thinking SQL is harder and, say, whatever-NoSQL-brand is easy... only because they had more experience and a clear vision of everything when trying out the later. I just wished more people would just keep things simple. For most common web applications out there a single SQL database suffices well, and you can do most, if not all, queries on two or three lines at most with no complex operations and keep things lean. For sure, for search engine ElasticSearch is marvelous, and for keeping track of documents without ever losing data, Datomic is a robust and proven solution... but what I see is mostly people writing software for mom-and-pops shops using Mongo with no transaction support whatsoever.
closeparen 7y ago
But software from 10 years ago is often just plugging along in a closet somewhere.

by morrbo 7y ago

bigtex 7y ago

I am fairly certain dotNet has been pushing parameterized queries since .net 2.0 in 2005. I know at my current employer we have been doing it since 2008.

henvic 7y ago

Indeed, ORM is encouraged out of the box in many ecosystems... and sure enough, it is viewed as a silver bullet by many developers and this is a pity. Some ORMs are powerful and even have subsets of language for data transformation, and so on... And now you have even another problem: another layer of abstraction that might fail or have their own bugs and security issues. I miss writing pure and simple SQL queries whenever I'm forced to use an ORM. This is one of the things I enjoy in the Go ecosystem: if you want SQL, probably go with database/sql and write SQL directly instead of any fancy ORMs out there.

6thaccount2 7y ago
I don't write anything user facing, but write plenty of scripts that query a database, return a dataset, create a data frame, and then do statistical analysis on it. The SQL is all pretty straightforward with no ORM and is really easy to understand and use.
- henvic 7y ago
  Yeah. Most of the time I see people complaining about SQL, I identify that they are trying to build complex nested joins and other stuff likewise for no good reason besides risky premature optimization... And they end up creating little monsters that will haunt them sometime in the future. Then, what happens next? They might end up hating SQL for no good reason and embracing the 'NoSQL' flag with any kind of non-relational database out there and make the very same mistakes they were complaining about SQL, only this time it'll be probably in JSON instead. And they will probably notice earlier the errors and end up thinking SQL is harder and, say, whatever-NoSQL-brand is easy... only because they had more experience and a clear vision of everything when trying out the later. I just wished more people would just keep things simple. For most common web applications out there a single SQL database suffices well, and you can do most, if not all, queries on two or three lines at most with no complex operations and keep things lean. For sure, for search engine ElasticSearch is marvelous, and for keeping track of documents without ever losing data, Datomic is a robust and proven solution... but what I see is mostly people writing software for mom-and-pops shops using Mongo with no transaction support whatsoever.

closeparen 7y ago

But software from 10 years ago is often just plugging along in a closet somewhere.