71–80 of 117 posts
Same guys hit Sun.com via SQL Injection as well - http://tinkode27.baywords.com/sun-com-sun-mycrosystems-vulne... Shameless self plug: Netsparker ( My startup: http://www.netsparker.com/ ) could have identified both of these vulnerabilities.
You're right: that's an annoying plug. Please don't do that.
Earlier quoted context omitted.
You're right: that's an annoying plug. Please don't do that.
Why? It's a pretty relevant plug -- I think that's ok!
But, more to the point, how annoying would it be if every time I responded to a comment on HN, I added "this is one of the many things we take care of it you get us to review your applications"?
When threads are about products, I think it's fine --- helpful, even! --- to point out competing offerings and alternatives. But on news stories, let's just keep the commercial offerings off the threads.
Earlier quoted context omitted.
Metasploit mostly focuses on Infrastructure and exploiting known vulnerabilities. Netsparker is solely focused on web application security (detection & exploitation). For example Netsparker can crawl AJAX/Javascript apps, support form authentication etc. Metasploit on the other hand possibly will never do that kind of stuff.
You are comparing a $1000 commercial product to open source Ruby code. Metasploit is sponsored by Rapid7, which does in fact have a product that is competitive with your offering. Do we need to get into a detailed discussion of why I think the plug for your scanner is inappropriate for this thread? Or can we just let it suffice to say that HN isn't a great place to promote products on random threads?
We have a good relationship with Rapid7 guys, they even has a module to import Netsparker results into Metasploit and we keep getting synced with them in new updates.
> Or can we just let it suffice to say that HN isn't a great place to promote products on random threads?
Personally I love seeing other HNers to send their relative products, projects, startups, commercial ideas, job ads in HN threads, I don't think there is anything wrong with that. You might think otherwise, that's why there is one upvote and one downvote button.
Earlier quoted context omitted.
> You don't need parameterized queries or stored procedures for protection against injection ... There's no need for the database's native wire protocol to explicitly support parameterization to implement this. This means that every protocol client must implement their own query escaping, rather than relying on the database to provide a single, normative implementation of escaping. > For example Ruby on Rails's Activ…
It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue. The examples you've provided of Rails SQLI issues are bad ones: * The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface. * The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LI…
"You can solve it by blindly calling #h on your outputs"
Ouch. We know that scheme doesn't work too well: it's why we had #h and we now have #html_safe...
Earlier quoted context omitted.
You are comparing a $1000 commercial product to open source Ruby code. Metasploit is sponsored by Rapid7, which does in fact have a product that is competitive with your offering. Do we need to get into a detailed discussion of why I think the plug for your scanner is inappropriate for this thread? Or can we just let it suffice to say that HN isn't a great place to promote products on random threads?
I'm not comparing, I'm telling the difference. Just like Netsparker will not do port scanning, possibly Metasploit will not do full web app stuff. You can talk with someone from Rapid7 and they'll tell you the same thing. And for the record I love Metasploit, it's a fantastic tool. We have a good relationship with Rapid7 guys, they even has a module to import Netsparker results into Metasploit and we keep getting syn…
I'm responding harshly because I do not agree with your logic (to wit: any thread involving security is a great place to plug your scanner) and because I found your comparison of Netsparker to Metasploit disingenuous: Metasploit simply isn't Rapid7's web app offering.
Earlier quoted context omitted.
It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue. The examples you've provided of Rails SQLI issues are bad ones: * The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface. * The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LI…
> you can solve it by blindly calling #to_i on your inputs "You can solve it by blindly calling #h on your outputs" Ouch. We know that scheme doesn't work too well: it's why we had #h and we now have #html_safe...
In case we're misunderstanding each other, I'm also saying that the framework should be doing that, not the caller (as was the case with h()).
Earlier quoted context omitted.
Could you expand a bit on how parameterized queries are not sufficient for defense against SQL injection (assuming, of course, that developers use the escaping and do not concatenate unescaped data into queries)? As for them being required -- you can obviously escape queries yourself, but the normative reference for escaping is the target database itself, and reproducing escaping locally in the client brings with it…
Not every "input" to a "query" (using these terms loosely) can be bound as a variable. Simple example: ASC and DESC. There are trickier examples that are still common. It is a bad idea for applications to implement quoting regimes, and it is a bad idea for frameworks to try to create one-size-fits-all quoting regimes like PHP used to. That doesn't mean it's a bad idea for a framework's e.g. MySQL support to provide t…
Oracle's security team bear full responsibility for this breach. MySQL's founder Monty Widenius left Sun in 2005. Sun declined, Oracle bought them as a strategic buy and the portal has been neglected to the point of being compromised. One wonders what internal neglect MySQL is suffering behind the corporate veil.
Earlier quoted context omitted.
Who downloads MySQL from their site?
Who downloads MySQL?
But I agree. Most of the time, I prefer PostgreSQL.