31–40 of 41 posts
Earlier quoted context omitted.
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.
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…
It encountered an error: /var/lib/gems/2.5.0/gems/sexp_processor-4.13.0/lib/sexp.rb:222:in `line': setting s(:args).line nil (ArgumentError)
ruby 2.5.1p57
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 do offensive security. A lot of developers are ignorant of when/how React apps tend to be XSS vulnerable. Since it has a reputation as being 'safe' from XSS, devs often assume it's just something they don't have to worry about.
This has led to a small renaissance of XSS bug bounties on sites like hackerone, where you see a lot of specialists who just go around finding obvious, common XSS vulns in eg Angular apps.
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'm very unlikely to find XSS in a simple React app I do offensive security. A lot of developers are ignorant of when/how React apps tend to be XSS vulnerable. Since it has a reputation as being 'safe' from XSS, devs often assume it's just something they don't have to worry about. This has led to a small renaissance of XSS bug bounties on sites like hackerone, where you see a lot of specialists who just go around f…
It's not my argument that there's no XSS in React apps. I've definitely found React XSS. But I assume any Rails app I test will have it somewhere, and, based on experience, I do not have that assumption about React applications.
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…
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.
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.
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.
Earlier quoted context omitted.
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 "co…
I'm not trying to be pedantic; I do hear this sort of claim a lot but when pressed people rarely have anything more than pearl clutching about various metaprogramming capabilities that rarely get used outside of blog posts.
In other words, just because you can redefine + doesn't mean everyone is doing that in production code. :)
Earlier quoted context omitted.
> I'm very unlikely to find XSS in a simple React app I do offensive security. A lot of developers are ignorant of when/how React apps tend to be XSS vulnerable. Since it has a reputation as being 'safe' from XSS, devs often assume it's just something they don't have to worry about. This has led to a small renaissance of XSS bug bounties on sites like hackerone, where you see a lot of specialists who just go around f…
I do offensive security. My direct experience, in my audit workload of web applications, which I've had pretty steadily (with some short gaps) since 2005, is that XSS vulnerabilities are far rarer in React applications (regardless of backend) than they are in Rails apps. It's not hard to see why: Rails begs you to disable XSS protection to get anything interesting done in HTML (basically, any time you dip out of Erb…