How things work matters
In a span of maybe two weeks I'm reading the second article where a software that looks nice on the surface turns out to be horrible in the inside.
This is a good reminder that having nice features is important, but how things work under the hood matters as well. Sometimes it results on a fine, such as when 23andMe failed to secure user access or when Zoom lied about end-to-end encryption.
But fines are the rare exceptions. More often it just allows hackers to gain and modify data and put users at risk.
The first story is about this blog post where the author could insert scripts into the users of the Arc browser.
I haven't heard of Arc browser before, but according to its own description it's an enhanced Chromium:
Experience a calmer, more personal internet in this browser designed for you. Let go of the clicks, the clutter, the distractions with the Arc browser.
It comes with a feature called Boosts that, according to the documentation:
Boosts are a new way to edit and remix your internet, and share it with friends too!
In a nutshell, you can add rules that change things on pages like the font size, colors, size, capitalization, and, of course, allows any JavaScript to be inserted.
And since these can be shared, that means it is stored on a remote server.
Of course, there was a security vulnerability here. From the article:
- arc boosts can contain arbitrary javascript
- arc boosts are stored in firestore
- the arc browser gets which boosts to use via the creatorID field
- we can arbitrarily chage the creatorID field to any user id
Boosts can be useful features. But if you look into how they work they allow a remote party to inject any script into any of site you visit. Any vulnerability on their side directly compromises you. Were it to be written on their webpage, I'm sure many users would think twice to install the browser.
The second story is this blog post where the author could gain a real-time view of all restaurants using a specific ordering system.
A few days ago, I went to a cafe near my home. I sat down and scanned the QR code on the table. It took me to a website displaying the cafe's menu. It asked me for my name and Whatsapp mobile number. I entered the details and placed the order.
/api/morder/suggestion/ongoing/items?storeID=XXXX
/api/morder/suggestion/items/purchase/history?merchantID=YYYY&storeID=XXXX
The first request listed the food items currently ordered at the cafe. The second returned how many times each item was ordered in the past month.
Some more APIs later:
From the mobile number, I could see all the food he had ever ordered in this cafe.
Getting the revenue for the store:
The purchase history API provided a count of each food item ordered over the past month. The menu API gave the price of each food item. So I wrote a small script to calculate the cafe's dine-in revenue for the last month.
Then in other restaurants:
I could now see all the ongoing orders from all their restaurants in real time!
And also place orders for other people's tables:
I figured out that I can remotely place an order at any restaurant table where people were already sitting without needing their table PIN.
On the surface only the ordering experience is visible. But how it works allows any people to see all the sales records of any restaurant and also make inconveniences for the guests.
