191–200 of 220 posts
Earlier quoted context omitted.
Asking Steve Jobs a question is going to require a very impressive in-band signaling hack on a system that appears to have no such vulnerability.
Asking Jobs is pretty easy. It's getting an answer that's difficult.
Earlier quoted context omitted.
the ORM escapes the parameter but it lets you specify bits of SQL by hand (think "select foo, myfunc(bar) as BAZ, joineds.quux as quux"). In theory when you do that you have already given up on letting the framework handle it for you, and you must take care of not feeding raw user input as the select code, for example. The issue here is that the option to do this is exposed in a functionality where people do not expe…
Well, the Django ORM also allows you to write SQL by hand and if you make a mistake you can fall pray to SQL injection, so I'm assuming that there's something different about this exploit. From what I understand the current issue appears because the person who implemented the faulty method uses SQL directly and doesn't pass the parameters separately. In Python, you would do something like this: execute('select name,…
The orm supports building the sql piecemeal, e.g
find(select: "name, foo(bar) as baz",
conditions: 'x=y',
limit: 3)
select("name, foo(bar) as baz").
where('x=y').
limit(3)
Now remember that ruby Rails has this (antipattern imo) of accepting arguments in a dozen way for some methods e.g.
find(1)
find(:first)
find([1])
find(1,limit: 1)
And AR has dynamically generated finders (which Django does not have AFAIR).
One would expect the dynamically generated finder to be doing
def find_by_foo arg
where(foo, arg).limit(1)
end
def find_by_foo *args
many_options = args.extract_options!
opts = combine_with_foo_handling(many_options)
find(opts)
end
Notice that, as others already pointed out, usually as a user you shouldn't be able to create custom objects of the kind that exploits this issue (an hash with symbols as keys) unless your have other vulnerabilities already.
Earlier quoted context omitted.
The problem is that ORMs like ActiveRecord really are just domain specific languages for building queries. If these DSLs use inband are carelessly constructed (e.g. they use some form of inband signaling) you can do the injection attack against the actual ORM code and make it build queries the author of the code did not intend.
http://sqlalchemy.org/ is an ORM and does not have these security issues. So it can be done.
One could lament that the real issue is the (maybe not so) accidental complexity (and hidden deep down complexity lies insecurity) that results when you're using utter non-sense like an ORM. The very concept of an ORM is broken. I know most devs don't know SQL well enough to do more code directly from SQL and I know most devs don't know anything else than SQL... But it's a bit sad to see all these "frameworks" tailor…
The 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-...
Earlier quoted context omitted.
Well, the Django ORM also allows you to write SQL by hand and if you make a mistake you can fall pray to SQL injection, so I'm assuming that there's something different about this exploit. From what I understand the current issue appears because the person who implemented the faulty method uses SQL directly and doesn't pass the parameters separately. In Python, you would do something like this: execute('select name,…
the thing that is different is that the raw sql facilities are made explicitly available not through the common methods that expect them, but through something else. The orm supports building the sql piecemeal, e.g find(select: "name, foo(bar) as baz", conditions: 'x=y', limit: 3) this is a small step above a raw execute, and obviously ugly and low level. Also a somewhat obsolete practice, since for a few years you c…
Post.objects.filter(some_field_name=some_value)Earlier quoted context omitted.
354 matches. https://github.com/search?utf8=%E2%9C%93&q=secret_token....
did you even look at what was matched? Change the cookie secret token at config/initializers/secret_token.rb Create a config/initializers/secret_token.rb file: That will rename your app in the following files: ... config/initializers/secret_token.rb Change your Application’s Secret Token ... Change the secret token at /config/initializers/secret_token.rb Those are the first six items in order and the trend continues…
Earlier quoted context omitted.
Well, the Django ORM also allows you to write SQL by hand and if you make a mistake you can fall pray to SQL injection, so I'm assuming that there's something different about this exploit. From what I understand the current issue appears because the person who implemented the faulty method uses SQL directly and doesn't pass the parameters separately. In Python, you would do something like this: execute('select name,…
the thing that is different is that the raw sql facilities are made explicitly available not through the common methods that expect them, but through something else. The orm supports building the sql piecemeal, e.g find(select: "name, foo(bar) as baz", conditions: 'x=y', limit: 3) this is a small step above a raw execute, and obviously ugly and low level. Also a somewhat obsolete practice, since for a few years you c…
(in a manager)
def find_by_foo(self, arg):
return self.filter(foo=arg)[:1]Earlier 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…