SQL was never meant to be used in web applications. It is inherently insecure in its c&c schema. Can we please fucking stop using databases that are not designed for the web in the web? Please?

(I know, I know, we’re stuck with what we have. But for fok’s sake, I want to strangle that muthafucka who thought it’s a good idea…)

I agree. We need to go back to the days before and use XSLT and XML to build our online content.

But why stop there? Let's go further back and get rid of the cluttered designs of the current web and streamline it back to a text only BBS.

No more need to use JSON or APIs either. Everything is a hosted through a socket and you need to bitbang your way through it. If you're not in the same server as the socket, get fucked! 😆 That is unless you know how to pipe your output across a ssh tunnel.

While we're on the subject, internet connected computers are so insecure these days, right? Let's go back to dialing into remote. Like you know, dialup like gams and paps used to do. If you don't want your server to answer, just pickup the receiver on your landline.

It's so simple!

Thank you!

I'd appreciate some alternative, why do we always bash things but never provide alternatives to better our world.

I'm with @sariel back to XML we go!

Embrace monkeh, let’s go back to oohs and ahhs. Civilization was a mistake.

@C0D4 I have been pondering the subject of a viable alternative lately. If I had a solution in mind, I’d probably be rich pretty soon, eh?

The problem with SQL in the web context is that querying and command&control are inseparable, and that securing it still requires each application to be separately secured, which many a dev (and even DBE) forgo to do adequately. The real problem, of course, is the web itself, but that’s beside the point.

Do the existing database alternatives (that is to say NoSQL, many of which, to my knowledge, have been designed for the web) that do not expose or employ SQL as a command and control interface present an adequately secure alternative? I possess insufficient knowledge to answer that definitely.

@ars1 I agree.

RDMSes are pretty good at storing and querying relational data though. So if you got relational data, chances are that an RDBMS is a good match. And the standard query language for that is SQL.

Whether it is a web application or not doesn't really matter that much.

For security, just use prepared statements and check your privileges.

@Oktokolo that is what we have in this world, yes.

What I was musing about is the inherent insecurity of SQL and it’s ill-advised introduction to the web context, with the developments on the security aspect of things coming late behind and mostly as workarounds, hacks even, that have by now been more or less standardised.

Just a morning’s food for thought. It’s not like I had a better solution. I don’t. It’s just an example of a central technology in IT where security considerations still lack far behind, even more so when it was introduced. I guess nobody really thought of that back then. Understandable as it is, since the cyber threat landscape was vastly different, if not inexistent, or at least unacknowledged…

@100110111 Security isn't the issue with RDBMSes and SQL - concurrent write scalability is.

All the big RDBMSes have pretty fine-grainesd security controls that can do way more than you actually need for web applications. They come from a time where the DBMS also was the application server.

So what do you actually mean with "insecurity"?

@Oktokolo it’s the defaults. If it wasn’t inherently insecure, SQLi wouldn’t stay year after year in the top 3 of OWASP Top 10. I’m aware it’s an user error, but the problem lies within leaving the security controls for the users to implement and/or enable.

@100110111 this is why the CQRS pattern exists.

Not only does it provide context to your architecture for security, it also allows your services to scale exponentially.

You can still develop CQRS with a traditional database, but you still need a HA cache for reads. Traditional databases cannot deliver the needed performance because of thread locks.

This is where elasticsearch is best suited.

Throw in a couple queues and you've got yourself a good start to a HA service.

One thing to note though. Frontends will need to be accommodating since requests to change or create data will be accepted but never completed in the original request.

IMO the problem isn't the database, it's how it's used in the architecture.

@100110111 Prepared statements completely eliminate SQLi and even before that you only had to do the proper escaping. You are right, that there is a noob trap here.

But like you can use a template engine that handles escaping for you when generating HTML, you also can just use prepared statements or Microsofts's LINQ to handle the escaping when querying the DBMS.

Sure noobs have to learn about that - like they have to learn the language and what a race condition is. Software development, like any job, comes with knowledge and skill requirements if you don't wanna botch it.

if you can't figure out the database I'm using looking at my API, there is no problem in using SQL whatsoever.

SQLi is unique to SQL because nosql isn't old enough to have it. New instances of sqli aren't common, the old ones just aren't being fixed.

Command injection as a general class of vulnerabilities can only be fixed (kinda) by enforcing that all command strings are known at compile time through the type system. I know some Rust libs that do this but not much else.

As for schema modification and other administrative queries, MySQL and Postgres have trivial ways to lock down everything that isn't purely data, I'm not sure about other DBMSes but I'd assume something similar. If you have a qualified security expert, they will know this. If you don't, you're building a proof-of-concept. If you are building a production app with mutable data without a security expert, no amount of tooling will fix you.

- JS wasn't meant to be ran on the server.

- Listerine wasn't meant as a mouth water.

- Slinkies weren't meant to keep our monkey brains occupied for ages.

Things get used for things they weren't meant to all the time.

If things get used widely for things they weren't meant to, there probably is a good reason they chose to.

@FinlayDaG33k except for JS. There still isn’t a good reason to use JS outside the browser context 😏

@100110111 or use JS at all.

HTML is insecure by default, I don't see how is it MySQL's fault. HTML post data, for example, is unsanitized and unfiltered by default. It's up to us to clean them.

this whole internet thing you all talk about is just a trend anyway. why even bother?

Development should be safe, should be easy, shouldn't require a 4 year degree to just not shoot yourself in the foot...so often... It is almost as if this is a profession that requires professionals to do the thing. Maybe we should expect developers to not be fucking pansies.