Subresource Integrity

If you’ve been keeping up with recent browser developments you may have noticed that in the past few weeks both Chrome and Firefox have started to support subresource integrity, with companies like Github making an active push for other sites to make use of the functionality. This is a low-risk change that offers tremendous security gains for your users, so we just pushed out an update that makes it easier to start using subresource integrity on your website.

Subresource integrity is a new browser feature that allows websites to ensure the integrity of resources loaded from external sources, such as content delivery networks (CDNs). This is a common technique used by websites to speed up the loading of assets, including common Javascript libraries like jQuery.

As is the nature of loading arbitrary code, this has always opened up websites to the possibility of being attacked through their CDN: an insecure or malicious CDN holds the potential to insert malicious code onto any website to which it serves assets. Subresource integrity serves to mitigate this attack by ensuring that all loaded resources contain the exact content expected by the website. This is done through the use of a cryptographic digest, computed on all fetched resources, that is then compared against an expected digest. This provides the browser the capability of detecting resources that have been tampered with, allowing it the opportunity to abort the loading of the resources before any malicious code is executed.

Protecting a resource is done by adding the “integrity” attribute to an asset’s HTML tag:

<script src="https://example.com/include.js"
        integrity="sha256-Rj/9XDU7F6pNSX8yBddiCIIS+XKDTtdq0//No0MH0AE="
        crossorigin="anonymous"></script>

It’s an elegant solution to a very serious risk, and it’s a solution we recommend implementing. It won’t secure all of your users, with Microsoft Edge still not supporting the feature, but it can serve as a valuable line of defense in the event of a breach of your CDN. Many of the popular web frameworks provide libraries that make it easy to enable subresource integrity on your assets, and further instructions on making use of the technology are available on the Mozilla Developer Network.

Going forward, all Tinfoil Security scans will flag external resources that are not protected by subresource integrity. Give it a try by signing up for our 30-day free trial.


Shane Wilton

Shane Wilton is the Grand Magistrate of Security at Tinfoil Security, and the company's resident programming language theorist. When he isn't coding in a functional language like Elixir, he's probably hacking on an interpreter for an esolang of his own, or playing around with dependent types in Idris. Security is always at the forefront of his thoughts, and he enjoys building tools which make it easy for other engineers to write secure code. His love for security is matched only by his love for bad movies - and does he ever love bad movies.

Tags: browser security security New Feature


Tinfoil Security for Microsoft Azure

Tinfoil Security is proud to announce a brand new partnership with Microsoft Azure, to provide their customers unparallelled web application security for their Azure Web Apps—the first such security solution to be offered on the Azure Marketplace. Microsoft has long been known for making it incredibly easy to build and deploy web applications, but customers always had to go elsewhere to ensure those same applications were safe and secure. Now, with the launch of this exciting partnership, it’s never been easier for you to secure your application. Tinfoil Security is built into your Azure Web Apps management portal, and can be set up with just the click of a button.

Microsoft Azure provides its customers industry-leading protection at the network and data-center level, but previously offered no web application security solutions. Now, with the aid of Tinfoil Security, Microsoft Azure’s customers finally have an easy way to secure their entire software stack.

Starting today, you can secure your Azure Web Apps by continuously scanning them for vulnerabilities. You’ll be scanned for over 60 types of vulnerabilities, including the OWASP Top 10, and we’ll provide detailed instructions on fixing every vulnerability we find.

Furthermore, we’ve added the ability to convert your scan results into ModSecurity rules. ModSecurity is a web application firewall (WAF) that Microsoft Azure includes as part of their Web Apps Service; think of ModSecurity as a layer in front of your application that inspects requests and decides whether or not to block them based on rules you’ve configured. As of today, you can enable our ModSecurity rules to help prevent attacks while you fix each underlying issue we discover. Tinfoil and Azure make this process easy, fast, and consistent.

Tinfoil has always had a great respect for Microsoft and, specifically, for the Azure team. When we first interacted with them back in 2013, we were left with the distinct impression that we shared both vision and goals: an extreme focus on the user experience, an intention to make development easier than ever before, and an understanding that security is a necessary and paramount part of the development process, especially as more and more companies continue to get breached and lose sensitive customer data.

This partnership has been a long time coming. We explored many different routes as we investigated how we could best offer our best-in-breed security and couple it with Azure’s top-notch build and deploy user experience. We’re proud to announce what we genuinely believe is the most valuable solution to Azure and Tinfoil customers alike.

We hope you’re as excited as we are about this exciting new offer for Microsoft Azure customers, so please don’t hesitate to let us know what you think.

Click here to get started on securing your Microsoft Azure Web Apps today.

If you’re not on the Azure platform, or if you want to integrate security deeper into your development and DevOps process, feel free to check out our main product at https://www.tinfoilsecurity.com.


Michael "Borski" Borohovski

Michael Borohovski is cofounder and CTO at Tinfoil Security. He got his start in security when he was just 13 years old, and has been programming for longer than he can remember. When he's not busy breaking software or building it, he also loves singing, juggling, and magic tricks. Yes, magic tricks.

Tags: security website scanning Launch azure microsoft


DevSec: Empowering DevOps with Security

We’ve had an interesting journey over the past few years at Tinfoil. Each year technology evolves, but security is often left behind. As more of you scan with us, we see more issues with current security processes. The biggest problem? Agile development.

We love pushing code often. We’ll make changes to our website or scanner on a daily (and sometimes hourly) basis. As a small team we’re able to run our security tests pre-deploy without a problem, but have noticed a large gap amongst our customers. Over the past year we’ve worked with some of the best and largest enterprise companies to establish a new security practice: empowering DevOps with security and bringing it closer to the source.

Security teams are small, much smaller than development teams. Some companies have a single person thinking about security issues and others have hundreds. A few years back either was OK. New code was deployed once every few months and went through a full QA and penetration testing process. With continuous integration systems and DevOps teams forming, security can’t keep up. New code is deployed daily, if not hourly, and security has yet to become a part of the testing process.

Tinfoil is now working with security teams to relieve some of the pressure so they can work on the big picture. Starting with our web application scanner, you can now pull Tinfoil into your DevOps process without adding any extra burden. Many customers use our API to hook into their CI systems, and we’re working on specific integrations with tools like Jenkins and CircleCI to make the process even easier. These integrations are set up so as soon as new versions of a website are pushed out, Tinfoil scans are run. As we find vulnerabilities we have many ways to export the data, including directly into your JIRA or issue tracker so your developers can fix the problems right away. Our goal is to simplify security while not compromising security.

DevSec is the joining of DevOps and security. Your engineers should feel empowered with security, not burdened by it. We’ll be posting a series of posts on best practices for getting your development teams up and running with a DevSec process. As always, you’re welcome to use Tinfoil to supplement this process. We welcome questions and feedback as we explore this new focus shift. Email or chat with us anytime.

Looking forward to more years of interesting adventures and challenges.


Ainsley Braun

Ainsley Braun is the co-founder and CEO of Tinfoil Security. She's consistently looking for interesting, innovative ways to improve the way security is currently implemented. She spends a lot of her time thinking about the usability and painpoints of security, and loves talking with Tinfoil's users. She also loves rowing and flying kites.

Tags: security business advice new features DevSec DevOps


Stop Paying For SSL Certificates You Don't Need

Securing your stack with a SSL/TLS doesn't have to be costly or time consuming. There are two sides to TLS: Public Key Infrastructure (PKI) and Public Key/Asymmetric Cryptography. Hopefully your public network data is already encrypted with SSL/TLS (leveraging Public Key Cryptography), but you can also leverage a PKI to easily gain additional security wins for your internal network traffic.

SSL/TLS is most frequently used for encrypting data on the wire. You want to prevent the person next to you at Starbucks from being able to see your password as you submit a login form on the WiFi. It is used to verify the identity of a web server -- peer verification. You want to know that data going to and from www.tinfoilsecurity.com actually is coming from our servers, and not from someone else's. Early on in the TLS handshake your browser (and any underlying library like OpenSSL) does most of the heavy lifting for you: checking that the certificate's CommonName or SubjectAltNames matches the hostname and verifying the chain of trust. However, a tragically rarely used feature of SSL/TLS is that the client also has the opportunity to present a certificate during the handshake and the server can use it to verify the client's identity as well.

Why doesn't every browser present a certificate to every SSL website identifying the visitor as me? It certainly would make logins simple, but the rub comes with trust -- any certificate could identify the user as Ben Sedat. Public Key Infrastructure tries to solve this, and if both the website and client trust an authority to sign the certificates and keep track of them then you can establish a trusted link and make it a lot harder to forge fake things into the system.

Websites do this by requesting a certificate from a set of known Certificate Authorities. Browsers and operating systems keep lists of valid CAs and alert you when the certificate's chain of trust isn't valid. These CAs charge for their services, usually anywhere from $10 to $100 a year. Both you and your website's visitor trust the CA and everything works well, at least until it doesn't. What isn't widely publicized is that you can easily set up your own CA.

This CA isn't going to be trusted by your website visitors, but your infrastructure can trust it as long as you keep it safe. All too often we see companies and services disabling SSL entirely. They think that they need an expensive certificate, signed by a well-known CA. In the case of a website with clients that aren't under your control, that may be necessary. However, if you have more direct control over the client (like if you're your own API client) you can establish who you want to trust. Many libraries, like the Ruby hooks around OpenSSL and SSL connections allow you to specify which certificate authorities you want to trust in addition to the system defaults.

There isn't a perfect security system but you can easily add hurdles to delay and frustrate an attacker. SSL encryption of internet traffic is one such hurdle, and enforcing client/server identities on top creates one more hoop an attacker has to jump through to be successful. A client certificate isn't the be-all-end-all either -- it can be combined with usernames/passwords, two-factor authentication on another device, or all sorts of other methods to harden a system even more.

Go Forth and Make Your Own CA

OpenSSL is the de-facto standard command line utility for dealing with certificates. At Tinfoil we also really like XCA (http://sourceforge.net/projects/xca/); it's open-source and provides a (mostly) usable UI over the somewhat arcane OpenSSL invocations. Creating a CA and some certificates is easy in XCA, and once you're done you can have pieces of your application authenticating each other and keeping the communication secure.

  1. Creating a certificate authority
    First secure your XCA database (and private keys) with good password(s). Keep these safe, and don't put it anywhere digital! This is a critical layer of security for your CA.

  2. Generate your CA's private key
    Choose a nice long key here. There's some debate over key sizes regarding performance but it's worth it to go big here unless you're constrained by an embedded device. 1024-bit is considered too small, with 2048-bit being better currently but eventually breakable. 4096-bit may take a while to generate the key but it's worth it. It's also worth noting that RSA keys are more performant while encrypting, while DSA is faster for signing requests. ECDSA uses elliptic curve, which allows for smaller keys but is more computationally intensive.

    Creating a CA key

    The equivalent openssl incantations (for newer OpenSSL versions it may be easier to use the genpkey command):
    RSA: openssl genrsa -des3 -out blogCA-key.pem <bytes>
    DSA: openssl dsaparam -out blogCA-params.pem
             openssl gendsa -des3 -out blogCA-key.pem blogCA-params.pem
    ECDSA: openssl ecparam -out blogCA-params.pem
                 openssl ecparam -genkey -in blogCA-params.pem -out blogCA-key.pem
                 openssl ec -des3 -in blogCA-key.pem -out blogCA-key.pem

  3. Generate your CA's public certificate
    Choose the CA template and Apply All of the extensions. This flags your new certificate as a Certificate Authority, which some clients care about when evaluating the chain of trust. Also give it a commonName, essentially an identifier for your certificate, and choose an end date fairly far in the future.

    Creating a CA Certificate
    CA Certificate Options

    Via the command line:
    openssl req -new -x509 -days 730 -key blogCA-key.pem -out blogCA-cert.pem

  4. Generate a server certificate
    You can generate the private key, request, and certificate for a server application all within XCA. For bonus points, you can generate the private key and request on your server/clients directly, transfer just the request over, sign it with the CA and transfer the certificate back to the server. This prevents the private key from ever going on your network, although secure tunnels like SSH can make this process safer.

    Creating a server key
    Creating a server certificate request

    Create the private keys via CLI:
    RSA: openssl req  -newkey rsa:<bytes> -keyout server1-key.pem -out server1.csr
    DSA: openssl req -newkey dsa:blogCA-cert.pem -keyout server1-key.pem -out server1.csr
    ECDSA: openssl req -newkey ec:blogCA-cert.pem -keyout server1-key.pem -out server1.csr

    Signing the request via CLI:

    openssl x509 -CA blogCA-cert.pem -CAkey blogCA-key.pem -CAcreateserial \
    -days 365 -req -in server1.csr -out server1-cert.pem

    You can repeat this process for your servers, and/or your clients. Now you have all the credential pieces to have pieces of your infrastructure reveal themselves and verify each other during communication.

  5. Validating the trust
    Now it's time to use the certificates in your infrastructure. Standard peer verification from the client's perspective checks against the requested hostname, but in (cloud) infrastructure that could be a frequently changing target. One option is to use a load balancer behind a CNAME. Another option when you are your own client is to check the common or subject names in the provided certificate and validate against those and your certificate authority.

    There can be some gotchas in the minefield of secure SSL communication, especially as we're using the commonName as a service identifier rather than just matching the hostname. Some examples below perform peer verification from the client's perspective with that in mind. Feel free to send along any equivalent ones in other languages and I'd be happy to credit and include them.

    Sample ruby client code, with sockets:
    require 'socket'
    require 'openssl'
    
    context = OpenSSL::SSL::SSLContext.new
    context.verify_mode = OpenSSL::SSL::VERIFY_FAIL_IF_NO_PEER_CERT
    
    store = OpenSSL::X509::Store.new
    store.add_file 'blogCA-cert.pem'
    
    context.cert_store = store
    context.verify_callback = proc do |preverify, ssl_context|
      raise OpenSSL::SSL::SSLError.new unless preverify && ssl_context.error == 0
    end
    socket = TCPSocket.new('service.example.com', 8080)
    
    ssl_connection = OpenSSL::SSL::SSLSocket.new(socket, context)
    ssl_connection.connect
    ssl_connection.post_connection_check('server1') # Check the CommonName or AltSubjectNames
    # SSL Connection Ready for Use Now
    Sample ruby client with Net/Http:
    require 'net/http'
    require 'openssl'
    
    store = OpenSSL::X509::Store.new
    store.add_file 'blogCA-cert.pem'
    
    Net::HTTP.start('service.example.com', 8080, :use_ssl => true, :verify_mode  => OpenSSL::SSL::VERIFY_NONE) do |http|
        # Our own verification, as net/http uses hostname validation. Sadly, the flag for this (https://github.com/ruby/ruby/blob/trunk/lib/net/http.rb#L658) is unchecked
        raise 'Possible MITM' unless OpenSSL::SSL.verify_certificate_identity(http.peer_cert, 'server1')
        raise 'Bad trust chain' unless store.verify(http.peer_cert)
        # SSL Connection Ready for Use Now
    end

It's worth taking a moment to go over some basic CA security. Like a real CA, you need to keep your CA's passphrase and private key secret. I recommend taking a page from Bitcoin wallet private key protection and put the private key on some cold storage, like a VM or flash drive that you can keep entirely off the internet.

Expiration dates are the other gotcha of this type of security. Generating new keys and certificates should be easy now, so you can use a shorter certificate lifespan before you have to rotate them. If you use a calendaring solution it's worth it to put in a reminder a few weeks before the certificate expires so you remember to renew. Don't get caught unawares.

That's the basics of creating and using your own CA! For extra credit, you can post your CA's certificate revocation list someplace and check against that as well. Certificate Authorities are fairly easy to set up and provide extra hurdles of identification if someone has intruded on your network and wants to man-in-the-middle your network traffic.


Ben Sedat

Ben Sedat is the Engineering Wizard of Tinfoil Security. He's a bit of a blend between a traditional software engineer (builder) and security engineer (breaker). He spends a lot of time thinking about security: both detection as well as creating solutions for the security issues that exist in software and the internet. He also plays lots of video games. Lots.

Tags: security SSL guide


Building A Browser Extension? Be Careful Not To Accidentally XSS the Whole Internet.

Update/TL;DRIf you didn’t generate it, assume it’s malicious.

Sometimes, the state of your website’s security can be affected by resources and services outside your control. The topic of today? Browser extensions.

Recently, we disclosed a vulnerability to a well-known company (let’s refer to them as Company) in their browser extension (specifically, in Chrome). To their credit, Company responded rapidly and fixed the issue within 2 days - major props to them for responding so quickly. Before we get into the vulnerability, let’s talk a little about what the extension does.

Chrome extensions? Not much harm can come from that...

From the Company’s feature description, the browser extension automatically takes content you want to share and pops it into a message, ready to go. This sounds great! And for the most part, it is. Occasionally, though, we are reminded that extensions can be dangerous, and now is one of those times. Browser extensions are effectively allowed to run any arbitrary JavaScript they’d like on any page you visit, changing the DOM at will. In Company’s case, they were trying to make their customers’ lives easier by finding any text that looked like a Twitter hashtag or Twitter handle and converting it into a clickable link that automatically searches for that hashtag or handle. Well-intentioned, as is most of what we do as software engineers.

Sounds great. So where’s the vulnerability?

The vulnerability boils down to the following: if a page had a hashtag in its content that, as part of the hashtag, had an HTML-escaped element appended, it would get unescaped and then, by definition, inserted directly into the DOM by Company’s browser extension. Consider the following example:

 #tinfoil&lt;script&gt;alert('XSS')​&lt;/script&gt;

If this showed up in the text of a page, the extension noticed the #tinfoil hashtag and attempted to convert it into a link. So the above became something like the following:

 <a class="_company_extension" a="" href="#" #tinfoil"="" "javascript:var e = document.createEvent(&quot;CustomEvent&quot;); e.initCustomEvent(&quot;extensionEvent&quot;, true, true, {type: &quot;hash&quot;, value: &quot;#tinfoil&quot;}); document.body.dispatchEvent(e); return false;">#tinfoil</a><script>alert('XSS'​)</script>

You’ll notice that this is malformed HTML to begin with (the #tinfoil attribute of the a tag, for example), but the more important issue is that the Company’s browser extension actually unescapes the escaped HTML for the script tag and, in doing so, inserts it into the DOM. Of course, the link still works, pulling up a search for #tinfoil as it should, so if we weren’t popping up an alert box, the user would be none the wiser.

Uh oh...so what does this mean for me?

Well, effectively this means that if you were using the Company’s browser extension within Chrome, it would execute any malicious JS stored on any website you were visiting. For example, suppose you were logged into a financial service and viewing the discussion forums for help on a topic - someone could have posted this malicious hashtag in response creating a persistent, or stored, XSS. Worse is that even if said financial service had taken the proper precautions to prevent XSS by escaping HTML into its HTML entities (as we recommend), the Company’s browser extension would still have re-encoded it and run the malicious JavaScript. Essentially, Company had accidentally XSS’d the whole internet.

Okay. So what can we learn from this?

User generated content occurs everywhere, and it is always important to escape any input you may receive. The mantra we often use is: “If you didn’t generate it, assume it’s malicious.” In this case, the document returned by the website the user is visiting should be considered potentially malicious. The extension is acting on data it did not create, and as such should treat it more carefully than it would other data, by escaping everything it can. So if you’re building a browser extension, be sure to treat the DOM of whatever page you’re modifying as dangerous, because it is.

We love to talk about these sorts of issues, so feel free to chat with us via email or in our support chat. :)


Michael "Borski" Borohovski

Michael Borohovski is cofounder and CTO at Tinfoil Security. He got his start in security when he was just 13 years old, and has been programming for longer than he can remember. When he's not busy breaking software or building it, he also loves singing, juggling, and magic tricks. Yes, magic tricks.

Tags: XSS browser extensions browser security chrome google google chrome security


Tinfoil Security Blog

Tinfoil Security provides the simplest security solution. With Tinfoil Security, your site is routinely monitored and checked for vulnerabilities using a scanner that's constantly updated. Using the same techniques as malicious hackers, we systematically test all the access points, instantly notifying you when there's a threat and giving you step-by-step instructions, tailored to your software stack, to eliminate it. You have a lot to manage; let us manage your website's security.