Christoper Rigor has posted a good set of Ruby on Rails Security 17-Item Checklist on Engine Yard’s blog. Check it out.

He did a good job hitting the important ones without being overly verbose.

If you’re looking for a standard to follow, check out the OWASP ASVS.

Your Internet Service Provider has direct access to the type of information on you and your family that the National Security Agency uses for spying.

Your ISP knows when you are at home and when you are not, when your kids are doing their homework. They know or can know what you’re watching on Netflix (even when its encrypted) and YouTube. If any member of your household ever views pornographic content, your ISP knows how much and at what times such content is accessed. They can infer through traffic analysis how many people are living at your home and even know how many iPhone and Android devices that you have. And even though they cannot see into your encrypted search queries on Google, your ISP knows every medical website that you visited to research a condition that you think you have or are looking into a drug that your doctor has prescribed to you.

Dear Honorable Members of the United States Congress:

I work in application security in the cybersecurity field to make software more secure from attack. The cybersecurity threats that face our nation are very important to my wife and me. As Americans, our private data is in great jeopardy because of increased cybersecurity threats. Our infrastructure is prone to being hacked, and major data breaches of both private and government networks are routinely in the news. The best way to prevent these breaches is to increase the use of strong encryption with no backdoors.

The track record of data breaches demonstrates an uncomfortable truth: when sophisticated adversaries want to hack a network, they will ultimately win. Among the few tools known to computer science that can prevent a data breach is strong encryption. This means that there is no backdoor and no backup key. Either the original user needs to enter the password, or the data is un-retrievable.

Earlier this month I had the honor of speaking with information security students at Kennesaw State University in Georgia thanks to Dr. Herbert Mattord. It is a very diverse class with both traditional students and more mature students who are switching careers. Most of the students had little or no professional software development experience so I view these talks as extra critical because infosec professionals play an important role in this by working with developers and thus need to know something about how software is made.

It’s been a few months and I wish I had shared the link with you sooner. Back on August 29, 2016, I was the guest of Joe Gray’s Advanced Persistent Security Podcast’s Intro To App Sec Episode.

We talked about application security and the news. Give it a listen!

Tim Kadlec has written a fantastic blog post that you should read right away at https://snyk.io/blog/mongodb-hack-and-secure-defaults.

It starts with: “If you have a MongoDB installation, now would be the time to verify that it is secure. Since just before Christmas, over 28,000 public MongoDB installs have been hacked. The attackers are holding the hacked data ransom, demanding companies pay using Bitcoins to get their data back. From the looks of it, at least 20 companies have given in and paid the ransom so far. This post explains the hack, how to protect yourself, and what we can learn from it.”

This is a topic that I’ve found to be important in my work with clients. I’ve written about it privately and even Tweeted along these lines. Hats off to Mr. Kadlec for publishing this. One of my friends, Bennie, had found a great analogy for the Mongo situation saying that “as is true in many cases with everything, it is pilot error! The big difference is people are able to ‘fly’ software without giving proof they’ve had ‘flying’ lessons!”

Other Items

Before Christmas, I posted some new videos up at https://rietta.com/learning/appsec. Namely the first two lessons in a new series of security in software development. Start to learn how developers can help prevent a data breach and the roles of blue, red, and purple teams in software development.

One Last Thing

Please let me know your application security questions and I will do my best to answer, possibly by video!

As a fun little experiment, I ran the same CPU benchmark on a few processors that I have around my home office that come from various generations. The Raspberry Pi was predictably beaten by even the nine year old AMD Athlon processor, but considering its from factor and power usage it is a remarkably versatile little system on a chip.

Today marks the 28th anniversary of the Morris Worm, which devastated large portions of the nascent Internet on November 2, 1988. Even though it was unleashed nearly three decades ago, it was more advanced than the Mirai worm that compromised hundreds of thousands of IoT devices in recent weeks.

The Morris Worm source code on a floppy disk was on display at the Computer History Museum in Mountain View, Calif. Photo licensed under Creative Commons from Intel Free Press, © 2013.

Further Reading

• Lessons from the First Major Computer Virus (2013)
• In 1988, One Rogue Worm Shut Down 10 Percent Of The Internet (2015)
• A tale of two worms, three vulnerabilities, and one National Security Agency (2016)

I originally started drafting this post on January 14, 2012, but it sat unpublished since then. Its fun to look back at ones journey, 1743 days ago. In 2012, I was relatively new to the Ruby on Rails platform after having worked in PHP and SQL for years, as well as a little .NET. The platform has been a good choice that I enjoy working with still to this day. I was working in Rails 3 at the time and had completed at least three client websites in Rails in 2011.

Anyway, let’s take a look at the little lesson that I had started to write about over 4 years ago.

How to Handle Maximum Lengths for User Supplied Input

Stop annoying users by appearing to allow more text in a field than supported!

The default length of a string in an ActiveRecord model is 255 characters. By default the text_field helper will allow the user to enter more. As a user, one is incorrectly to think that he or she can enter more text than is allowed and it is silently truncated by the web app. Stop it, seriously.

Do it by two easy steps:

1. Set the maxlength and size attributes on your one-line text fields.
2. Validate the length of the text fields in your model.

In the View:

1

  <%= f.text_field :first_name, maxlength: 255, size: 30 %>

In the Model:

1
2
3
4
5

  validates :first_name,
    presence: true,
    length: {maximum: 255},
    on: :create,
    allow_nil: false

Conclusion

Even today in 2016, many Rails developers leave maximum length validation out of their Rails models. This is a mistake. If you are using PostgreSQL, then validating that a string is no more than 255 is even more important because a string that is longer will cause the model to be reported as valid and yet PostgreSQL will raise an exception on save. This will lead to data loss and the dreaded “Something Went Wrong” 500 error page for your users unless you handle the length validation properly.

The 2016 Verizon DBIR report is out and is available for download. Among the findings is the prevalence of data breaches that are attributable to stolen authorization credentials.

According to the report “63% of confirmed data breaches involved weak, default or stolen passwords” (page 20). This is an increase from 2015, when the stat was that 51% of web application breaches were attributable to stolen credentials. If anything is clear, it’s that the lowly credential theft is a clear and present danger in information security. It is responsible for more incidents than all the other exotic, technically interesting attacks combined.