Migrating to Google’s NoCaptcha ReCaptcha

posted in Engineering

Here at SendSafely we’ve been using ReCaptcha for a while now to protect unauthenticated portions of our website that may be susceptible to abuse by bots (the most notable of which is our Personal URL feature).

This month we upgraded all of our ReCaptchas to the new and improved “NoCaptcha ReCaptcha” API (officially known as ReCaptcha v2). Migrating existing ReCaptcha’s to the new v2 API was surprisingly easy. Unfortunately, our ReCaptcha code is not something we look at all that often, so we first needed to re-familiarized ourselves with the v1 implementation. As it turned out, we only needed to change a few lines of code to make our old code work with the new API. We thought we would post a summary of the steps needed to help those that haven’t made the switch but are thinking about it.  

Read More [fa icon=long-arrow-right"]

Notes about Chrome v40 and Content Security Policy Level 2

posted in Engineering

Here at SendSafely, we’ve advocated the use of Content Security Policy and have been running a fairly strict CSP in block mode for over a year now. With the release of Google Chrome version 40 this week, we wanted to highlight one important breaking change that resulted in the need for us to adapt our CSP to work with the new version of Chrome.

Read More [fa icon=long-arrow-right"]

Perfect Forward Secrecy and more…

posted in Engineering

Last month we started rolling out some subtle changes to SendSafely that many users may not have noticed. For starters, we are now taking advantage of some new SSL features that Amazon announced back in February for the Elastic Load Balancer technology that we use for handling end-user SSL connections. Our front-end load balancers now support Perfect Forward Secrecy on all SSL/TLS connections. Perfect Forward Secrecy provides additional safeguards against the eavesdropping of encrypted data, through the use of a unique random session key. This prevents the decoding of captured data, even if the secret long-term key is compromised.  With the addition of PFS we earned an A+ from SSL Labs, the highest possible rating.

Read More [fa icon=long-arrow-right"]

Summer Developer Internship

posted in Engineering

Are you a software engineering student interested in security and privacy? Are you passionate about writing secure code and working with cutting edge technologies? Do you have a strong interest in web application development? If you answered YES to any, or better yet ALL, of these questions then we’d love to hear from you!  This year we are offering a combined internship with our sister company, Gotham Digital Science (GDS).  

Read More [fa icon=long-arrow-right"]

Web-based Single Sign-On and the Dangers of SAML XML Parsing

posted in Engineering

Security Assertion Markup Language (SAML) is a popular XML-based open standard for exchanging authentication and authorization data between two systems.  In the world of enterprise cloud applications, SAML is one of the most common protocols for implementing single sign-on between enterprise customers and cloud service providers.  Given that, it’s no surprise that support for SAML-based Single Sign-on was one of the earliest requested features that our enterprise customers asked for.

Read More [fa icon=long-arrow-right"]

Bypassing Content Security Policy with Java Applets

posted in Engineering

If you’ve read our previous posts on Content Security Policy, you know that we spent a good amount of time getting our site to work using a fairly strict CSP.  Something we recently discussed in our presentation at AppSec USA was the fact that most browsers are currently ineffective when it comes to blocking Java Applet execution with CSP.  This post will share more details on what we found regarding applet execution and CSP.

Read More [fa icon=long-arrow-right"]

Slides from OWASP AppSec USA

posted in Engineering

In case you missed the presentation by SendSafely’s Brian Holyfield and Erik Larsson at OWASP AppSec USA, we’ve posted a copy of the deck in our GitHub repository.  Brian and Erik discussed some of the challenges we faced here at SendSafely when implementing Content Security Policy (CSP) on our site.  There will also be a video recording of the talk posted in the AppSec 2013 YouTube Channel.

Read More [fa icon=long-arrow-right"]

AppSec USA 2013 in NYC!

posted in Engineering

Next week SendSafely will be at the 2013 OWASP AppSec USA conference, right here in New York City.  If you are interested in attending and not already registered for the conference you can do so on the AppSec USA website at http://appsecusa.org/2013/. The talks looks great and we couldn’t me more excited about it being hosted in our very own hometown!

Read More [fa icon=long-arrow-right"]

Avoiding Residual SSH Keys on Ubuntu AMIs

posted in Engineering

If you’ve ever used Amazon EC2 to run Linux, you probably know that the AWS console prompts you to choose an SSH key-pair when spawning a new Linux instance.  Public/private key pairs allow you to securely connect to your instance using SSH after it launches. On Ubuntu Linux, the SSH public key is made available to the instance by the Ubuntu CloudInit package.  This package is installed on all Ubuntu Cloud Images and also in the official Ubuntu images available on EC2 (https://help.ubuntu.com/community/CloudInit).  It runs at boot time, and adds the SSH key to the default user's ~/.ssh/authorized_keys file.  

Read More [fa icon=long-arrow-right"]

Using Content Security Policy to Prevent Cross-Site Scripting (XSS)

posted in Engineering

On SendSafely.com we make heavy use of many new JavaScript APIs introduced with HTML5. We encrypt files, calculate checksums and upload data using pure JavaScript.  Moving logic like this down to the browser, however, makes the threat of Cross-Site Scripting (XSS) even greater than before.  In order to prevent XSS vulnerabilities, our site makes liberal use of pretty aggressive client-side and server-side encoding APIs.  These APIs are based on the OWASP ESAPI library, so we have context-specific encoding methods for pretty much every scenario.   Even so, we recognize that it is very difficult to rule out all possible ways to inject code, including a human error on our part. For this reason we chose to also implement Content Security Policy (CSP) on SendSafely.com.

Read More [fa icon=long-arrow-right"]