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:
An interesting read about race conditions on the interweb.
An example of automatic security gone too far, in my opinion. Allow all parameters in production that were ever used in development?
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.
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.
Should you use Ruby’s SecureRandom?
- 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.
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).
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:
- “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
Set up Let’s encrypt, nginx and security headers
XSS from ad networks on a security researcher’s blog
Rails sends the recommended setting by default, but an interesting read.
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 in links to remove access to the window JS object when linking with target=_blank
Remote Code Execution in git client and server
The web app security questionnaire that Google uses to assess vendors
A basic security checklist from all levels with quick wins
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:
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
This reminds us that Rails XSS protection only works in Erb, other cases still need manual escapes according to the context.
Do you really have SSL 2 disabled on your web server? Another SSL attack with a catchy name.