By- April 11, 2017
When creating software, it’s very important to be able to verify the correctness of your code, and writing a Chrome extension is no exception. For an automated testing suite to work, we require two things. First, the code must be modularized in a way that allows for simple unit tests to be written. If this isn’t the case, writing tests can become a very tedious and messy process. Second, the testing suite needs to be able to access and interact with the application as a whole (integration tests). At first glance, it appears Google Chrome’s extensions satisfy neither of these requirements. However, with a bit of creativity, we can find solutions to both.
We’ll begin by looking at the first requirement: The code must be modularized in a way that allows for simple unit tests to be written. Chrome extensions are broken into three parts. The popup (the window that shows when you click the extension icon), the background script (any extension logic that runs in the background), and the content script (any extension logic that runs as a part of the current web page). Each of these must be exactly one file.
We’ll discuss a few solutions soon, including how Google likely manages their 26,000-line background script, but for now let’s move on to the second requirement: The testing suite needs to be able to access and interact with the application as a whole. The good news is that Google provides ChromeDriver, a way of programmatically interacting with Chrome. The bad news is that they seem to have forgotten about programmatically interacting with extensions.
As of today, there isn’t a way to click on your extension’s icon and open the popup using ChromeDriver. The workaround is to navigate to http://(your extension id)/popup.html, and view your popup there. This workaround is flawed, however. It renders the popup in a differently sized window than your normal popup, which makes asserting on UI behavior challenging or impossible depending on what you want to do. Also, if you want to assert that interacting with your popup does something to a page that’s currently open, you’re out of luck, since you need to navigate your browser to the popup to be able to interact with it.
Creating a Chrome extension that’s testable is possible, but we need to get a bit creative. To begin, we need a way to modularize our program into bite-sized chunks that each have a specific purpose. Then, we need to figure out a solution to our integration test issues, including setting up some sort of headless browser that can run tests. Finally, we need to actually write tests.
The other option is to use some sort of build system. By using a build system (such as Gulp), you can develop the extension in any form you’d like, then allow the build system to concatenate files together, thus creating Chrome’s required single script at build-time. By using a task runner like Gulp, you could have a setup where Gulp runs unit tests on your modules, then minifies and compiles everything into Chrome’s required format, and finally runs integration tests on the bundled package. This solution requires Node as a development dependency, but it offers more flexibility than the background.html option.
Writing functional integration tests is a little harder. Assuming we want to use some sort of CI system, we’ll probably want our integration tests running in a headless browser, so we should first focus on trying to get a headless browser running with our Chrome extension.
Selenium is a popular choice for browser automation, and has wrappers in just about every major language. It also works with ChromeDriver, which is great news, since we can’t load our Chrome extension into any other kind of browser. Depending on your wrapper, you’ll either be given a method to load in an extension or you’ll have to use the driver flag
--load-extension=extension_path. If you’re running the browser in headless mode, it may also be required to pass
The extension path you give the driver should be the path to the folder containing your manifest.json, and it should not be zipped. If either of these aren’t true, Chrome crashes. Once you’ve gotten Selenium to navigate to your extension popup at http://(your extension id)/popup.html, you’re ready to put together some tests.
I’ve put together a working, testable example implementing everything mentioned in this blog post. It can be found on GitHub here. This can be used either as a proof of concept or as a base for anyone writing a Chrome extension. The extension has a super simple background module that we test with a unit test, and some text on a popup that we test using an integration test. Unit tests are done using Karma and Jasmine. Integration tests are done using Watir and RSpec. Hopefully this example helps people write better, more testable Chrome extensions in the future.
Questions? Have a better method for testing Chrome extensions? We’d love to hear from you. Feel free to shoot us an email at email@example.com with any awesome browser extensions you’re building and how you’ve gone about testing them.
By- April 03, 2017
Ensuring our scanner can successfully authenticate into any given site has always been a priority at Tinfoil Security, and has helped us stay ahead. After all, if authentication fails, the scanner may not be able to access huge parts of a site, and can miss many vulnerabilities. Today, we’re announcing the Tinfoil Security Login Recorder: the easiest way for our scanner to authenticate into your site.
The Login Recorder is a browser extension that allows you to teach our scanner how to authenticate into your site by recording your login sequence in your own browser. Simply install our Chrome extension and follow the on-screen instructions to submit your recording.
Begin by providing API keys found here. If you’ve never created Tinfoil API keys before, the first step in the extension has a link to an interactive tutorial that will show you how to make one. Ensure your keys are “Full Access”, otherwise the extension won’t be able to send data to our server.
After you’ve authenticated, you’ll be asked to select which site you want to provide a recording for. Choose the site from the menu then hit ‘Next’. You’ll be warned about which sites have existing recordings, and submitting a recording for a site that already has one will overwrite the existing recording.
When a site has been selected, you’re ready to record! Make sure you’re on the login page for the correct site, then hit the ‘Record’ button.
At this point, the extension icon will turn red to indicate we are recording. Authenticate with your site as you normally would, then open the extension popup and click ‘Finished’ to end your recording.
Next, you’ll be asked to select some ‘verifiers’ on the page after you’ve logged in by clicking on them in your browser. A verifier is an element on the current page that is not present before authentication. For example, if you authenticate with your site and are greeted with a “Hello, Nathaniel!” banner, this would make a perfect verifier. We use these verifiers to help figure out if our scanner successfully logged in to your site, or if something went wrong in the process. We recommend selecting at least 3 verifiers.
When this is done, all that’s left to do is submit! Once you hit the ‘Submit’ button, your recording will be securely sent to our servers, and your next Tinfoil scan will mimic your recorded login to authenticate into your site.
This new method of authentication will work on many different types of login flows. Whether your site uses a traditional style login page, or a complex multi-page authentication flow built to your site’s needs, the Login Recorder provides a simple way to get your account setup quickly and easily.
Note that Tinfoil Security is dedicated to handling your sensitive information privately and securely. After submitting, your recording and API keys are removed from your system. On Tinfoil’s servers, your recording is encrypted using the same security practices as the rest of Tinfoil Security’s sensitive information. See https://www.tinfoilsecurity.com/security for more information.
Visit the Chrome Web Store to try the extension today!
By- March 10, 2017
NOTE: Tinfoil’s web application scanner now looks for Strutshock! Sign up and start a free trial here. We also have a checker for only Strutshock here. Simply input your URL to see if you are vulnerable.
If you’ve been keeping up with the security community lately, you’ve probably heard about the Struts 2 vulnerability (CVE-2017-5638) announced by Apache a couple days ago. This allows for remote code execution due to improper handling of the Content-Type header by the Jakarta Multipart parser. Thus, an attacker can gain full access to and control of any information stored on a server.
When an invalid Content-Type header is parsed by the Jakarta Multipart Parser, an exception is raised. The raised exception includes the invalid Content-Type header in the message. Unfortunately, if the header includes OGNL (Object Graph Navigation Language), the OGNL is evaluated before being returned. This allows an attacker to execute arbitrary code in the exception handler.
Anyone currently using Apache Struts 2.3.5 - Struts 2.3.31 or Apache Struts 2.5 - Struts 2.5.10. If you’re not sure whether or not you’ve been affected, we’ve included our Strutshock test, for anyone, as part of our free trial once you’ve verified ownership of your website.
Upgrade to Apache Struts 2.3.32 or Apache Struts 184.108.40.206.
Yes, two workarounds were recently published on the Apache Struts 2 documentation. However, we highly suggest upgrading to a patched version as soon as possible.
When the patch was released on March 6, less than a day later, a GitHub issue was opened on Rapid7’s Metasploit framework, an open source project, that included sample code allowing anyone to exploit the vulnerability. According to Cisco Talos, this resulted in immediate exploitation, and the rate of exploitation has remained steady since. If the severity doesn’t worry you, the fact that this attack is easy to reproduce and incredibly widespread should.
By- October 06, 2015
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.
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.
By- June 03, 2015
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.
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.