Earlier quoted context omitted.
by that logic php is rock solid
75% of web servers run on it, I think thats a pretty solid mark
source?
SQL Injection Vulnerability in Ruby on Rails; affects all versions
181–190 of 220 posts
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#182Earlier quoted context omitted.
I've been going through the code for ActiveRecord and now AuthLogic. I'm admittedly not well versed in Ruby. However from the description of the vulnerability found at [1], it would appear as though the cookie value can be set to a Ruby string value that is then parsed by server to produce a Ruby Hash value (rather than the AuthLogic plugin's assumed string value). Is the eval() of the cookie value done by Rails or i…
[deleted]
[deleted]
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#183The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability? You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup? You do know that if someone has your app's secret key they can just write whatever…
Did a quick write-up on the conditions required to exploit this: http://blog.pentesterlab.com/2013/01/on-exploiting-cve-2012-...
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#184Earlier quoted context omitted.
Yes, clearly, because Rails has introduced absolutely no other kind of default protection . Is this an argument for hand rolling your own code, or for using some other framework that is apparently immune (or, to be charitable, has a stronger security track record)?
Likely its an argument to use parameterized queries which fix the SQL injection problem altogether. I'm not familiar with Ruby, but surely they support it in 2013?
Actually, no, not if you're using the mysql2 gem. There is an open issue / pull request but it doesn't seem to have much momentum.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#185Earlier quoted context omitted.
I've always found Rails to be easy to secure compared to most other frameworks. I think the defaults are all pretty secure. I'd prefer having constant security patches. It shows people are still constantly testing it for vulnerabilities.
SQL injection is the web-equivalent of having a stack allocated buffer overflow. We have built and use (expensive) abstractions that supposedly eliminate these whole class of issues. With Rails, you get the expensive abstraction and apparently none of the security.
This is silly. The stinger on this vulnerability is SQL injection, but the vulnerability itself is closer in spirit to code injection. The issue here isn't database hygiene. Parameterized queries would not have helped.
There's a real critique of Rails to be leveled here (there is some fucked up stuff going on with Rails request processing), but yours isn't it.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#186Earlier quoted context omitted.
>The fact that this keeps happening on Rails is the #1 reason I haven't bothered to take the time to do anything real with it. I don't have the time to read the code for the framework and I don't trust that it's written with security in mind. What frameworks do you use? Have you performed your own audit?
Totally fair question. I personally prefer not to use ORMs for this specific reason: they are typically way too complicated to be able to plow through the code in any reasonable way. It's also generally not that hard to design your application in such a way that using a minimalist "ORM-ish" layer of your own making isn't exactly a waste of time. I've also found that they rarely follow these best practices (it's madde…
I think this kind of view point is mostly influenced by having to deal with poorly designed ORMs and (tho occasionally very necessary) convoluted database designs.
> For world-facing code, ORMs are risky unless you've got someone on the team who knows it and has the ability to ensure it doesn't suffer from these types of design flaws.
This I think is wrong, for the same reason you don't want to be putting together your crypto package. If anything, these kind of security vulnerabilities demonstrate just how hard it is to get all of the subtleties pinned down. Rails is used widely and has been inspected by far more domain experts than you'd ever have on your team and yet.
Sometimes ActiveRecord gets a little in the way - especially back when has_and_belongs_to_many associations were considered best practice - but for the most part I haven't been able to empathize with these kinds of claims. AR is really flexible and gives you a lot of functionality for free.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#187Earlier quoted context omitted.
> user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack How do you implement authentication if you can't check an email (user provided data) matches a password (user provided data, probably hashed but still)? How do you look up blog posts by a user-provided tag, without using that tag in query composition? How do y…
Simple: use parametric prepared statements instead of composing a SQL string with the user-provided data (escaped or otherwise). This has been available in numerous database APIs for like, ever. For example [1], [2], [3]. Any actual web developer will have read something along the lines of [4]. A lot people seem confused by my original post, which was in response to a Django user's question about how this sort of thi…
The attack is targeting a secondary method signature that #find_by_* can hold with the express purpose of executing arbitrary SQL. That is, when #find_by_* is invoked with a hash with a key such as :select or :conditions it expects a SQL string, probably hard coded.
The bug however is that it's possible for user input, with a session hijacking, to provide that hash with symbolic key. There is no SQL injection, this is straight up arbitrary execution of SQL.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#188The more I read these stories (and not just in Rails, though they seem to be the most talked about), the more I seriously consider taking the time to evaluate frameworks such as Yesod where the type system makes these kinds of security flaws impossible.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#189Earlier quoted context omitted.
Stupid question, but how was that not discovered until now? That seems quite major, or something that the developers would have tested for ..
The vulnerability doesn't get triggered normally. As the grandparent said, request parameters are stored in an object of class HashWithIndifferentAccess, which stores all keys as strings. For the vulnerability to be triggered, the keys must be symbols. You cannot trigger this vulnerability unless your have written code in your app which converts the HashWithIndifferentAccess to a normal hash. This patch does not fix…
Thanks for the great explanation, Sir widget.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#190Earlier quoted context omitted.
tenderlove mentions it has been assigned CVE-2012-5664. This is that CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5664 It references two articles that require session secrets.
Yes, the article does mention session secrets. However, this exploit does not require session secrets. The person who wrote the blog post wrote about essentially two vulnerabilities: session forging and SQL injection.
No, the guy showed a way to to sql injections by using a forged session. The problem is that the sql injection requires a hash with symbols as key and params are stored in HashWithIndifferentAccess which should not symbolize the keys. So to exploit the SQL injection you need a vector that allows you to inject symbolized keys. It might be possible to corrupt the params hash, but I can't think of any at the moment. However, the session can contain any ruby object and thus is a possible vector.