Four weeks ago, we blogged about the issue with Rails’ built-in anti-CSRF mechanism, protect_from_forgery, where we calculated that over 50,000 Ruby developers were impacted by Cross-site Request Forgery (CSRF) attacks.
There’s been some buzz recently about protect_from_forgery, Rails’ built-in anti-CSRF mechanism, and how it’s not secure by default. Having found, evaluated, disclosed, and tried to fix issues with it in the past, we decided to perform a thorough evaluation of how severe the problem was.
According to a blog post made on 18f, it is a standard to ensure all federal websites and web services to serve only via secured connections (HTTPS). Yet in its recent study, about 6.1% of the domains do not have HTTPS enabled. Package managers have, in the past, deprecate certain commands/features that defaults to HTTP. RubyGems has deprecated
source :rubygems in
Gemfile due to the insecurity of HTTP, and recommends the explicit use of HTTPS.
In this post, we will highlight the issues of insecure network connection(s) made by open-source libraries during build time. Also, we introduce an open-source monitoring tool, Build Inspector, that can be used to detect insecure network traffic made during the build process. Finally, we analyze the number of affected builds from a sample pool of open-source repositories.
A few days ago, I found a CSRF vulnerability in rails_admin. rails_admin is a Ruby gem that generates administrative interfaces for your models automatically. Interestingly, this vulnerability is similar in nature to the one I found in administrate, a similar gem. Additionally, past Ruby gems affected in a similar fashion can be explored at this link.
Ransomware is a growing pernicious threat. Some ransomeware called ‘Locky’ was recently discovered spreading through Facebook Messenger, and just last weekend San Francisco’s light-rail system was compromised by ransomware. Today we’ll take an in-depth look at how ransomware can target developers, proliferating through library dependencies.
We’ve got a present for you this week. This is the biggest release of SourceClear since we launched, and we can’t wait for you to dive in. Thanks to everyone who’s ideas and feedback have helped shape this release, and a special thank you to all of our beta testers who have shown us how crucial SourceClear is in helping teams build secure software.
If you’re not using SourceClear yet, today is a great day to sign up. Here is a rundown of all the new features being released today:
Package and dependency managers like npm allow command execution as part of the build process. Command execution provides an easy and convenient mechanism for developers to script tasks during the build. For instance, npm allows developers to use pre-install and post-install hooks to execute tasks. A pre-install hook can be used to compile some dependent native library before starting the build. A post-install hook can be used for clean up after the build.
In this blog post, we demonstrate how an attacker can use npm to exfiltrate information from the developer’s machine. Although we show the attack scenarios for npm, similar attacks can also be done on other package managers like gradle.
Don’t trust user input. That’s a core security tenet for building secure software. In our web applications we sanitize text input to protect against XSS, and verify uploaded files are free of malware. But what happens when you take user-submitted software and execute whatever it tells you to do? That’s essentially what Continuous Integration environments are made for. If the tests say to count to 10, the system counts to 10. If it says to download software and start mining for Bitcoin, that’s exactly what it’ll do.
Misbehaving or even malicious builds are a difficult threat for CI environments to protect against. Continuous Integration services are essentially asked, every day, by every customer, to run random pieces of software. If you run a CI system at your company, you’re doing the same. To help identify these potentially dangerous builds, we’ve been working on a project called Build Inspector.
As a Data Scientist at SourceClear I get to analyze lots of interesting vulnerability data as well as anonymized project data. New customers often ask us what “normal” looks like when it comes to vulnerabilities in their projects, so I thought I’d take a look and share a few insights.