• 7 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
  • SQL, where injection is still in the top 10 security risks

    This is absolutely true, but it's not what it looks like on the surface, and if you dig into the OWASP entry for this, you'll see they talk about mitigation.

    You can completely eliminate the possibility of injection attacks using well-understood technologies such as bind variables, which an ORM will usually use under the covers but which you can also use with your own queries. There are many, many database applications that have never once had a SQL injection vulnerability and never will.

    The reason SQL injection is a widespread security risk, to be blunt, is that there are astonishingly large numbers of inexperienced and/or low-skill developers out there who haven't learned how to use the tools at their disposal. The techniques for avoiding injection vulnerability are simple and have been well-documented for literally decades but they can't help if a lousy dev decides to ignore them.

    Now, a case could be made that it'd be better if instead, we were using a query language (maybe even a variant of SQL) that made injection attacks impossible. I agree in principle, but (a) I think this ends up being a lot harder than it looks if you want to maintain the same expressive power and flexibility SQL has, (b) given that SQL exists, "get bad devs to stop using SQL" doesn't seem any more likely to succeed than "get bad devs to use bind variables," and (c) I have too much faith in the ability of devs to introduce security vulnerabilities against all odds.


  • it would be great to “just” have a DB with a binary protocol that makes it unnecessary to write an ORM.

    Other people have talked about other parts of the post so I want to focus on this one.

    The problem an ORM solves is not a problem of SQL being textual. Just switching to a binary representation will have little or no impact on the need for an ORM. The ORM is solving the problem that's in its name: bridging the conceptual gap between an object-oriented data model and a relational data model. "A relational data model" isn't about how queries are represented in a wire protocol; instead, it is about how data, and relationships between pieces of data, are organized.

    So, okay, what if you get rid of the relational data model and make your database store objects directly? You can! NoSQL databases had a surge in popularity not too long ago, and before that, there have been lots of object databases.

    What you're likely to discover in an application of any real complexity, though, and the reason the industry has cooled somewhat on NoSQL databases after the initial hype cycle, is that the relational model turns out to be popular for a reason: it is extremely useful, and some of its useful properties are awkward to express in terms of operations on objects. True, you can ditch the ORM, but often you end up introducing complex queries to do things that are simple in SQL and the net result is more complex and harder to maintain than when you started. (Note "often" here; sometimes non-relational databases are the best tool for the job.)

    And even in an object database, you still have to know what you're doing! Storing objects instead of relational tuples won't magically cause all your previously-slow queries to become lightning-fast. You will still need to think about data access patterns and indexes and caching and the rest. If the problem you're trying to solve is "my queries are inefficient," fixing the queries is a much better first step than ditching the entire database and starting over.



  • Especially infuriating when the other person is in a very different time zone. I once worked on a project with a partner company in a time zone 10 hours ahead of mine and it was common for trivial things to take days purely because the other person insisted on typing "Hi," waiting for my "Hi, what's up?" response (which they didn't see until the next day since our hours didn't overlap), and then replying with their question, which I didn't see until my next day. Answering the actual question often took like 30 seconds, but in the meantime two or three days had gone by.

    I came to believe they were doing it on purpose so they could constantly slack off and tell their boss they were blocked waiting for my answer.




  • Depends on where I'm going, whether I've been there before, and how long my trip is, but as a rule I'll always seek out the local food and try to see a mix of famous big-name sights and weird niche things that interest me. For example, when I was in Tokyo last, I went to the top of Tokyo Tower at sunset (normal tourist sightseeing thing) and also went to see their underground flood-control tunnels.

    I don't enjoy "sit on a beach and do nothing" vacations, but more power to you if that's your style.


  • lobste.rs is an interesting case study. On the one hand, it sucked to want to join and be unable to! I was in that boat for a while. And it is also disappointingly low-volume; it can be hard to get much of a discussion going just because the user base is so small.

    On the other hand, when a discussion does get going, it has easily the highest signal:noise ratio of any technology message board I've ever participated in. Very few low-effort posts, and a high percentage of well-thought-out, respectful conversations.

    I'm not saying I think lemm.ee should follow this model, but it's not without its merits.




  • Yes, and I even have it as an automatic scheduled payment so I don't forget. Even with its flaws, it remains one of the shining gems of the Internet, and a resource I use frequently in both my professional life and my personal one. I remember how it was to suddenly want to learn more about a random topic before Wikipedia and I don't want to go back.

    I also donate to The Internet Archive.