Hacker News Reader

Comment by mcfunley | Hacker News Reader

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got some bad advice and thought you were safe from sql injection if you wrote your sql inside stored procedures. This misconception got wildly out of hand.

We stopped writing sprocs and migrated to MySQL over many years instead. I'm happy with the decision. The database isn't a good place to put things that need extensive unit testing.

Or at least it isn't if you're a giant consumer-facing website. YMMV.

View on HN

Why the migration to MySQL rather than just migrating away from the stored procedures?

We hired some key employees from Flickr who knew a particular MySQL sharding strategy really well. Postgres would have worked fine, just not the way we were using it back then.

I'll probably never understand why people believe that a stored proc is not subject to injection attacks. Like they're magic or something.

Because if you use the input parameters correctly they are immune to injection.

If you concatenate unsanitized input you are susceptible no matter where you write the SQL.

I get that. That is exactly the same condition as sanitizing inputs in every other context of passing parameters to a service/proc/func. I would not phrase immunity to injection conditionally; there is no immunity, only sanitizing inputs.

Though that's also true if it's done application-server side.

Yup. Examples: value stored in a table is concatenated into a query without escapement, leaving it vulnerable to injection. Whose job was it to ensure the DB contained clean data? My policy has been to call quote_identifier or quote_literal (PostgreSQL) where applicable, or use typecasts to enforce value literals.

Ya PostGIS is dumb and worthless. You should only use your db as a dumb data dump. You shouldn't even bother with keys.

Reply on news.ycombinator.com