Live data from Hacker News

ActiveRecord Vulnerability - Circumvention of attr_protected

groups.google.com

91–96 of 96 posts

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#91

I'm building a fairly large web-product for my startup in Rails, and I'm really worried now. I'd paint the recent security vulnerabilities with one broad stroke -- someone trusted the client too much. Isn't that something really, really basic when dealing with data received from a remote client? Never trust anything? Right from the Github mass-assignment [1] vulnerability to the recent YAML & JSON parsing vulnerabili…

Now is a good time to review alternative frameworks. A lot of them are simpler to understand, rely on less magic, and have communities around them that are interested in security as well as functionality.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#92

I'm building a fairly large web-product for my startup in Rails, and I'm really worried now. I'd paint the recent security vulnerabilities with one broad stroke -- someone trusted the client too much. Isn't that something really, really basic when dealing with data received from a remote client? Never trust anything? Right from the Github mass-assignment [1] vulnerability to the recent YAML & JSON parsing vulnerabili…

Now is a good time to review alternative frameworks. A lot of them are simpler to understand, rely on less magic, and have communities around them that are interested in security as well as functionality.

No, before starting to build a product is a good time to do that.

Now is a good time to patch your code and keep building your company.

Every framework has security bugs.

Jumping ship to a framework you don't understand, possibly one that is harder to update, is a knee-jerk reactionary response to the problem.

If all these compromises worry you, invest some time in setting a HIDS (Host Intrusion Detection System), subscribing to the relevant security mailing lists, and ensuring that your deployment workflow allows you to patch production code within a few minutes.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#93
post #92

Earlier quoted context omitted.

Now is a good time to review alternative frameworks. A lot of them are simpler to understand, rely on less magic, and have communities around them that are interested in security as well as functionality.

No, before starting to build a product is a good time to do that. Now is a good time to patch your code and keep building your company. Every framework has security bugs. Jumping ship to a framework you don't understand, possibly one that is harder to update, is a knee-jerk reactionary response to the problem. If all these compromises worry you, invest some time in setting a HIDS (Host Intrusion Detection System), su…

At the end of the day, it is a trade-off: do I stick with a current framework full of security holes, indicative of poor design and keep the daily patch cycle fingers-crossed, or do I draw a line, migrate to a less magic less shiny but more secure better engineered framework and focus my time on building my apps instead of spending it all on patching. Tough call.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#94

Is stuff like this vulnerability present in Django as well, and just not being discovered as quickly, or is there something in the water (or was there years ago) in the Rails camp that caused all these bugs?

For all the complaints in the Python community that Django contains too much magic, Rails is far more magical; and that magic add complexity that allows these kinds of problems to show up. That is not to say Django doesn't have issues; it undoubtably does. I just think the hidden surface area is smaller.

Are there complaints in the Python community that Django contains too much magic? Serious question: I don't follow many Python/etc mailing lists so I'm pretty out of the loop on the general impressions people have of Django. I was kind of hoping that Django's magic-removal branch (merged all the way back in 2006!) would have helped here.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#95
post #20

I want to shamelessly give a shout-out to Ryan from our MTV team on this one; Rails ActiveModel was I think? the first real piece of Ruby code he ever looked at, and he found the permset Blacklist regex bypass (joernchen found the other one) inside of an hour. Everyone here will testify that I was no help to him at all; my contributions mostly consisted of throwing a large rubber balancing ball at him from the other…

Not to belittle Ryan's contribution, but the vulnerability he found was used in the Stripe CTF, so I have to assume he was already familiar with it. I don't believe you could randomly pick up a piece of code, not knowing the language it's written in and find this sort of thing otherwise.

At the same time it's slightly shocking that no-one has greped Rails for this kind of well-known vulnerability before, never mind auditing for less obvious ones.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#96
post #95
post #20

I want to shamelessly give a shout-out to Ryan from our MTV team on this one; Rails ActiveModel was I think? the first real piece of Ruby code he ever looked at, and he found the permset Blacklist regex bypass (joernchen found the other one) inside of an hour. Everyone here will testify that I was no help to him at all; my contributions mostly consisted of throwing a large rubber balancing ball at him from the other…

Not to belittle Ryan's contribution, but the vulnerability he found was used in the Stripe CTF, so I have to assume he was already familiar with it. I don't believe you could randomly pick up a piece of code, not knowing the language it's written in and find this sort of thing otherwise. At the same time it's slightly shocking that no-one has greped Rails for this kind of well-known vulnerability before, never mind a…

Vulnerabilities that don't trace back to common and well-known implementation mistakes are pretty rare. You're almost always familiar with the root cause of an exploitable vulnerability; the trick is finding it.
Post reply on HN