Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Attacking Ruby on Rails applications (2016)

phrack.org

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Attacking Ruby on Rails applications (2016)

#11

Post by Polylactic_acid »

atom_enger wrote: post #6

I remember reading this when I was the sole Infrastructure Engineer for Reverb.com. I knew we were being attacked and I knew we had issues but I didn't have any idea where to start. This article sparked my interested in Cyber Security and helped me find a bug in the website that allowed me to set the CEO's credit card as a primary card on my account in production. That was an amazing day. All I had to do was modify a…

The unscoped find issue is fairly easily solved by using devise's current_user in combination with something like cancancan. Let them send anything as a param but have the controller blow up if the user doesn't have permission to access it.

I suspect an insane number of websites are validated only by the frontend and can be exploited like this.

Re: Attacking Ruby on Rails applications (2016)

#12

Post by tprynn »

Polylactic_acid wrote: post #10
dwheeler wrote: post #5

If you're using Ruby on Rails, you should be using a static code analyzer to look for vulnerabilities. Please take a look at Railroader, an OSS tool I maintain that does this (and contributors are wanted!): https://railroader.org/ I recommend that you also use a web application scanner like OWASP ZAP and something to scan your dependencies for known vulnerabilities (e.g., bundle audit or GitHub's scanner). That is in…

Static code analyzers don't seem to find too much interesting in my experience. They could basically only find string interpol in queries and uses of constantize. Ruby is just too dynamic to find any really interesting issues.

Really? I find that brakeman is a pretty amazing tool which finds a number of surprising issues. Of course, these days the vast majority of Rails apps already have brakeman set up, so it's used more as part of the commit process and less of a "wow, here's a few dozen potentially high-impact web vulns". I wouldn't hesitate to say that it's the most high-signal SCA tool I've used across any language/framework.

(source: a few years of webapp pentesting and Rails app dev)

Re: Attacking Ruby on Rails applications (2016)

#13

Post by peteforde »

gargarplex wrote: post #8

I figure, if you ever want to attack a Rails app (white hat on), go through the CVE list and try every vulnerability. There's been so many with exploit codes and it's dubious that every single service is patched.

I figure, if you want to attack literally any app, go through the CVE and try every vulnerability.

I don't think it's defensible to claim that Rails itself is inherently more vulnerable than other similar systems. If you disagree, feel free to cite references.

Re: Attacking Ruby on Rails applications (2016)

#14

Post by peteforde »

atom_enger wrote: post #6

I remember reading this when I was the sole Infrastructure Engineer for Reverb.com. I knew we were being attacked and I knew we had issues but I didn't have any idea where to start. This article sparked my interested in Cyber Security and helped me find a bug in the website that allowed me to set the CEO's credit card as a primary card on my account in production. That was an amazing day. All I had to do was modify a…

Don't get me wrong: I'm really glad that you caught the bug in your code before anyone lost an eye.

However, a critical summary of your situation could be "improperly used an advanced method that exists for the specific purpose of marking a string as having been certified safe, potentially allowing an XSS that would have otherwise been successfully filtered out by Rails' extensive anti-XSS mechanisms".

I was super upset when one of the drives in my RAID 0 set went, but it was still my bad for not learning that RAID 0 isn't mirroring. (Hint: the 0 is the amount of information you can recover in case of failure.)

My point is just that you can't really claim that Rails dropped the ball here. If there are footguns installed, it's because you installed them (and didn't read the manual for html_safe).

Re: Attacking Ruby on Rails applications (2016)

#15

Post by Polylactic_acid »

tprynn wrote: post #12
Polylactic_acid wrote: post #10

Earlier quoted context omitted.

Static code analyzers don't seem to find too much interesting in my experience. They could basically only find string interpol in queries and uses of constantize. Ruby is just too dynamic to find any really interesting issues.

Really? I find that brakeman is a pretty amazing tool which finds a number of surprising issues. Of course, these days the vast majority of Rails apps already have brakeman set up, so it's used more as part of the commit process and less of a "wow, here's a few dozen potentially high-impact web vulns". I wouldn't hesitate to say that it's the most high-signal SCA tool I've used across any language/framework. (source:…

I ran brakeman on our app and it found a bunch of things that were almost vulnerabilities because it was unable to work out the source of some data going in to a potentially unsafe function but after I inspected all of them, none of them were actual vulnerabilities. Meanwhile a bunch of real issues go undetected that could have been spotted in a language like rust.

Re: Attacking Ruby on Rails applications (2016)

#17

Post by slimed »

tprynn wrote: post #12
Polylactic_acid wrote: post #10

Earlier quoted context omitted.

Static code analyzers don't seem to find too much interesting in my experience. They could basically only find string interpol in queries and uses of constantize. Ruby is just too dynamic to find any really interesting issues.

Really? I find that brakeman is a pretty amazing tool which finds a number of surprising issues. Of course, these days the vast majority of Rails apps already have brakeman set up, so it's used more as part of the commit process and less of a "wow, here's a few dozen potentially high-impact web vulns". I wouldn't hesitate to say that it's the most high-signal SCA tool I've used across any language/framework. (source:…

The bar is low for such tools regardless of programming language. In a language as dynamic as Ruby it's several miles into the Earth's crust. The tool won't be able to tell you much of anything you shouldn't already know. "Potentially high-impact web vulns" is a next to useless metric when provided by such a tool. The rate of false positives is high. A distraction such as this when your application surely has more serious vulnerabilities is not helpful.

Re: Attacking Ruby on Rails applications (2016)

#19

Post by 1propionyl »

1vasari wrote: post #18
hajimuz wrote: post #16

I like the format of this post very much. Plain text yet clean and navigatable. Is there any tool for this?

No. It's plain text

I think you've missed the point of what they were asking... which is probably if there are tools to facilitate authoring and publishing in plain text.

Re: Attacking Ruby on Rails applications (2016)

#20

Post by 1propionyl »

peteforde wrote: post #13
gargarplex wrote: post #8

I figure, if you ever want to attack a Rails app (white hat on), go through the CVE list and try every vulnerability. There's been so many with exploit codes and it's dubious that every single service is patched.

I figure, if you want to attack literally any app, go through the CVE and try every vulnerability. I don't think it's defensible to claim that Rails itself is inherently more vulnerable than other similar systems. If you disagree, feel free to cite references.

The question isn't whether a framework is or is not more vulnerable than other similar systems.

It is whether using that framework courages developer behavior that produces more or less vulnerabilities.

Ruby in general almost certainly does encourage dangerous developer patterns, however I doubt that's the case for Rails in particular as it has largely been practically a DSL for nearly a decade.

As a corollary of "convention over configuration" and dominant patterns in popular accessory frameworks however, this only applies so long as you don't try to be too clever.

Post reply on HN