Ask Hackaday: Could Rating Airlines Stop Flights From Spreading Diseases?

December 6, 2023 by Lewin Day 82 Comments

A few weeks ago, I found myself the victim of flights from hell. My first flight was cancelled, leaving me driving home late at night, only to wake again for a red-eye the next morning. That was cancelled as well, with the second replacement delayed by a further hour. All in all I ended up spending a good ten hours extra in the airport surrounded by tired, sick, and coughing individuals, and ended up a full 16 hours late to my destination. On the return, I’d again tangle with delays, and by the weekend’s close, I’d contracted a nasty flu for my trouble.

All this had me riled up and looking for revenge. I had lost hours of my life to these frustrations, and the respiratory havoc claimed a further week of my working life. It had me realizing that we could surely improve the performance and hygiene of our airliners with a simple idea: a website called Flights From Hell.

Continue reading “Ask Hackaday: Could Rating Airlines Stop Flights From Spreading Diseases?” →

Mobile phone reading an NFC tag with information on a garden plant

NFC Puts A Stake In The Ground

August 15, 2023 by Michael Shaub 21 Comments

Sometimes we have a new part or piece of tech that we want to use, and it feels like a solution looking for a problem. Upon first encountering NFC Tags, [nalanj] was looking for an application and thought they might make a great update to old-fashioned plant markers in a garden. Those are usually small and, being outside 24/7, the elements tend to wear away at what little information they hold.

[nalanj] used a freeform data structuring service called Cardinal to set up text information fields for each plant and even photos. Once a template has been created, every entry gets a unique URL that’s perfect for writing to an NFC tag. See the blog post on Cardinal’s site for the whole process, the thought behind the physical design of the NFC tag holder, and a great application of a pause in the 3D print to encapsulate the tags.

NFC tags are super hackable, though, so you don’t have to limit yourself to lookups in a plant database. Heck, you could throw away your door keys.

A Collection Of Websites That Look Like Desktops

October 27, 2022 by Lewin Day 15 Comments

Web design has come a long way since those halcyon days of Web 1.0. There are plenty of rules about how to make a clean and efficient website, but sometimes it’s more fun to throw them out and just be creative instead. In that vein, [Simone] has curated a wonderful collection of websites that emulate the computer desktop experience online.

The collection’s website very much fits this theme. Upon visiting, an Award BIOS screen flashes up. From there, we get a Windows 95-like interface full of links to other sites that emulate a computer desktop layout. There’s even a 3D screensaver that pops up if you mouse away for too long.

There’s Browso.app, which semi-accurately tells you information about your computer in a theme reminiscent of MacOS 9. Meanwhile, clicking on “It Is As if You Were Doing Work” will take you to a weird game that’s compelling in its replication of office banality. Nightwave Plaza offers exquisite vaporwave vibes, while others simply intend to faithfully recreate various OSes in a browser window.

It’s a fun collection of websites that go from the weirdly afamiliar to downright impressive recreations of former realities. It’s certainly fun to click around for a while and see what’s out there. We do love some good web ephemera around these parts!

Turning GitHub Into A URL Shortening Service

November 18, 2020 by Sven Gregori 11 Comments

URL shortening services like TinyURL or Bitly have long become an essential part of the modern web, and are popular enough that even Google killed off their own already. Creating your own shortener is also a fun exercise, and in its core doesn’t require much more than a nifty domain name, some form of database to map the URLs, and a bit of web technology to glue it all together. [Nelsontky] figured you don’t even have to build most of it yourself, but you could just (ab)use GitHub for it.

Using GitHub Pages to host the URL shortening website itself, [nelsontky] actually repurposes GitHub’s issue tracking system to map the shortened identifier to the original URL. Each redirection is simply a new issue, with the issue number serving as the shortening identifier, and the issue’s title text storing the original URL. To map the request, a bit of JavaScript extracts the issue number from the request, looks it up via GitHub API, and if a valid one was found (and API rate limits weren’t exceeded), redirects the caller accordingly. What’s especially clever about this is that GitHub Pages usually just serves static files stored in a repository, so the entire redirection logic is actually placed in the 404 error handling page, allowing requests to any arbitrary paths.

While this may not be as neat as placing your entire website content straight into the URL itself, it could be nicely combined with this rotary phone to simply dial the issue number and access your bookmarks — perfect in case you always wanted your own website phone book. And if you don’t like the thought of interacting with the GitHub UI every time you want to add a new URL, give the command line tools a try.

Tiny Websites Have No Server

July 7, 2018 by Al Williams 49 Comments

A big trend in web services right now is the so-called serverless computing, such as Amazon’s Lambda service. The idea is you don’t have a dedicated server waiting for requests for a specific purpose. Instead, you have one server (such as Amazon’s) listening for lots of requests and on demand, you spin up an environment to process that request. Conceptually, it lets you run a bit of Javascript or some other language “in the cloud” with no dedicated server. https://itty.bitty.site takes this one step farther. The site creates self-contained websites where the content is encoded in the URL itself.

Probably the best example is to simply go to the site and click on “About itty bitty.” That page is itself encoded in its own URL. If you then click on the App link, you’ll see a calculator, showing that this isn’t just for snippets of text. While this does depend on the itty.bitty.site web host to provide the decoding framework, the decoding is done totally in your browser and the code is open source. What that means is you could host it on your own server, if you wanted to.

At first, this seems like a novelty until you start thinking about it. A small computer with an Internet connection could easily formulate these URLs to create web pages. A bigger computer could even host the itty.bitty server. Then there’s the privacy issue. At first, we were thinking that a page like this would be hard to censor since there is no centralized server with the content. But you still need the decoding framework. However, that wouldn’t stop a sophisticated user from “redirecting” to another — maybe private — decoding website and reading the page regardless of anyone’s disapproval of the content.

Continue reading “Tiny Websites Have No Server” →

Fooling Google Search Console With Tricky PHP

July 17, 2015 by Rick Osgood 42 Comments

When [Steve] received a notice from Google that a new owner had been added to his Google Search Console account, he knew something was wrong. He hadn’t added anyone to his account. At first he thought it might be a clever phishing tactic. Maybe the email was trying to get him to click a malicious link. Upon further investigation, he discovered that it was legitimate. Some strange email address had been added to his account. How did this happen?

When you want to add a website to Google’s services, they require that you prove that you own the actual website as a security precaution. One method to provide proof is by uploading or creating an HTML file to your website with some specific text inside. In this case, the file needed to be called “google1a74e5bf969ded17.html” and it needed to contain the string “google-site-verification: googlea174e5bf969ded17.html”.

[Steve] logged into his web server and looked in the website directory but he couldn’t find the verification file. Out of curiosity, he tried visiting the web page anyways and was surprised to find that it worked. After some experimentation, [Steve] learned that if he tried to load any web page that looked like “googleNNNNNNN.html”, he would be presented with the corresponding verification code of “google-site-verification: googleNNNNNNNN.html”. Something was automatically generating these pages.

After further investigation, [Steve] found that some malicious PHP code had been added to his website’s index.php page. Unfortunately the code was obfuscated, so he couldn’t determine exactly what was happening. After removing the new code from the index.php file, [Steve] was able to remove the hacker’s email address from [Steve’s] Google account.

This is a very interesting hack, because not only did it allow this one hacker to add himself to [Steve’s] Google account, but it would also have allowed anyone else to do the same thing. This is because each new hacker would have been able to fool Google’s servers into thinking that they had uploaded the verification file thanks to the malicious PHP code. It makes us think that perhaps Google’s verification system should use a separate randomized string inside of the verification file. Perhaps one that can’t be guessed or calculated based on known variables such as the file name.

Hacking Oklahoma State University’s Student ID Cards

February 25, 2015 by Rick Osgood 39 Comments

[Sam] took an information security class at Oklahoma State University back in 2013. For his final project, he and a team of other students had to find a security vulnerability and then devise a theoretical plan to exploit it. [Sam’s] team decided to focus on the school’s ID cards. OSU’s ID cards are very similar to credit cards. They are the same size and shape, they have data encoded on a magnetic strip, and they have a 16 digit identification number. These cards were used for several different purposes. Examples include photo ID, physical access to some areas on campus, charges to an online account, and more.

[Sam] and his team analyzed over 100 different cards in order to get a good sample. They found that all cards started with same eight digits. This is similar to the issuer identification number found in the first six digits of a credit card number. Th analysis also showed that there were only three combinations used for the next two digits. Those were either 05, 06, or 11. With that in mind, the total possible number of combinations for card numbers was mathematically calculated to be three million.

OSU also had a URL printed on the back of each card. This website had a simple form with a single field. The user can enter in a 16 digit card number and the system would tell the user if that card was valid. The page would also tell you if the card holder was an employee, a student, or if there were any other special flags on the card. We’re not sure why every student would need access to this website, but the fact is that the URL was printed right on the back of the card. The website also had no limit to how many times a query could be made. The only hint that the university was aware of possible security implications was the disclaimer on the site. The disclaimer mentioned that usage of the tool was “logged and tracked”.

The next step was to purchase a magnetic card reader and writer. The team decoded all of the cards and analyzed the data. They found that each card held an expiration date, but the expiration date was identical for every single card. The team used the reader/writer to copy the data from [Sam’s] card and modify the name. They then wrote the data back onto a new, blank magnetic card. This card had no printing or markings on it. [Sam] took the card and was able to use it to purchase items from a store on campus. He noticed that the register reached back to a server somewhere to verify his real name. It didn’t do any checks against the name written onto the magstripe. Even still, the cashier still accepted a card with no official markings.

The final step was to write a node.js script to scrape the number verification website. With just 15 lines of code, the script will run through all possible combinations of numbers in a random sequence and log the result. The website can handle between three and five requests per second, which means that brute forcing all possible combinations can be completed in roughly two days. These harvested numbers can then be written onto blank cards and potentially used to purchase goods on another student’s account.

[Sam’s] team offers several recommendations to improve the security of this system. One idea is to include a second form of authorization, such as a PIN. The PIN wouldn’t be stored on the card, and therefore can’t be copied in this manner. The primary recommendation was to take down the verification website. So far OSU has responded by taking the website offline, but no other changes have been made.