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.
Like this kind of articles?
Subscribe to hear about new Rails security resources first. Only helpful articles and guides. Monthly(ish) updates, no spam.
