Thursday, October 23, 2014In my last post, I briefly talked about my initial experience of working as a designer in a security startup. I promised a follow-up post eventually—and here it is.
A well-designed application has to have a good balance of various components: aesthetics, usability, security, and so on. I used to think if a system works well on the surface, it's okay even if it’s flawed behind the scenes. As long as the users aren’t able to tell, it's not a big issue. This logic, however, can only work in the short term. It fails miserably in the long term. There are many examples that could be covered in this topic, but for now I want to focus on one specialty of our team: web application security.
Wednesday, October 15, 2014Docker is a new container technology that is taking Devops by storm, with many companies moving their applications from running in virtual machines (VMs) over to containers. What does Docker do? It allows you to run many containers on the same host without them interfering with each other. But unlike VMs that run an entire operating system in each instance, Docker containers can utilize the same host operating system. This way, each container only has the necessary files and tools for its specific task, giving containers and Docker an advantage over traditional VMs. For more information about how to get started with Docker, take a look at this great article: http://learningdocker.com
Above graphic from https://docs.docker.com/terms/layer/
A Docker container is the running instance of a Docker image, and a Docker image is a file system made up of multiple layer images. Docker images are created by parsing the Dockerfile. Each line of the Dockerfile runs by first creating a temporary container and mounting the previous layer images. Then the command runs inside this container and creates a new layer image. The process continues until all lines of the Dockerfile are run.
Once the final Docker image is created, all of the unnecessary intermediate layers and containers are removed. And when you modify a Dockerfile and create a new image, Docker only rebuilds layers that have changed. The rest stay the same. This can be a good thing or a bad thing depending on how you structure your Dockerfile.
Wednesday, October 8, 2014nVisium is primarily known for its software security work. A lesser known and emerging piece of nVisium's core business is software development (for nVisium products). As such, we will continue to discuss software security but will also provide blog posts on software development. This post represents a non-security, purely development focused, blog post.
This blog post assumes you are familiar with Ruby, Rails, and the Devise gem.
Monday, October 6, 2014nVisium, the leading provider of application security tools, services, and research for software development, is please to announced that Ernie Miller will join the team as Director of Engineering. In this position, Ernie will focus on building nVisium’s product suite and growing the engineering team. Ernie is an incredible talent and an established engineer, speaker, and mentor.Ernie has spoken globally from RailsClub to RubyConf and has spent his fair share of time hacking on ActiveRecord, a core dependency of the Ruby on Rails framework. Ernie’s focus on excellence, in both product and people management, along with his technical capabilities aligns perfectly with nVisium’s vision for the Director of Engineering.Ernie has previously worked with several nVisium employees, and we are excited to have him as part of our team! Aside from being a Ruby expert, Ernie also has experience in the information security industry and is extremely familiar with the high standard of application security that nVisium strives for in the products and services we provide to customers.As nVisium continues to grow its product suite, we are thrilled to have Ernie at the forefront, guiding our technical decisions and engineering strategies.Welcome, Ernie!
Wednesday, September 24, 2014The first commit to Railsgoat was on March 19th, 2013; 604 commits later, a lot has changed. New vulnerabilities added, new features written up, new lessons created—all to help hackers learn about Rails security. But the focus for Railsgoat has always been ensuring its realism and usability, and that hasn't changed. Railsgoat is still just as easy to get started and use as ever. We've even been working on some enhancements utilizing Vagrant and Docker to make setting up Railsgoat easier.
For those who don't know much about Vagrant, its purpose is to, "Create and configure lightweight, reproducible, and portable development environments." It does this through creating reusable and configured virtual machines. Docker is a Linux containerization system, and Linux containers are lightweight virtual machines that are intended to run a single process. Docker provides a light and flexible infrastructure that can be modified seamlessly. We'll talk through some of the details of the Vagrant and Docker configuration for Railsgoat.
Friday, September 12, 2014The vulnerabilities associated with mobile applications have been well documented over the last couple of years; and while developers are aware of the issues, new languages often introduce new ways of performing actions that expose old vulnerabilities.
This video explores Insecure Data Storage and Unintended Data Leakage, two common security mistakes in mobile applications. I use Swift.nV, nVisium’s open source training tool, to examine these issues in Swift, Apple’s new programming language.
For more security-related videos, visit SecCasts
Seth Law is the Director of Research & Development of nVisium and wrangles the internal and external research efforts to improve understanding of application security. He spends the majority of his time thinking up new ways to secure web and mobile applications, but has been known to code when the need arises.
For the past 12 years, Seth has been worked within multiple disciplines in the security field, from software development to network protection, both as a manager and individual contributor. During the last few years, Seth has honed his application security skills using offensive and defensive techniques, including tool development.
Wednesday, September 10, 2014This blog post will attempt to explain how Rails applications can protect themselves from Cross-Site Request Forgery (CSRF) by looking at the details of the built-in protection mechanisms.Cross-Site Request Forgery is a serious vulnerability that stems from the trust that web applications place on the session identification cookies that are being passed between browser and server. For a more detailed explanation of CSRF, I suggest looking at the OWASP guide on Cross-Site Request Forgery.Rails includes a built-in mechanism for preventing CSRF, protect_from_forgery, which is included by default in the application_controller.rb controller when generating new applications. This protect_from_forgery method leverages magic to ensure that your application is protected from hackers!Seriously though, many developers hardly recognize the threat imposed by CSRF, let alone the implementation details of the protect_from_forgery method.So, first things first, just to be clear, protect_from_forgery is not magic! There are implementation details which are important to understand. This is one of the cases where “the devil is in the details.”
- ▼ October (4)