41–50 of 117 posts
Earlier quoted context omitted.
How can you say everyone should be fine using a simple construct like that, have you ever had to write a complex query on a non-trivial database?
You will be able in a straight-forward way to extend this to allow any possible query.
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.
What really pisses me off about this is that you had to register just to be able to download the files. So they unnecessarily had a lot of people's username/passwords for absolutely no good reason.
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…
The database is the normative reference on what is and is not a special cased character and how escaping should be implemented. I don't think it's reasonable to assert that escaping is a concern that should be adopted by every framework that might ever talk to a database.
The examples you've provided of Rails SQLI issues are bad ones
I'm sure you could supply some better examples since your focus is in security, and there are a vast number of issues that have arisen in ActiveRecord's escaping (especially in early versions of Rails). These are merely what I quickly found while Googling.
The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface.
It's also an interface that was repeatedly and unintentionally used by Rails users to insert unescaped queries in a way that did not immediately appear incorrect, as evidenced by the preponderance of questions on the subject.
The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LIMIT and OFFSET arguments as anything but integer constants); it is also the simplest of the class of SQLI concern areas (you can solve it by blindly calling #to_i on your inputs), which also includes table names, sort orders, and column references.
Given that this conversation is occurring in the context of discussing how MySQL's design has led to exactly these types of errors, I think this is an applicable example.
Earlier quoted context omitted.
That product looks awfully similar to Metasploit ( http://www.metasploit.com/ ) , no? How is it different? I watched the demo video and couldn't really tell.
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.
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?
Earlier quoted context omitted.
That product looks awfully similar to Metasploit ( http://www.metasploit.com/ ) , no? How is it different? I watched the demo video and couldn't really tell.
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.
Earlier quoted context omitted.
You're arguing against the periphery of his point. By waiting so long to provide parameterized queries, MySQL helped foster the attitude that they were "useless enterprise bloat". The lack of parameterized queries was likely an influencing factor in the non-support or non-advertisement of parameterized-style APIs. MySQL is a crucial part of its own community. You cannot hold the community responsible for this situati…
I have never heard someone say parameterized queries were "useless enterprise bloat". Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test. Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.
I have. Usually from people with no idea what they're talking about, maybe one of us has been (un)lucky in our experience. Hopefully it's me.
> Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test.
That's great! How long has it been true, though? When I first learned PHP (2003), this was not mentioned. Maybe it existed, either in MySQL directly or as an api method, but it certainly wasn't widely advertised. Maybe looking all the way back to 2003 is stepping outside the scope of "modern" here, but I still occasionally get to deal with problems created back then.
> Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.
I'm sure it does, considering the differences in our experience of the situation.
Also, my point was not that parameterized queries are the end of SQLI defense or required for it. Just that you can't give MySQL as a company a pass on a situation they helped create. Parameterized queries are a very simple and common first step in learning to deal with SQL injection. Not implementing them for so long did not help the situation in this respect.
What really pisses me off about this is that you had to register just to be able to download the files. So they unnecessarily had a lot of people's username/passwords for absolutely no good reason.
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…
It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue. The database is the normative reference on what is and is not a special cased character and how escaping should be implemented. I don't think it's reasonable to assert that escaping is a concern that should be adopted by every framework that might ever talk to a database. The examples you've provided of Rails SQLI issues…
I don't know how to respond to any of these points.
The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?".
Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The database's simple job is to accept and execute queries.
Earlier quoted context omitted.
The database in this case has to share some of the blame. For years MySQL did not support parametrized queries or stored procedures (or did not promote them), and many of the people coding against it consistently claimed that they didn't need that kind of "enterprise crap" polluting their favorite DB. This gave way to a MASSIVE code base that is inherently vulnerable to injection attacks. So yeah, it's the fault of t…
You don't need parameterized queries or stored procedures for protection against injection. In fact they're not injection protection mechanisms at all. What you actually mean is that the database libraries should provide parameterized-style APIs. There's no need for the database's native wire protocol to explicitly support parameterization to implement this. For example Ruby on Rails's ActiveRecord provides an API th…
What?! Parameterized queries (in any competent implementation) ARE, in fact, injection protection mechanisms. Escaping != Parameterization.
Ruby on Rails is a poor example to use here - it's a trendy web language that (judging by your comment) does not use proper database practices.
Properly implemented parameterized queries offer protection against SQL injection because they seperate data from instruction - none of the data points in a query are executed, ever.
Gluing SQL instruction strings together with data from users is incredibly stupid and you should never, ever do that.
Use a framework that supports proper parameterized queries.