Measuring Web Latency in the Browser

We’ll go out on a limb and assume that anyone reading these words is probably familiar with the classic ping command. Depending on which operating system you worship the options might be slightly different, but every variation of this simple tool does the same thing: send an ICMP echo request and wait for a response. How long it takes to get a response from the target, if it gets one at all, is shown to the user. This if often the very first step to diagnosing network connectivity issues; if this doesn’t work, there’s an excellent chance the line is dead.

But in the modern web-centric view of networking, ping might not give us the whole picture. But nature it doesn’t take into account things like DNS lookups, and it certainly doesn’t help you determine what (if any) services the target has available to you. Accordingly, [Liu Zhiyong] has come up with a tool he calls “pingms”, which allows you to check web server latency right from your browser.

Rather than relying on ICMP, pingms performs a more realistic test. It takes the list of targets from the file “targets.js” and connects to each one over HTTP. How does it work? The code [Liu] has come up with will take each target domain name, append a random number to create a gibberish filename, and then calculate how long it takes to get a response when trying to download the file. Obviously it’s going to be getting a 404 response from the web server, but the important thing is simply that it gets the response.

With this data, [Liu] has come up with a simplistic but very slick interface which shows the user the collected data with easy to understand color-coded graphs. As interesting as it is to see how long it takes your favorite web sites or service providers to wake up and start talking, watching the colored bars hop up and down the list to sort themselves is easily our favorite part of pingms.

[Liu] has released pingms under the GPLv3 license, so if you’re looking to utilize the software for your own purposes you just need to provide a list of test targets. If you need to perform low-level diagnostics, check out this handy network tester you can build for cheap.

Control a Quadcopter over Websockets

The interface

Everyone’s favourite IOT module, the ESP8266, is often the go-to choice for any project that needs quick and cheap control over the web. [Andi23456] wanted to control his quadcopter using the luxury of his mobile phone and thought permanently tethering an ESP12-E module to the quadcopter was exactly what he required.

The ESP8266, really showcasing its all-round prowess, hosts both a web server for a HTML5 based joystick and a Websockets server so that a client, such as a phone, could interact with it over a fast, low latency connection. Once the ESP8266 receives the input, it uses interrupts to generate the corresponding PPM (Pule Position Modulation) code which the RC receiver on the quadcopter can understand. Very cool!

What really makes this realtime(ish) control viable is Websockets, a protocol that basically allows you to flexibly exchange data over an “upgraded” HTTP connection without having to lug around headers each time you communicate. If you haven’t heard of Websockets you really should look really check out this library or even watch this video to see what you can achieve.

Hackaday Prize Entry: Minimalist HTTP

For his Hackaday Prize entry, [Yann] is building something that isn’t hardware, but it’s still fascinating. He’s come up with a minimalist HTTP compliant server written in C. It’s small, it’s portable, and in some cases, it will be a bunch better solution than throwing a full Linux stack into a single sensor.

This micro HTTP server has two core modules, each with a specific purpose. The file server does exactly what it says on the tin, but the HTTaP is a bit more interesting. HTTaP is a protocol first published in 2014 that is designed to be a simpler alternative to WebSockets.

[Yann] has been experimenting with HTTaP, and the benefits are obvious. You don’t need Apache to make use of it, HTTaP can work directly with an HTML/JavaScript page, and using only GET and POST messages, you can control hardware and logic circuits.

As this is a minimalist HTTP server, the security is dubious at best. That’s not the point, though. This is just a tool designed for use in a lab or controlled environments with an air gap. Safety, scheduling, encryption, and authentication are not part of HTTaP or this micro HTTP server.

Distributed, Open Source Chat with Vector and Matrix

When it comes to chat, you have many choices. Facebook Messenger, Google Talk, Whatsapp, Kik, and Slack are all viable options. However, all of these choices are proprietary, and require you to use servers that you can’t run yourself. They’re highly centralized, closed source tools.

In the open source world, IRC has been the go to solution for chat for many years, and for good reason. Anyone can run a server, there’s many clients, and it’s built on open standards. But IRC comes from a pre-mobile world, and relies on clients to maintain persistent connections to the server. It’s not the best experience on a phone.

Matrix.org and Vector.im aim to be a modern solution to chat. Matrix is a standard for passing messages around, and Vector is a chat solution built on top, with support for iOS, Android, and your browser.

What makes this solution different is the concept of Homeservers. A Homeserver manages messages for users, recording them when they are received and providing them to users when they connect. Homeservers also “federate” to communicate amongst each other. This means anyone can run a Homeserver and connect it to the greater network of Matrix, providing a distributed approach to building a chat network.

Under the hood, Matrix is just HTTP. You send messages into the network with POST requests, and receive new messages by polling with GET requests. This means no persistent connections are required, which is perfect for mobile and low power devices.

On the topic of devices, Matrix is designed for general purpose messaging, not just chat. It should be pretty simple to connect hardware up to Matrix, which would provide a simple way to get data in and out of connected devices. Since it’s all HTTP, a device based on the ESP8266 could hop into your chat room with relative ease.

Matrix and Vector are very much in beta, but are definitely usable and worth a try. To get started, you can create an account on Vector.im and start chatting. We’re awaiting some of the features in the works, including end-to-end encryption, and hope to see some future hacks talking to the Matrix infrastructure.

Alarm Notifies the Office When the Coffee is Ready

[Stian] thought it would be nice if his coworkers could be electronically notified when the latest batch of coffee is ready. He ended up building an inexpensive coffee alarm system to do exactly that. When the coffee is done, the brewer can press a giant button to notify the rest of the office that it’s time for a cuppa joe.

[Stian’s] first project requirement was to activate the system using a big physical button. He chose a button from Sparkfun, although he ended up modifying it to better suit his needs. The original button came with a single LED built-in. This wasn’t enough for [Stian], so he added two more LEDs. All three LEDs are driven by a ULN2003A NPN transistor array. Now he can flash them in sequence to make a simple animation.

This momentary push button supplies power to a ESP8266 microcontroller using a soft latch power switch. When the momentary switch is pressed, it supplies power to the latch. The latch then powers up the main circuit and continues supplying power even when the push button is released. The reason for this power trickery is to conserve power from the 18650 li-on battery.

The core functionality of the alarm uses a combination of physical hardware and two cloud-based services. The ESP8266 was chosen because it includes a built-in WiFi chip and it only costs five dollars. The microcontroller is configured to connect to the WiFi network with the push of a button. The device also monitors the giant alarm button.

When the button is pressed, it sends an HTTP request to a custom clojure app running on a cloud service called Heroku. The clojure app then stores brewing information in a database and sends a notification to the Slack cloud service. Slack is a sort of project management app that allows multiple users to work on projects and communicate easier over the internet. [Stian] has tapped into it in order to send the actual text notification to his coworkers to let them know that the coffee is ready. Be sure to watch the demo video below. Continue reading “Alarm Notifies the Office When the Coffee is Ready”

Race Conditions Exploit Granted Free Money on Web Services

[Josip] has been playing around with race conditions on web interfaces lately, finding vulnerabilities on both Facebook and Digital Ocean. A race condition can occur when a piece of software processes multiple threads using a shared resource.

For example, [Josip] discovered that he was able to manipulate page reviews using just a single Facebook account. Normally, a user is permitted to leave just one review for any given Facebook page. This prevents a single user from being able to skew the page’s overall ranking by making a bunch of positive or negative reviews. The trick to manipulating the system was to intercept the HTTP request that submitted the page review. The request was then replayed over and over in a very short amount of time.

Facebook’s servers ended up processing some of these requests simultaneously, essentially unaware that multiple requests had come in so close together. The result was that multiple reviews were submitted, artificially changing the pages overall ranking even though only one review actually showed up on the page for this user. The user can then delete their single review, and repeat this cycle over and over. It took Facebook approximately two months to fix this vulnerability, but in the end it was fixed and [Josip] received a nice bounty.

The Digital Ocean hack was essentially the exact same process. This time instead of hacking page reviews, [Josip] went after some free money. He found that he was able to submit the same promotional code multiple times, resulting in a hefty discount at checkout time. Digital Ocean wasted no time fixing this bug, repairing it within just ten days of the disclosure.

Exposing Private Facebook Photos with a Malicious App

[Laxman] is back again with another hack related to Facebook photos. This hack revolves around the Facebook mobile application’s “sync photos” function. This feature automatically uploads every photo taken on your mobile device to your Facebook account. These photos are automatically marked as private so that only the user can see them. The user would have to manually update the privacy settings on each photo later in order to make them available to friends or the public.

[Laxman] wanted to put these privacy restrictions to the test, so he started poking around the Facebook mobile application. He found that the Facebook app would make an HTTP GET request to a specific URL in order to retrieve the synced photos. This request was performed using a top-level access token. The Facebook server checked this token before sending down the private images. It sounds secure, but [Laxman] found a fatal flaw.

The Facebook server only checked the owner of the token. It did not bother to check which Facebook application was making the request. As long as the app had the “user_photos” permission, it was able to pull down the private photos. This permission is required by many applications as it allows the apps to access the user’s public photos. This vulnerability could have allowed an attacker access to the victim’s private photos by building a malicious application and then tricking victims into installing the app.

At least, that could have been the case if Facebook wasn’t so good about fixing their vulnerabilities. [Laxman] disclosed his finding to Facebook. They had patched the vulnerability less than an hour after acknowledging the disclosure. They also found this vulnerability severe enough to warrant a $10,000 bounty payout to [Laxman]. This is in addition to the $12,500 [Laxman] received last month for a different Facebook photo-related vulnerability.