Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
1–10 of 16 posts
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#2This would be interesting from a query analytics perspective, but in terms of protection, i would personally not want to rely on something at the DB level. I would place a significant bet that this opinion is not unique to me, and it is why you do not find this built into xxSQL already.
If the 'attacker' has access to execute unsafe queries, that is a problem you should address much further up the ladder rather than by adding additional work / responsibility to your DB.
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#3Very clever. Hope to see a mysql port someday.
There's a big argument going on in php-dev right now if php should do some basic, obvious injection protection. Of course that is controversial.
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#4Very clever. Hope to see a mysql port someday. There's a big argument going on in php-dev right now if php should do some basic, obvious injection protection. Of course that is controversial.
This already exists in MySQL (enterprise) here:
https://dev.mysql.com/doc/refman/5.6/en/firewall.html
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#5This would be interesting from a query analytics perspective, but in terms of protection, i would personally not want to rely on something at the DB level. I would place a significant bet that this opinion is not unique to me, and it is why you do not find this built into xxSQL already. If the 'attacker' has access to execute unsafe queries, that is a problem you should address much further up the ladder rather than…
White it's not unique to you there would likely be many people here who are aware of the concept of trust boundaries and would appreciate this product :)
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#6I'm assuming this works for prepared queries? That is, I should be able to execute a query which is the same, aside from different values for the bound parameters. Anyway, looks pretty cool :)
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#7This would be interesting from a query analytics perspective, but in terms of protection, i would personally not want to rely on something at the DB level. I would place a significant bet that this opinion is not unique to me, and it is why you do not find this built into xxSQL already. If the 'attacker' has access to execute unsafe queries, that is a problem you should address much further up the ladder rather than…
White it's not unique to you there would likely be many people here who are aware of the concept of trust boundaries and would appreciate this product :)
Yeah you're right and I can think of several cases, especially in legacy software, where this would be helpful. I just feel that this is one of those things that delegates responsibility to a lower level component due to a flaw in one above it, with the major benefit being that no code changes are required to implement the system, but coming with the cost of increased DB CPU and IO consumption.
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#8This would be interesting from a query analytics perspective, but in terms of protection, i would personally not want to rely on something at the DB level. I would place a significant bet that this opinion is not unique to me, and it is why you do not find this built into xxSQL already. If the 'attacker' has access to execute unsafe queries, that is a problem you should address much further up the ladder rather than…
I agree with you on that, but at the same time the best security strategies are usually multi-level.
Protection at the application and access layers are always ideal but in that rare case that some major exploit comes along it would be ideal to have extra security one level deeper.
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#9Earlier quoted context omitted.
White it's not unique to you there would likely be many people here who are aware of the concept of trust boundaries and would appreciate this product :)
Yeah you're right and I can think of several cases, especially in legacy software, where this would be helpful. I just feel that this is one of those things that delegates responsibility to a lower level component due to a flaw in one above it, with the major benefit being that no code changes are required to implement the system, but coming with the cost of increased DB CPU and IO consumption.
Yes, as a DBA I would say this is one of the many reasons stores procedures are useful.
Re: Show HN: sql_firewall – SQL Firewall Extension for PostgreSQL
#10This would be interesting from a query analytics perspective, but in terms of protection, i would personally not want to rely on something at the DB level. I would place a significant bet that this opinion is not unique to me, and it is why you do not find this built into xxSQL already. If the 'attacker' has access to execute unsafe queries, that is a problem you should address much further up the ladder rather than…
I see your comment is raising some controversy, but I tend to be in your camp on this one. I do a significant amount of development involving PostgreSQL and I don't think I would want to rely on this. I don't want to belittle the work in question, but as someone that can develop for the database, I have other, better techniques which can provide defensive in depth such as injection prevention while not relying on yet another third party extension. I can set up stored procedure barriers, view barriers, and more between the data in my database and outside access from application tiers. Some of these techniques provide injection prevention as a side effect and in those cases where I do have to consciously provide such protection, I can do so in a central point of access that can service distributed application tiers.
Having said that, there are many development shops that don't have strong database development talent on hand and really treat the database as some black box where to stuff data. In these instances, the database development centric approaches aren't feasible as practical matter. In these cases, I think such a tool can be helpful since at least it gives you the choke point. Where you'd run into issues in this scenario is that this tool requires a learning period to know which queries are good and which aren't. When an application developer changes code, I would imagine that you'd have to address the SQL firewall training as well; a developer that might not be as comfortable developing for the database might not consider that factor and you might get some wonky deployments. I might be missing something on this count only having scanned the docs a bit for this extension.