41–50 of 220 posts
It seems like this is being conflated with the session token issue? How do you submit params with symbolized keys? Hashes are easy enough, but it doesn't work with hashes that have strings as keys, only symbols. EDIT: Just to be clear, tenderlove (Ruby/Rails committer) confirms that you do not need to edit the session to exploit this ( http://news.ycombinator.com/item?id=4999767 ). It's still unclear how it is possib…
This isn't a problem if you check the type of data you get from a user before you use it. You should be doing that anyway. The article says a work-around is to use .to_s or .to_i on user input. My standard practice is to cast to int for all IDs I get externally (in PHP too). Some projects I work on go so far as to validate type and data ranges of every argument passed in. Those applications would therefore not be vul…
"You should be doing that anyway." A huge selling point of Rails, other web frameworks, and ORMs in general, is that you don't have to be doing these checks. You can push the query through without concern of SQL injection, and handle the failure case there. This is convenient because you often have to handle that failure case anyway. Rails' own "Getting Started" guide uses this technique because it's assumed to be se…
Earlier quoted context omitted.
Different vuln; this one has nothing to do with session cookies.
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.
Earlier quoted context omitted.
History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.
Look no further than the deprecated 5ESS switches which used to give up free calls due to 2600hz tones being signaled inband. Ask Steve Jobs and Woz about BlueBoxes; you need look no further to see the inherent dangers on inband signaling. Slightly off-topic, but still relevant IMHO.
Earlier quoted context omitted.
The main issue stems from Ruby using the last positional parameter to pass a hash representing keyword arguments. This means if there's only one parameter, and someone can sneak a Hash in there where you weren't expecting it (params parsing, request body parsing, etc) then they can end up passing dodgy 'keyword arguments' into your method call.
You can pass a hash (dictionary) to represent kwargs in Python. This seems like bad engineering fundamentals in the design of ActiveRecord for it to be perpetually subject to this sort of thing.
Eh, sure but you need to explicitly pass the dict as a kwarg with a double-asterisk, or else it's just a normal positional parameter.
In Ruby prior to 2.0, there is no formal concept of kwargs, so there is no distinction between passing a Hash as the last positional parameter and passing kwargs. This is the root problem, and I look forward to it going away when everyone moves to 2.0.
I am mostly a Django programmer so excuse my ignorance of rails. How does this keep happening? In Django you would do: Post.objects.get(pk=request.GET['id']) There really is no way to do SQL injection this way. This line in rails looks almost exactly like how you would do it in Django: Post.find_by_id(params[:id]) Also this seems really serious. It's not like a edge case where you need to grab a post by id. This is p…
[deleted]
That is why Python has kwargs. Those two stars stand out like a sore thumb and when you are passing positional arguments in the form of a hash it is pretty apparent.
I am mostly a Django programmer so excuse my ignorance of rails. How does this keep happening? In Django you would do: Post.objects.get(pk=request.GET['id']) There really is no way to do SQL injection this way. This line in rails looks almost exactly like how you would do it in Django: Post.find_by_id(params[:id]) Also this seems really serious. It's not like a edge case where you need to grab a post by id. This is p…
This generally happens in one of two says:
1) (most common) You have a SQL statement that takes a user-provided parameter and you compose your SQL statement as a string, including that parameter (eg., sql = "SELECT * FROM person where id = " + form.id, or similar). This is typically solved by using parametric, prepared statements. Basically, you prepare a SQL statement that contains "?" for the parameter values and then bind values to the statement.
2) (Common in ORM frameworks) A user provided string is used to compose some other (non-parameter) piece of the SQL statement, such as a column or table name. This is usually caused by laziness. Rather than combining the string provided by the user (form values, URL components, etc.) you should instead look up the string to use from some internal data source, such as a list of domain classes, etc., and use that instead. In that way, the data that is user provided is kept entirely separate from data that will be executed.
You'll hear a lot of people talk about "why isn't this being escaped". And, frankly, it's a good question. But the real question is "why are you trusting data that could come from anywhere on earth?". Don't take it for granted that only your users will be sending queries to your application.
The code you write for Django (Post.objects.get(pk=request.GET['id']) is only secure from 1 and 2 if the framework is written in an appropriate manner to avoid trusting user provided data.
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.
ps. This type of problem applies to any kind of "data that is executable", be it strings passed to an "eval" function or strings passed to a web browser. SQL is just a giant eval() function.
Earlier quoted context omitted.
The main issue stems from Ruby using the last positional parameter to pass a hash representing keyword arguments. This means if there's only one parameter, and someone can sneak a Hash in there where you weren't expecting it (params parsing, request body parsing, etc) then they can end up passing dodgy 'keyword arguments' into your method call.
In Python, the parameter escaping is done at the level of the database driver not the ORM. Isn't this the case with Ruby? Of course, you could use the driver incorrectly to risk SQL injection, but that is a very obvious mistake that no experienced developer would make.
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 expect it (dynamic finders) and thus people may be passing risky input there.
It seems like this is being conflated with the session token issue? How do you submit params with symbolized keys? Hashes are easy enough, but it doesn't work with hashes that have strings as keys, only symbols. EDIT: Just to be clear, tenderlove (Ruby/Rails committer) confirms that you do not need to edit the session to exploit this ( http://news.ycombinator.com/item?id=4999767 ). It's still unclear how it is possib…
Rails param parsing automatically converts all param keys to symbols.