Ruby on Rails web security digest #16

It feels like after summer, the amount of security news increases again. Yes, also on the Rails security project, a few new articles about other forms of injection. Oh and here interesting reads from elsewhere:

The Dropbox hack is real

Yes the Dropbox hack is real and this is proper journalism – verified and cross-checked before publishing.

Mitigating MIME Confusion Attacks in Firefox

Firefox now also supports the X-Content-Type-Options: nosniff against MIME-type sniffing.

Protecting your embedded content with subresource integrity (SRI)

Using subresource integrity (SRI)? Here’s how to add a fallback.

Did you like attr_accessible? Someone ported it to Rails 5.

Google Chrome, Firefox Address Bar Spoofing Vulnerability

A spooky browser vulnerability turns URLs around if it sees an RTL string.

Let’s look at some of the security at Github

Some security features at Github, including a hack for dangling markup.

The target=”_blank” vulnerability by example

Antivirus Uploads with Clamby

Interesting Rails and web application security reads #15

Ah yes, two new Rails security vulnerabilities last week. I guess you already updated Rails, right? Good, so on to this week’s interesting web app security reads:

Death by copy/paste

Are we copying too many security solutions without really understanding them?

CloudFlare, We Have A Problem

Opinion on CloudFlare: No real DDoS mitigation and breaking the TLS model.

Testing the HSTS preload process

How long does it take to get on the HSTS preload list („I want this site to be always HTTPS, also for the very first request“)? About 8 days it seems.

Malware in the browser: how you might get hacked by a Chrome extension

Hiding secrets in a Vault

Secrets in the configuration: Can be stored in Vault.

stronger_parameters

This is an extension of strong_parameters with added type checking and conversion.
PS: Do you know anybody who might benefit from this kind of posts? Please share it with them.

Web security reading list (summer edition) #14

I’m back! I hope you’re having a great summer. So let’s go straight to this week’s interesting security-related reads:

Race conditions on the web

An interesting read about race conditions on the interweb.

Active Params

An example of automatic security gone too far, in my opinion. Allow all parameters in production that were ever used in development?

Typosquatting programming language package managers

Typosquatting gems: Don’t install coffe-script, urllib2, req7est. This guy uploaded 200+ packages with similar names as popular gems to illustrate the „typosquatting“ problem.

Why you shouldn’t share links on Facebook

Don’t message secret URLs on Facebook, e.g. Google Docs because links shared via Facebook Messenger reveals the URL in a publicly accessible API.

Making Content-Security-Policy great again

Common mistakes, bypasses and a look at CSP 3.

Autocomplete=off is ignored on non-login <input> elements in Chrome

Here’s the WontFix answer from the Chrome team.

Ruby on Rails security reading list (password hack edition) #13

With a lot of attacks against Twitter passwords, VK and LinkedIn recently (or not so recently), it became also clear that people use the same passwords for different services. On Tuesday, someone used those password lists to sign into Github. Is this a reason for apps to provide or promote Two Factor Authentication?
Ah, and here are this week’s articles worth reading:

Rails 5 changes protect_from_forgery execution order

Self-Destructing Cookies

Another safe-browsing add-on to delete all cookies when you close a tab in Firefox.

Should you use Ruby’s SecureRandom?

There’s a discussion about the security of the SecureRandom Ruby module going on. Some researchers now recommend using a different gem.

Ruby authentication: Secure your Rack application with JWT

Hack: XSS via a Facebook page name

A reminder that XSS really can happen anywhere.

HelpSpot Vault

Service to send encrypted messages that expire.
PS: This newsletter grows only by word of mouth. If you think someone could be interested in it, please use the sharing (Twitter, E-Mail) below. Thank you!

The bigger picture review and Rails security reading list #12

Let’s start with an article that describes how someone took over locked Instagram accounts by changing an ID. That’s interesting because I discovered something similar in another app very recently. I think this is why it’s important to regularly review the bigger picture. In this case, that means asking: „What if someone skips a few steps of the ‘locking-an-account‘ workflow and just changes an ID?“.
And now for (not so) completely different articles:
How to inspect the magic bytes of images to fix some problems with the branded vulnerability ImageTragick.

Pastejacking

You think you’re copying an innocent command in the browser, but it’s evil.

Harden Firefox security settings

OS X Security and Privacy Guide

 A practical guide to securing OS X.
How to store secrets in a git repository

The Origins of the <Blink> Tag

This is not related to security, but from the history book. The origins of the <blink> tag: Someone was drunk

Typical privilege escalation, CSP and Rails security reading #11

Last week I came across this typical privilege escalation vulnerability. This type of problem happened in about 30% of the Rails apps that I reviewed. It goes like this:
  • 2 users have access to 2 different projects
  • 1 resource in each project (web hooks in this case)
  • User 1 and 2 can access /projects/1/hooks/1 and /projects/2/hooks/1 even though one of them shouldn’t
  • That’s because the resource controller uses ProjectHook.find(params[:hook_id]), so it’s not scoped to the project.
 Let’s go and fix similar problems. But now for something completely different:
Only .37% of the top million Alexa sites use a Content-Security-Policy. Is it time to start implementing one?

Same-site Cookies

New: Same-Site cookies are sent only when using a web app directly, not through a request from a third-party website. With them, CSRF attacks won’t be possible anymore, because a request from a different site won’t be as a signed in user anymore. This is supported in the newest Chrome and Opera versions (and was before through general browser settings).

A cheesy name for multiple vulnerabilities in the popular ImageMagick (e.g. through rmagick, paperclip): Remote Code Execution, delete and move files, SSRF, read local files.
The page we’re linking to with target=’_blank’ gains partial access to the source page via the window.opener object.
Let’s Encrypt is not beta anymore.

Rails and web security reading + how to filter redirects #10

Do you know the Rails.application.config.filter_redirect filter? It’s an undocumented configuration feature which lets you filter certain redirect URLs from your log files. This is handy when you’re redirecting to a URL with tokens in it so that they don’t show up in the log. A bit like config.filter_parameters.

Add the following to a new initializer and it will show “Redirected to [FILTERED]” in the log for redirects to a URL that contains that string. That means it will filter https://example.com, http://www.example.com and the like.

Rails.application.config.filter_redirect = ['example.com']

But now on to this week’s interesting (Rails) security articles:

 

CSV Injection in business.uber.com

Hack: Do you provide CSV exports, here’s an interesting hack with Excel method injection. A reminder to escape/sanitize according to the context.
Github added a feature for verified commits using PGP signatures.
Whitelisting input data from a short dictionary with #presence_in.
Gems with a dash in the name could possibly be hijacked, check yours, even if it’s not very likely.
The Content Security Policy HTTP header Github started with and what it looks like now.
A long-established enterprise security guideline is to frequently change the password, the British CESG advises against it now.
Subresource Integrity (SRI) against hijacked JavaScript files from CDNs and how to calculate the hash with various tools.

Rails and web security reading (with Gmail security lessons learned) #9

So what did the Gmail team learn while protecting their app?
  • “Prevent vulnerabilities through product design”
  • “Empower users to take action through a meaningful feedback UI”
  • “Any defense can be defeated – use defense in depth with multiple layers of protection”
  • “Detection systems are imperfect – implement catch-up mechanisms”
  • “Make it hard for attackers to understand your defenses”
  • “Implement an emergency system“ as a last resort
And now for other interesting reads:

Let’s Encrypt & Nginx

Set up Let’s encrypt, nginx and security headers

How I got XSS’d by my ad network

XSS from ad networks on a security researcher’s blog

The misunderstood X-XSS-Protection

Rails sends the recommended setting by default, but an interesting read.

Secure websites shun HTTP Public Key Pinning

HTTP Public Key Pinning not widely adopted, also because a small mistake could wipe out an online business

Uber bug bounty: Turning self-XSS into good-XSS

How self-XSS can still be used to affect other users

Rails security reading digest #8: Admin panel, checklists and link security

Do you have an admin panel? Then you might be interested in my recent article @codeship: How to protect a sensitive area of your application with mutual TLS authentication. That means the client also authenticates itself against the server with a client-side certificate. The full nginx web server configuration is available here.

Now, what was worth reading recently:

About rel=noopener

About rel=noopener in links to remove access to the window JS object when linking with target=_blank

Let’s encrypt with a Rails app on Heroku

 

Remote Code Execution in all git versions (client + server) < 2.7.4: CVE-2016-2324, CVE-2016‑2315

Remote Code Execution in git client and server

 

Vendor Security Assessment Questionnaires

The web app security questionnaire that Google uses to assess vendors

 

Securitychecklist.org

A basic security checklist from all levels with quick wins

Rails security digest and review reminders #7

The latest Rails security fixes were another reminder that we shouldn’t rely too much on a framework to solve everything security for us. The fix was for controller code like render params[:id] which makes it possible to render every file on the server. It also reminds that all user input is potentially tampered with.
Let’s take a second every time we use user input and think about what class it could potentially be: Fixnum, String, Array, Hash, nil, a blank string. Then we can look up the render method (link to Rails version 4.2.1) and see that it accepts a Hash. params[:id] can be a Hash, too.

Other interesting articles:

Kill your dependencies, less gems in Rails, less security worries.

 

Acceptance of FIDO 2.0 Specifications by the W3C accelerates the movement to end passwords

 

A few notes how Quora moved to HTTPS

Here’s an another extensive TLS configuration wiki page from Mozilla.

Rails 5 ActiveModel before_ callbacks will not halt when returning false, possible security implications

 

Beware: Server-side APIs for Client-Side Rendering and Cross Site Scripting (XSS)

This reminds us that Rails XSS protection only works in Erb, other cases still need manual escapes according to the context.

The DROWN attack

Do you really have SSL 2 disabled on your web server? Another SSL attack with a catchy name.