Last two months were quite amazing for me as a Wingifighter; I was on a traveling spree over Italy and London. I got an opportunity to attend and speak at various international conferences and meetups there, which gave me new insights on the importance of JavaScript and Security. It was a new experience for me as I got a chance to meet some great people and learn a lot from them. This post is about my learnings and overall experience representing Wingify and driving the concept of Web Security at various tech events.

1) Node.js Conference, Italy (22nd October 2016)

I attended my first International Conference which was held at a beautiful place – Desenzano del Garda, Italy. I was one of the speakers and I talked about Node.js Security.

The conference started with a keynote by Microsoft’s Bryan Hughes (@nebrius) about the Node.js community and its evolution. He later introduced us to the Node.js foundation hierarchy and how it operates at various levels. Other speakers, too, touched various relevant and interesting topics including AsyncHooks, Load Balancing, and Deploying Node.js at scale. You can find more information at http://nodejsconf.it/

Speaker dinners were a great platform where I got to interact and network with fellow speakers. I also met Feross and I found him to be very humble and polite. He insisted on why fun side-projects are important and why you should keep doing them. And that’s why Wingify runs “Show n Tell” in which Wingifighters demonstrate and discuss any side projects that they are working on.

I spent the rest of my time in Italy in traveling and had a wonderful experience. I fell in Love with Gelatos🍦.

2) London Ajax Meetup (14th November 2016)

This is a monthly meetup that happens in London. This time the focus of the meetup was JavaScript Security and Neural Networks. I got a really good response after my talk. The venue was Skills Matter Office where a couple of other meetups were going on simultaneously. I realized this when I went into another arena searching for food and none of the people seemed to recognize me.

The other talk during the event was on “Classifying Numbers as Odd or Even With Neural Networks,” by Matt Zeunert. It was quite informative.

3) SeleniumConf UK (14th-16th November 2016)

SeleniumConf is an event focused on Web Testing and brings together Selenium developers and enthusiasts from around the world to share ideas, socialize, and work together on advancing the present and future success of the project.

My talk in this conference was about Web Security and Efficient Penetration Testing. I gave a live demo of my recent finding (security vulnerability) in InVision. With the help of Burp Suite and BeEf, I demonstrated how a malicious comment in Invision App can be used to control browser and steal information. You can read more about the vulnerability details I published in Hackernoon.

Here are the links to the video and slides.

4) Half Stack Conference (18th November 2016)

HalfStack is a one-day, single track, fun and unique JS conf in a pub 🍺. It was good to sit down and listen to Christian Heilmann, Remy Sharp and Dylan Schiemann. There were a lot of other interesting talks at the conference. Video recording for all sessions are available here.

After the conference, we went to another pub for a “JavaScript Pub Quiz.”

The following is an emoji mathematical example given by Mark Wubben in his talk on Babel

🍺 + 🍺 = 🍻

🍻 + 🍻 = 😆

(🍻 * 🍻)^🍻 = 😵


To sum up

I got to learn a lot from my travels. I would encourage everyone to follow and attend such conferences and events.

You can keep an eye on the list of FrontEnd Conferences for 2017 and follow Himanshu’s twitter list to stay up-to-date.

Happy Holidays! 🎄🎁


Few days back, we open-sourced our internal Skype bot to the world. Its called Heybot!, but we call it Ramukaka at Wingify :) Whether its about running a jenkins build or getting a customer info from account ID, Ramukaka does it all for us.

Heybot! gives you a simple framework to write commands that you can run, with provision of restricted access to some commands by power users only. Its written over Microsoft’s bot framework, designed to be extensible for any sort of task in small and large teams. Bot framework based bots work out of the box with Skype, but the same bots can act as a base for a Messenger, slack etc bot too.

So if your team communication is on Skype (or even if you work alone) and regularly do some tasks which could be automated through a command, Heybot! can definitely prove useful for you. Lets see how you can quickly set it up for Skype.

Installing

Heybot! is written in NodeJS. To set it up on a server you need to clone the Github repository first:

git clone git@github.com:wingify/heybot.git

and run npm install in the repository folder to install all the required dependencies.

Setup

Before you can start using the bot on Skype, you need to create a bot and register it with Microsoft as an app. Create a Microsoft app as directed here. When you register your bot, you’ll have to give it a name of your choice that will be used in Skype chat to talk with it.

Once you register the bot, you’ll have an app ID and app Password with you. Go ahead and create a copy of the file creds.template.js into creds.js and replace the ID and password in it. If you don’t want to store the ID and password in that readable file, you can have the same keys set as environment variables and Heybot will read from there. Note, that you still need to have a dummy creds.js file.

The bot framework requires the bot server to be running on a valid secure connection. Therefore, you’ll need to provide the Heybot with your domain’s SSL certificates (the .crt and .key files). Place them in the repository folder as ssl.cert and ssl.key.

Running the bot server

Now that you have setup your bot, you can run the bot server by running the command npm start. Similarly to stop it you can run npm stop.

Adding your bot on Skype

The bot you setup would in most cases have commands that you use on day to day basis and it won’t make sense to put such a bot publicly on the Microsoft bot marketplace. For this reason, you can keep you bot in preview mode - just available for you and anyone with the link to add the bot.

Go to your bot’s page from https://dev.botframework.com/bots. Now click on the Add to Skype button to add it to your skype.

Once you have added it your skype, you are all set to give it commands. Lets assume you gave your bot the name droid while registering. You can test your new bot by starting a conversation with it and saying anything. If it replies with a Hello message, its working perfectly. You can then try out pre-loaded commands such as !bored, !sad, !bitcoin etc.

If you add the bot to a group chat, you can give it command by simply mentioning its name before the command’s usual syntax. Eg. @Droid !bored.

There you go! Build your own commands and automate your daily boring tasks with Heybot! And do tell us on Github about any feature request, suggestion or any cool command that you made for Heybot!


About two years ago, Wingify had introduced the new generation of our Visual Website Optimizer to the world. Boasting a modern visual interface, it also had many new features. We’ve come a long way since then. We’ve added even more features to it while improving the previous ones. But with continuous development, it becomes imperative to keep the app lean and fast as well. New features, unless proactively attended to, usually make apps slower. This effect is especially prominent in SPAs(Single Page Applications) which have to be downloaded first on the browser before they can execute. Thus, performance management is an iterative and continuous process. This post is largely a collection of our learnings and implementations done on/to our app to keep it lean and slick.

There are several types of performances when it comes to modern web applications. This blog post chiefly deals with our efforts in improving the app load time. This was also the first phase of the plan since the first things users notice is how soon can they start using the app.

Performance Monitoring Tools

To measure performance, we’ve installed monitoring tools which help us visualize the improvement or deterioration of the app with every release made to production. The chief ones among them are:

  1. Speedcurve — Speedcurve generates a detailed report of the key metrics required to measure network performance. Speedcurve ensures that the each release is monitored. It has a detailed dashboard which shows the health of the app over a period of time. If there’s any negative impact in performance it sends a mail with details of the key performance parameters (like the content size of the page, content requests made by the page, page load time, rendering time etc.).

  2. Web Page Test Charts API — We’ve also installed a custom flavour of Trulia’s open source Webpage Test Charts API . Since both Speedcurve and Web Page Test Charts API essentially get the test results from webpagetest.org the benchmarking source is same. Web Page Test Charts API allows us to view other parameters which Speedcurve doesn’t show.

Performance Improvement Measures

Apart from the tools placed to measure performance, we’d also been busy shipping the following boosts to the app: 

  1. Upgrade to AngularJS 1.5 — While making the VWO App, two years back, the most stable version of AngularJS present was 1.2. Since then several versions have released with the latest one being 1.5. The features and performance benefits of 1.5 over 1.2 were convincing enough to make the move. But there were plenty of breaking changes which kept the Dev team as well as the QA team busy for quite some time in making sure that the upgraded code was bug free and the customers had a seamless transition. I’m glad to share that we’ve finally made the transition.

  2. Move to HTTP/2 Protocol — HTTP/2 protocol, the successor of the HTTP 1.1 protocol and based loosely on the SPDY protocol provides several benefits. It enables multiplexing of resources across single TCP connection, compressing and reducing HTTP headers and also supports Server Push (The server can optimistically push resources to the browser which it understands that the browser might require). HTTP/2 has good browser support and is backward compatible with HTTP 1.1 which means browsers not supporting it can fallback to the older protocol.

    HTTP/2 support

    HTTP/2 browser support information on Can I Use
  3. Move to HTTPS — HTTPS is a precondition for HTTP/2. So, yay!

  4. Reduce the initial app content on bootstrap — We’ve reduced the initial app loading size by more than a 100 KBs (and more… or should I say less… to come). This has been achieved due to the combined result of:
    • Removing heavy libraries with their lighter counterparts - We’ve completely removed libraries like Angular Bootstrap and Chosen from our app dependency. These have been replaced by in-house implementations of the respective libraries.
    • Loading only the modules critical to bootstrap, on bootstrap - On analyzing, our app’s bootstrap process, we realized that several modules which weren’t critical to it were still loaded. After some code refactor these modules have been eliminated from the process.
    • Splitting of vendor files into primary and secondary files - More on that later in the post.
  5. Implement better cache-bust mechanism — We’ve moved to naming our files based on MD5 checksum of their content instead of naming them based on their timestamp of generation, which was the case earlier. This has resulted in generation of fewer unique files on every build. Only the files which are modified get renamed. 

  6. ETags for the index page — The ETag or entity tag based on the HTTP protocol allows the client to make conditional requests. This enhances the caching mechanism and saves bandwidth since the browser only makes the request when the file has changed. Ergo, better loading time!

  7. Split vendor files into primary and secondary — It is a common practice in web development to combine all the libraries, required by the app, into a single file. Usually, this is called the vendor file and it gets downloaded entirely in the beginning. Often, several components of the vendor file aren’t required in the usual app usage, but they still get downloaded since it is a single bundle. We’ve divided the vendor file into two and split their content based on the frequency of usage. The first vendor file contains all the libraries which are absolutely necessary for the application to load. For example, AngularJS and its dependencies. The second vendor file is loaded on demand, based on modules which require less frequently required libraries, for example, Graph libraries to show graphs. By doing so we’ve cut a good chunk of approximately 200 KBs from the original monolithic vendor file, a considerable amount by any standard.

  8. Implement login page in vanilla JS — The VWO app is written in AngularJS framework. AngularJS is a heavy framework. To add to the woe it has tons of dependencies. The benefit of moving the login page out of AngularJS context, and keeping it in plain JS has a two-fold benefit. Firstly, the login page becomes lighter since it isn’t dependant on the framework anymore. Secondly, by utilising the time that the user takes in filling his credentials we can load, as much of the app, in the background, as possible. Thus, when the user is done signing in, a major portion of the app, if not all, would’ve already been downloaded.

  9. Optimize images - Though we used to optimize images earlier, it required the developers to manually run the task and commit those images to the repository. This was cumbersome and often developers would miss doing it. This has now been incorporated into our build process. Each image that now reaches the browser is optimized.

We’ve come a long way from the initial VWO app that was made two years back. And we still have a lot to cover. As we see it, this is just the tip of the iceberg. We’ll be publishing more posts on the improvements that we push to the app. If you have any suggestions, queries or concerns feel free to drop a comment.


Recently, I spoke about securing Web Applications at JSChannel Conference ’16. The conference venue was The Ritz-Carlton, Bangalore. JSChannel is a great conference to attend and to connect with some great people. And when I say great, I literally mean it. We met with Yehuda Katz (one of the creators of Ember.js), Lea Verou (Expert in the W3C CSS Working Group) & Christian Lilley (Father of SVG) and experts from McKinsey.

Three Wingifighters flew to attend and listen to this amazing conference and here we are, showing off some swag.🤘

Day 1 was amazing. Rachit, having attended almost all the sessions, has shared his learning experience at the conference on the Team Wingify’s Space.

Before The Talk

Speaking at a conference involves a lot of work before getting on stage. Preparation is crucial. I spent a good number of hours to jot down a list of security vulnerabilities to talk about and steps to mitigate them. I had to make sure none of my demonstrations exposed the vulnerabilities of the websites I chose to talk about.

And guess what, in my preparation for the demo, I actually found another way to bypass a previously reported vulnerability in time just before the conference. Keeping in mind the JavaScript conference and the audience, I made sure everything was related to Browser level and Node.js application attacks.

The Talk

For the video, scroll down to the end of the post.

It all started with a humorous introduction and a show of my prowess!

Security is like the elephant in the room where everyone agrees that it’s very important but only a few take it very seriously.

I touched upon the recent Github reused password attack and why we should follow a good password hygiene and move towards multi-factor authentication (MFA).

XSS

Rule of thumb: Validate input and escape output

CSRF

XSS + CSRF = Game Over!

I’ve developed a sample web application using Node.js, Express and Angular that is vulnerable to common security vulnerabilities were demonstrated. Click here to see the code.

What could possibly go wrong?

The talk ended with a live demonstration of an interesting and serious vulnerability found on a popular hiring platform, RecruiterBox. A JavaScript injection using which an attacker can upload a maliciously crafted resume and can perform Cross-site Scripting attacks. I used Burp Suite, an interceptor proxy to bypass the fix deployed by Recruiterbox, for demonstration purposes.

To know more about the vulnerability, click here.

Feedback:

After the talk, it was rewarding to see a good response and interesting queries from the audience. One comment I received from audience was “We have just realized that our services are vulnerable to one of the attacks you have demonstrated and we never gave a thought to it. Thank you!”.

My 2 cents for attending any tech conference

More than the talks themselves, it is the people that you should attend the conference for. You should meet the other attendees! If a particular talk is interesting and useful then you can and should talk to the speaker.

Key takeaways:

  1. Never blindly trust user input.
  2. Always use proven sanitizers and tools.
  3. Perform security audits.
  4. Keep discussing vulnerabilities because the Internet has a bunch of weird old stuff that, not necessarily, every software developer knows about.

Video.

As a first-time speaker, I wasn’t sure what to expect. It turned out to be a great experience and received very positive feedback.


There were just two hours left to catch a flight for an exciting opportunity to present at the biggest Selenium conference, SeleniumConf 2016, and we were still waiting for our cab to the airport. Our driver was lost within 350 meters of our Wingify office, finding his way around the vicinity. Eventually, we boarded the flight at the final call!

A cool breeze welcomed us at Bengaluru airport, and the next morning we were at The Chancery Pavillion Hotel with our passes:

Day 1 was about keynotes, new tools and sponsor stands. HP launches lean UFT, introducing Selenium inbuilt with the tool. There were a lot of talks that explored more areas Selenium could be used in, thereby widening its scope.

D day: Demo day

There was no hurry to reach the venue today as the streets were all mapped a day before, suits and boots were tied up. It was the day to present, world’s first ever open source automation tool for push notifications - PushKnot

Push notifications let users to opt into timely updates from sites they love and allow you to effectively re-engage them with customized, engaging content. As per recent surveys, push notifications are turning out to be better than email notifications.

Since it’s a relatively new technology which is booming, the SDLC flows goes like this specs written, functionality developed, unit tests written, how about testing it end to end? Do it manually or automate it like a boss!

PushKnot helps you do the latter part well.

“PushKnot is a specialized open-source proxy tool for modifying, parsing and fetching desktop push notifications.”

How PushKnot works:

It works as a proxy server which intercepts the service-worker registration request’s response. It adds a specific payload and the new modified service-worker is registered with the browser.

This payload has specialized code which intercepts and captures the push notification received. Once it has intercepted the push notifications, it saves the notification data in JSON format in a file, and forwards the notification back to the browser so that it can be seen there.

Once the response is stored in a JSON file it can be easily read and verified.

Steps:

  1. The service is available at https://github.com/Ankitagupta2309/pushKnot

  2. After cloning the repo and running npm install, you can start it by running

    node start.js —domain=<yourdomain>

  3. By default it will run on port 9002, if you want to change it, you can do so by using the flag —port=9003

  4. Set up https system proxy to point to 127.0.0.1:9002

    setup proxy push

  5. When you are launching your browser you need to set 2 flags:

    • Start a chrome browser with --ignore-certificate-errors flag
    • Set browser preference 'profile.default_content_setting_values.notifications': 1
chromeOptions: {
	'args': ['--ignore-certificate-errors'],
	prefs: {
		'profile.default_content_setting_values.notifications': 1
	}
}

Slides deck from the talk.

Demo from the talk.

Video of the talk.

It was a great learning experience. Received good feedback on our tool, some of which have already been implemented. Write back to us if you have any feedback or queries.