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

21–30 of 41 posts

Re: Attacking Ruby on Rails applications (2016)

#21

Post by thrownaway954 »

Polylactic_acid wrote: post #15
tprynn wrote: post #12

Earlier quoted context omitted.

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.

https://github.com/presidentbeef/brakeman

link to mentioned app for those interested.

Re: Attacking Ruby on Rails applications (2016)

#22

Post by mytailorisrich »

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…

It should be said that an "unscoped find" is a generic and serious design flaw, which isn't specific to Rails.

Re: Attacking Ruby on Rails applications (2016)

#23

Post by dmamills »

1propionyl wrote: post #19
1vasari wrote: post #18

Earlier quoted context omitted.

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.

The year is 2020, developers demand decent tooling for authoring and publishing plaintext.

Re: Attacking Ruby on Rails applications (2016)

#24

Post by rst »

mytailorisrich wrote: post #22
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…

It should be said that an "unscoped find" is a generic and serious design flaw, which isn't specific to Rails.

It's on the current OWASP top ten as one case of "Broken Access Control" (scenario 1): https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top...

(In at least one prior edition, it had an entry of its own as "Insecure Direct Object Reference".)

Re: Attacking Ruby on Rails applications (2016)

#25

Post by [deleted] »

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…

[deleted]

Re: Attacking Ruby on Rails applications (2016)

#26

Post by capableweb »

dmamills wrote: post #23
1propionyl wrote: post #19

Earlier quoted context omitted.

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.

The year is 2020, developers demand decent tooling for authoring and publishing plaintext.

Pretty sure anyone working in plaintext is using something better than ed or similar. emacs, vim, and many others are plaintext editors. It's not hard to imagine we can come up with even better tools for it as well.

Re: Attacking Ruby on Rails applications (2016)

#27

Post by tptacek »

rst wrote: post #24
mytailorisrich wrote: post #22

Earlier quoted context omitted.

It should be said that an "unscoped find" is a generic and serious design flaw, which isn't specific to Rails.

It's on the current OWASP top ten as one case of "Broken Access Control" (scenario 1): https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top... (In at least one prior edition, it had an entry of its own as "Insecure Direct Object Reference".)

At some point before that, it was known as "forced browsing", though that name took on a more particular meaning and then fell away. It is by far the most common software vulnerability.

Re: Attacking Ruby on Rails applications (2016)

#28

Post by tptacek »

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…

In practice, XSS is largely mooted by the rise of front-end frameworks like React, Vue, and Angular, which are the modern norm for delivering UI (I don't think we have a single client that uses serverside-templated-HTML anymore), and the front-end framework approach is better than the Rails/Django approach; I'm very unlikely to find XSS in a simple React app, but not at all unlikely to find it in a Rails app, because people always dip out of the XSS protection to do programmatic tags.

Re: Attacking Ruby on Rails applications (2016)

#29

Post by adrianmsmith »

tptacek wrote: post #28
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…

In practice, XSS is largely mooted by the rise of front-end frameworks like React, Vue, and Angular, which are the modern norm for delivering UI (I don't think we have a single client that uses serverside-templated-HTML anymore), and the front-end framework approach is better than the Rails/Django approach; I'm very unlikely to find XSS in a simple React app, but not at all unlikely to find it in a Rails app, because…

I think making the mistake of "unscoped find" that "atom_enger" was referring to is just as easy a mistake to make when writing a REST backend (to support a SPA front-end framework) as when using a traditional non-SPA web framework.

It's tempting, when writing a REST backend, to respond to e.g. "PUT /message/:id" by just executing "UPDATE ... WHERE message_id=?" from the parameter, without checking that that message belonged to the user whose credentials have been used to access the call.

That's possible with a non-SPA web framework, and it's also possible when writing REST backends.

Re: Attacking Ruby on Rails applications (2016)

#30

Post by tptacek »

adrianmsmith wrote: post #29
tptacek wrote: post #28

Earlier quoted context omitted.

In practice, XSS is largely mooted by the rise of front-end frameworks like React, Vue, and Angular, which are the modern norm for delivering UI (I don't think we have a single client that uses serverside-templated-HTML anymore), and the front-end framework approach is better than the Rails/Django approach; I'm very unlikely to find XSS in a simple React app, but not at all unlikely to find it in a Rails app, because…

I think making the mistake of "unscoped find" that "atom_enger" was referring to is just as easy a mistake to make when writing a REST backend (to support a SPA front-end framework) as when using a traditional non-SPA web framework. It's tempting, when writing a REST backend, to respond to e.g. "PUT /message/:id" by just executing "UPDATE ... WHERE message_id=?" from the parameter, without checking that that message…

Authz bugs are the most common bugs in every application, and no framework has a particular edge on stamping them out. I'm just responding to the claim about Rails having a security edge due to XSS protection, which it does not; in fact, it's become somewhat the opposite.
Post reply on HN