Forem: Rida F'kih

'Nothing Chats' is Not Secure.

Rida F'kih — Sat, 18 Nov 2023 08:30:42 +0000

Contributors

These findings were discovered in a joint effort between Batuhan İçöz, 1Conan, and I. Follow them on Twitter, they are both extremely talented.

Background

On November 16th, 2023, alongside an announcement by MKBHD, Nothing announced ‘Nothing Chats,’ an application exclusive to their hardware which brings iMessage to Android in a partnership with Sunbird. ‘Nothing Chats’ is a reskinned version of the existing Sunbird application, currently available on the Google Play Store.

After seeing conflicting statements related to the security of their application, members of the Texts.com reverse engineering team decided to take a look into the Sunbird application and their security practices.

‘Sunbird’ and consequently the ‘Nothing Chats’ application require sending your Apple ID credentials to their servers, where they authenticate on your behalf using a virtual machine running MacOS. If you’re an Apple user, this is the same Apple ID which you use to access your notes, photos, iCloud storage, email, and more. Preliminary findings were tested against the ‘Sunbird’ application, but we used the official ‘Nothing Chats’ application to confirm these vulnerabilities affected Nothing’s version as well.

Notification

Immediately, the Texts.com reverse engineering team noticed a few vulnerabilities and implementation issues which Kishan briefly outlined on Twitter / X. The main issue outlined being a vital request containing important credentials happening over an unencrypted channel (HTTP)

// Detect dark theme var iframe = document.getElementById('tweet-1725586252630540555-333'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1725586252630540555&theme=dark" }

Sunbird’s Response

Sunbird responded by denying any vulnerabilities, and justifying their implementation, doubling down on it being secure.

In short, they made a few claims.

Sunbird has ISO27001 certification, which testifies to their commitment towards security.
The HTTP request which as subject of concern is only a one-off request to notify of an iMessage connection, which then takes place on a secure channel.
The data is encrypted before being sent over HTTP with a key provided over HTTPS.

Whether or not they are using another service behind the scenes is impossible to tell, and they may be telling the truth that this is just a naming conflict between the pre-existing BlueBubbles service and their own internal service.

ISO27001 in this case is irrelevant. While its good to be committed to privacy and security, execution matters.

Other points of the response simply display a misunderstanding of the functionality of the technologies they’re leveraging, the primary one being JWT (JSON Web Tokens). JWTs are signed, not encrypted. Their payloads are accessible, and they themselves act as an access token.

In this case, the JWT is used to authenticate a user into the realtime Firebase database. It allows them to access storage which includes their account information, messages, accounts / connections, attachments, and more.

Vulnerabilities

Data in Transit Vulnerability

While Sunbird’s claim that they generate and send the JWT over a secured channel are true, the application immediately turns around and sends the JWT back to another Sunbird service hosted on a load-balanced Express server which does not implement SSL, so requests can be easily intercepted by an attacker.

The endpoint in question can be found at http://monarch.sunbirdapp.com:8888/register and accepts two fields in a JSON body. name which contains our Apple ID, and token which contains our JWT.

Transmitting our JWT over an insecure channel is very dangerous, because it acts as an API token which we can use to access all our data. By nature, JWTs cannot be easily invalidated on the server side. If an attacker gets their hands on it, they have unfettered access to the resource it grants until token expiry. In this case, all our account details, messages, attachments, etc., all in realtime.

By not implementing SSL, we’ve compromised level 7 of our OSI model. If an attacker compromises any point along our network pipeline between the application and the aforementioned Express server, our JWT can become compromised and an attacker will gain access to the information we’ve entrusted to Sunbird / Nothing Chats.

Attacks can be user-targeted, if you’re on a non-WPA network, a WPA network with a cracked PSK, or a compromised network hosted by an attacker, they can easily steal our packets, and your JWT.

The real danger begins as we walk down the network pipeline. Depending on the implementation of the load balancer, Express server, or encompassing network, an attacker targeting the server-end could gain access to any and all users who authenticate into iMessage once their attack begins.

You can see a screenshot of us intercepting a JWT sent over HTTP in the next section as part of a greater attack demonstration.

Data at Rest Vulnerability

Sunbird does try to implement E2EE, although their implementation is overshadowed by decrypting, and then storing the unencrypted payloads in their database.

When a message or an attachment is received by a user, they are unencrypted on the server side until the client sends a request acknowledging, and deleting them from the database. This means that an attacker subscribed to the Firebase realtime database will always be able to access the messages before or at the moment they are read by the user.

In the following screenshot, we’ve intercepted the JWT.

We then take it, and authenticate into our Firebase realtime database. This subscribes us to changes that occur in this

At this point, with nothing but the JWT, we could easily create a script which could download all information regarding the user and all their conversations with just 23 lines of code.

To demonstrate this, I sent myself the following message from my real iPhone to an account linked with ‘Nothing Chats’, and then requested the relevant data from Sunbird by running the script. You can see it is visible in plaintext, sans-encryption.

Insider Threat / Data Exposure

When you send a message using Sunbird or Nothing Chats, the data relating to your message including the contact information, message contents, and attachment URLs are sent to the Sunbird’s Sentry (a debugging platform), which can then be viewed by authorised parties within the company. This contradicts the FAQ item sourced directly from the Nothing website as of November 17th, 2023.

Are my messages secure?

Yes, Nothing Chats is built on Sunbird’s platform and all Chats messages are end-to-end encrypted, meaning neither we nor Sunbird can access the messages you’re sending and receiving.

By sending unencrypted outgoing messages to Sentry, authorised individuals at Sunbird would be able to view them from their Sentry dashboard. This makes them susceptible to insider threats. Here is the text content of a request sent to Sentry from the official ‘Nothing Chats’ application. The entire payload includes more messages, and information about the sender and recipient including their contact information.

Is It Real?

If you’re a ‘Nothing Chats’ user and are viewing this around November 17th, 2023, you may be able to see it with your own eyes. Within a matter of minutes, Batuhan İçöz created an open-source proof of concept which allows you to observe the lack of E2EE in your own browser.

Simply go to batuhan/sunbird-poc, and once you have a good understanding of the code, visit the URL listed on the repository sidebar. Authenticate into your ‘Nothing Chats’ account. Send yourself some texts, and observe your account details. It’s important to note this repository contains no decryption methods, so if E2EE was implemented, you wouldn’t be able to see your account and text information.

Conclusion

Sending your credentials to third-party services always presents a significant risk. It’s always important to stay vigilant with your information, and consider the security implications of sharing any. By sending our Apple ID to a third-party service, we are not only trusting the third-party with our texts, but should they become compromised, our photos, videos, contacts, notes, keychain, and more.

I Re-Wrote These 10+ Single Lines of JavaScript Code, the Team Lead Praised the Code for Being Elegant

Rida F'kih — Thu, 20 Oct 2022 04:58:25 +0000

I am the Team Lead, I praised the code. /s

This post is in response to, but by no means a dig on the blog post written by Zard-x on Medium called ‘I Wrote These 10+ Single Lines of JavaScript Code; the Team Lead Praised the Code for Being Elegant’.

One-liners are really cool challenges and very fun to make. I used to spend a lot of my time on codewars.com and codingame.com, which are two websites that facilitates little coding challenges which challenge your ability to write short code, or write code fast.

While code golf can serve as a fun engineering exercise, their lessons should rarely be used in the real world—and when they are—by no means should engineering managers be promoting developers to use this type of code in a codebase. When you’re in a collaborative environment, writing good code should be a priority. That means code that is readable, maintainable, and runs reliably.

Code golf is a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that solves a certain problem.

— Wikipedia, Code golf

Array Deduplication

Original Source Code

I’m not necessarily opposed to the common trick of removing duplicates from arrays by instantiating, and spreading a set, but due to the amount of times you’re indexing the array, it can be quite poor performance-wise.

Rewritten Source Code

On an array of 1,000,000 randomly generated numbers between 1 - 100, the original source code only performs at 12% of the speed that the rewritten version does. Since we use a map in the second function, we only have to iterate once over the array, and made it so that checking to see if we’ve already seen an element takes O(1) time.

The code eliminates “tricks,” and instead implores a well-known concept like hash maps, which may reduce the occurrence of inquiries by other developers on your code. The code also has well-named variables, with the function name removeDuplicateStrings defining the action that the function is doing, rather than an ambiguous name like uniqueArr, it also does not use excessively abbreviated words, making the code easier for non-native English speakers to understand.

Notice that the function is not documented. Excessive documentation can sometimes be a bad thing. If your variable names are well named, you may find your comments redundant, and that’s a good thing! If that happens, happily drop ‘em, and ship it!

If we’re absolutely dead-set on using spread operators and sets, or we want to remove duplicates of values that are not exclusively strings without writing bloated functionality, all we need to do is document our code, and ensure our variables are well-named.

Get Parameters from a URL and Convert Them to Object

Original Source Code

If there was a bug with this code, how excited would you be when you figured out this is the function you’d be working on? Odds are, not so much. Not to mention that re-building JSON objects with strings is something you want to avoid as much as possible, in this case that’d be quite easy.

Rewritten Source Code

In the rewritten code for this function, we use the convenient native JavaScript URL API which automatically invokes an instance of the URLSearchParams object for us, then we simply use the Object#fromEntries function on the resulting object! This prevents us from having to manually construct a JSON object by mingling and mangling strings.

Notice that we’ve provided a comment for this function! Despite the fact that I’ve included a specification for which type of parameters the function handles in the name of the function getURLParameters, it’s not necessarily clear what format the resulting object would be in.

Check Whether the Object is Empty

Original Source Code

Using ownKeys or Object.keys are both not very performant when checking if an object is empty.

Rewritten Source Code

This rewritten code is an old school method, and man has it passed the test of time! The re-written source code performs 20 times faster than the original method, and that’s only with two properties on an object. The performance boost comes from the fact that you no longer need to create arrays, copy over values, and index keys. You see one key and you’ve escaped the function!

It might not immediately be obvious why we’re iterating over the keys of the object, so we’ve left a short comment in there to ensure that any other developers know what’s going on.

Reverse the String

Original Source Code

In this case, we’re not off to a bad start! We could use a for-loop to get an 80% performance boost on short strings, and we might consider implementing that method if we’re reversing some chunky strings often, but in the case of the odd reversal on lightweight strings, we might just be better off with this functionality.

Rewritten Source Code

Splitting the chained methods across multiple lines is a personal preference of mine, as it allows me to scan the function paths rather than jumping through them, however if someone asked me to change it I wouldn’t make a fuss.

For fun, here is a more performant version.

Generate Random Hex

Original Source Code

Once again, not off to a bad start! I particularly like that we’re directly referencing the maximum hexadecimal value supported for non-alpha colours! Some minor cleanup, and we’ll be in business!

Rewritten Source Code

The only major change I made in this example is that I changed padEnd to padStart. The way this function works is by generating a random 24-bit integer, and then representing it in its hexadecimal format.

The minimum value we can get is 0 0x000000, with the highest value being 16,777,215 0xFFFFFF.

Let’s say our randomValue ended up being 255. Our hexValue would then be ff, and if we padded the end, our return value would be #ff0000, versus if we padded the beginning it would be #0000ff. If we then translate both these values back into integers, #ff0000 would actually represent the value 16,711,680, while #0000ff would represent 255. This means that if we pad the end rather than the beginning, we’d effectively get the wrong value.

In addition to this fact, with the first method, by padding the end rather than the beginning, #0000ff would actually be impossible to generate. Meaning there are plenty of missing values that could not possibly be generated. Specifically, every value between 0x000001 and 0x100000. That is 1,048,576 missing values from our function, but would also tip the odds in favour of all values that end with a 0, some more than others. For example, #100000 would be the result from 0x1, 0x10, 0x100, 0x1000, 0x10000, and of course 0x100000.

Conclusion

That took longer than expected, so I’ll be posting a second part to this blog post at a later date. I had a ton of fun refactoring this code. Would you have done something differently? Leave a comment on Medium or dev.to! I think this is a great learning opportunity for myself and others that might be in their code-golfing phase.

Want to read more of my stuff? You can check out my personal website. If you’d like to start a dialogue, feel free to tweet at me!

Happy 20th birthday Jira! You suck so bad.

Rida F'kih — Thu, 06 Oct 2022 06:22:31 +0000

What is Jira?

For those lucky enough not to know, Jira is the biggest and by far most popular project management and issue tracking tool in and out of the software development space, developed by Atlassian, founded in 2002, and still one of Australia’s biggest international startups.

Atlassian has created an insanely powerful, customizable tool which boasts robust integrations, every product management feature you could ask for, and yet it seems that it’s often not the case that it’s seen as a piece of software more than it’s seen as a way of life. People live by Jira, and they’ll die by Jira, and I think it just sucks.

How does Jira suck?

The Workflow Detriment

Jira—as the software that handles my issues in a daily basis—should be the piece of software that I interact with the most on the daily aside from a team communication platform. ie. Discord, Slack, etc.

However, as much as I want to use Jira in that way, it just can’t be well-integrated into my workflow. It is tucked away into my web-browser, with slow load times combined with convoluted & unintuitive nested navigation to get where I need to go. I should not need to have a special, dedicated “Jira Hole” in my bookmarks to use it effectively.

Design Oversight Extravaganza

Jira is riddled with what are quite frankly some of the worst design oversights I have seen in any piece of “enterprise ready” software in my life.

Dare you accidentally hit the wrong key while crafting a lengthy, yet beautifully written text: it shall be sent to the nether never to see again, not a warning in sight. I often find myself in navigation loops, find myself making dead-clicks, or having to click buttons that are not buttons **to get where I need to go.

User experience & user interface design is a very specialized and developed topic in 2022, I’d even consider it a science at this point, and Atlassian has managed to do it so poorly I simply cannot even fathom what is going on behind the scenes. I am a very download-happy person when it comes to trying out new software, and Jira’s user interface has to be the least intuitive, worst-design piece of garbage I have ever had the displeasure of laying my eyes on.

For software with origins in software development, it baffles me that Jira doesn’t support dark-mode. This means every time I open it, I get flash-banged.

Accessibility & Responsiveness

Thankfully in 2022, 20-years after it was created, Jira has finally addressed the inability for non-sighted users to use their software, yet it’s still not responsiveness to varying screen sizes. Come on.

Context Switching

The lack of a native application combined with the unintuitive UI, convoluted navigation, long loading times, content-layout shifts, inscrutable elements, etc., switching to Jira to edit, update, change or comment on a ticket requires a genuine need for context switching. Meaning it’s very common that you’ll lose momentum on tasks with higher cognitive load directly resulting from Jira.

The cluttered UI alone makes me feel like I’m operating a Boeing 747 in the comfort of my ergonomic chair, all while only having to flip one or two switches and click a button.

Performance

Working with Jira is like using the controls of military tank to drive a Tuk-Tuk. Complicated yet slow. Fun fact, when you open lightly populated Jira board view, you download ~24MB of data cross ~350 requests, and every ticket you preview is an additional ~20MB across ~90 requests.

That means if you open the Jira board view, and preview 10 tickets, that’s almost a quarter of a gigabyte that you just downloaded across over 1.25K requests, much of it uncached and redundant.

If we compare this to Notion with a highly-populated workspace, it initially downloads ~13.5MB over ~120 requests, with each previewed page downloading only about ~0.2MB over ~20 requests.

Customization Galore

One complaint many others have with Jira is just how customizable it is, management will go absolutely crazy with making Jira a completely new product, implement blocking processes and intense red-tape, and that’s why when someone complains about Jira the catch-all response is either “you’ve configured it wrong,” or “you’re using it wrong.”

Despite that fact, my experience with Jira has been rather minimalistic, never have I been on a team with overcomplicated processes around Jira itself, nor did we go crazy with the customizations, yet it was still problematic and abrasive to use.

Why does Jira suck?

Jira promotes bureaucracy-rich workflows that are built to convenience off-the-floor workers, managers, executives, etc., at the expense of those who are interfacing with it on a daily basis. As I outlined in the intro of this post, Jira is an insanely powerful tool, just not for the people who have their sleeves rolled up high. It generates amazing reports, fantastic predictions, fancy charts, great managerial tooling, makes imposing processes easier, has robust integrations, etc., and that’s why most managers I’ve spoken to really enjoy Jira, while on-the-floor engineers either range from fiery-eyed hate to toleration.

I think Jira does a good job of making teams look much busier than they are, but in the end I see it more as a “talk more not do more” situation.

A very common response I get when I ask developers why they use Jira is because they either don’t care, or haven’t found a suitable alternative.

The Alternative

Linear

Linear is the perfect antithesis of Jira. Rather than a slow, loose, unintuitive ticket management experience, Linear provides a highly fast and intuitive UI with realtime changes wrapped in a beautifully crafted, opinionated platform built with software developers in mind. It cuts out the unnecessary bureaucracy and leaves engineers with a ticket management experience that integrates very well into their day-to-day thanks to its desktop application, theme customizability, command palette, offline functionality, and speed. It integrates into a plethora of software including Zendesk, Intercom, Figma, GitHub, GitLab, Zapier, and gives you full-access to built custom integrations using their GraphQL interface.

Linear has been a pleasure to use on the teams I’ve worked on that have opted for it, as well as a no-brainer for collaborative personal projects. Although a potential downside to Linear is that it is built explicitly for engineers, thus may not be suitable for other teams such as marketing, design, etc.

Other Alternatives

If you’ve given Linear a try, but it just doesn’t work for you, some viable alternatives include GitHub Issues, Asana, ClickUp, YouTrack, Trello, Pivotal Tracker, and monday.com.

Real Quotes from Jira Users

If my article wasn’t enough of an articulation of the common frustrations with Jira, a small directory of quotes exists on a website called ifuckinghatejira.com, here are a few excerpts.

Jira is middle-management-ware, a term I made up for software that serves the needs of middle management, or, at least, the needs middle management thinks it has, which comes to the same thing as long as you’re selling to them. What are those needs? Metrics. Being able to make charts and graphs and summarized reports for the next-higher level of management, so they can say that their team is productive.

Every time I open Confluence or Jira I want to claw my fucking eyes out. It’s slow, hard to navigate, and terrible.

Tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it gets taken for the central thing. This is an illusion. Fixing a bug without filing a JIRA ticket is in itself progress. Moving a JIRA card without any other change is not. Yet the second is what’s visible and therefor what’s rewarded.

I hate Jira. You need to watch a few hours of tutorials to be able to understand this piece of crap.

The momentum of its user base plus incoherent analyst opinions only serve to discourage moving to something actually useful/modern/user centered/updated/etc.

It is bad, really bad, like come on your page takes 5 seconds to load on every click with a 100Mb internet and loads of ram, seriously? I don’t want to talk about the super unintuitive interface. It is basically cancer. And you can’t use something else if your organisation decides to use it.

it’s not meant for devs but for project managers - and project managers like to make the devs do their job in that horrific tool. Imo there should be a dev view that is dead simple, and a PM view with all the complicated bells and whistles.

Even stripped down, it’s still too complicated. The wealth of features tend to lead to practices that can be bad for overall productivity even if they look useful on the surface.

JIRA is powerful. BUT… the UX is bloody awful. As in makes me want to stab myself in the eyes daily. The number of times I’ve lost content due to terrible and buggy UI is growing numerous.

JIRA. Fucking JIRA. Everybody just fucking hates it. It tops the list of shit pieces of software by a fair margin, followed by JIRA in second place and JIRA in 3rd.

Jira presents an excellent exercise on how not to do UX. The interface is slow, cluttered and unresponsive. Want to figure out how to do anything? God help you, because the design certainly won’t.

I avoid doing any kind of work with JIRA besides what’s absolutely necessary - and even then I pull my hair out in frustration.

Jira is so mind bogglingly awful, clunky and slow, I would rather peel off my skin and bathe my weeping raw flesh in a bath of vinegar than have to use Jira for one more day!

ifuckinghatejira.com

The Power of Pissing Code, and its Place in Answering the Age-Old Question: “TypeScript, or JavaScript?”

Rida F'kih — Mon, 20 Jun 2022 07:27:15 +0000

New developers often ask whether they should use JavaScript or TypeScript, and while the answer will almost always be TypeScript, writing JavaScript has its place.

TypeError: Cannot read property 'typeScriptOrJavaScript' of undefined

A classic error. Some might say a rite of passage even.

Every developer has experienced it, and most developers are now equipped with both the experience and tools to avoid silly little errors like it. One of those tools? TypeScript.

For the unwitting beginner, this error stems from accidentally (or purposefully, if you’re a masochist) assuming an undefined variable is an object, and trying to access a property of that undefined value.

const undefinedVariable = undefined;
undefinedVariable.nonExistentProperty;
// TypeError: Cannot read property 'nonExistentProperty' of undefined

TypeScript to the Rescue

With TypeScript, small issues like this can be caught during development, meaning they’ll never see the light of day in runtime. With no changes to the above snippet, TypeScript would have warned the developer that the code is invalid outlining exactly what needs to be changed, in this case: ensuring undefinedVariable had a property called nonExistentProperty, or removing the invalid property access attempt.

type ActuallyDefinedVariable = {
    nonExistentProperty: string;
};

const undefinedVariable: ActuallyDefinedVariable = {
    nonExistentProperty: "I'm defined!",
};

undefinedVariable.nonExistentProperty; // ✅ TypeScript Approves

The Forbidden Keyword

Any language has its own set of bad practices, and TypeScript isn’t immune. I’ve seen both beginners and experienced developers alike resort to the keyword any, which is a catch-all type in TypeScript. It allows you to essentially bring JavaScript to TypeScript by removing static typing for a variable.

let numberVariable: number = 5;
numberVariable = "string"; // ❌ TypeScript Error

let anyVariable: any = 5;
anyVariable = "string"; // ✅ TypeScript Approves (but we don't)

When complex typing becomes an issue, some developers simply resort to any, but this defeats the purpose of TypeScript by removing the nice, strict typing that TypeScript provides. I personally use ESLint to disallow any from appearing anywhere in codebases I’m collaborating on, and I recommend you do to.

TypeScript or JavaScript?

This is a question that every beginner wants to know. TypeScript can seem like a hurdle to newbies, and she’s definitely more intimidating than her older sister: JavaScript, but once you get over the relatively small learning curve, the benefits pay off immensely.

I’m hard-struck for a reason to tell anyone to go with JavaScript on any project with even an ounce of complexity. TypeScript’s static typing improves the developer experience, and eliminates time lost debugging. Not to mention the improvement to ease-of-collaboration through the enforcement of better practices, making code more skim-friendly & clear.

However, I would be lying if I said that writing raw JavaScript didn’t have its place.

The Power of Pissing Code

Pissing code is a rather inelegant name for a style of coding I and other developers often find themselves doing. Similar to shaking your bike lock every time you pass it to make sure its not magically at risk of being stolen, sometimes we developers like to double check to make sure the language we’re working with is going to function the way we expect it to.

Perhaps you want to quickly plan out a function before introducing it into a library, test a build-in method before using it in a codebase, maybe you’re just trying something new, or you simply need to write a one-off script you’re never going to touch again.

If there is no permanence, complexity, or collaboration intended for the code you’re writing, piss it into a one-off JavaScript file or a Quokka session and call it a day. Since the codebase isn’t living on, the benefits become less tangible and rewarding. If the code is short-lived, or you’re just testing something out, just piss it into a file.

Conclusion

If the code is hitting version control, you’re collaborating with others, the code is complex, or its going to be used multiple times, its best to use TypeScript and reap the rewards, otherwise don’t feel guilty for pissing the code into a file or repl you’re never going to touch again!

If you liked this post, check me out on Twitter to be kept up to date on future posts! ❤️

Maintaining TypeScript Superpowers When Types Are Out of Reach

Rida F'kih — Wed, 13 Apr 2022 15:51:02 +0000

It’s all too common. You’re coding away in TypeScript, utilizing an external library, and you’re digging around the code for that type you just can’t find and… bam! The type you’ve been searching for is not exported!

You could either re-create the types locally, fork the repository and export the types, or work with what you’ve got! Today, I’m going to show you how to do the latter.

Inferred Return Types

Let's say we're utilizing a function from an external library which returns an object that lacks explicitly defined type information as follows.

const divideNumber = (dividend: number, divisor: number) => {
  const quotient = dividend / divisor;
  return { dividend, divisor, quotient };
};

/**
 * This function serves as an example of a function which returns
 * an inferred type, meaning the return type is not explicitly
 * defined by the developer.
 */

When using this function, TypeScript will automatically infer the type as follows.

{
     dividend: number;
     divisor: number;
     quotient: number;
}

/**
 * This is what the inferred return type of the previous function 
 * looks like.
 */

This is fine for basic usage, but if we want to do something with the type, it may become difficult.

If you're unfamiliar with the ReturnType, your first instinct might be to recreate the type yourself as follows, but doing so means we’ll be deviating from a single source of truth.

interface DivisionObject {
  dividend: number;
  divisor: number;
  quotient: number;
}

/**
 * This is a bad example of a solution to define a type for the
 * return type of the previous function.
 */

Thanks to ReturnType, which takes a generic—that being a function type signature—returns its return type, even if its not explicitly named.

We can either use it directly, or assign it to our own named type.

import { divideNumber } from "@fake-library/math";

type DivisionObject = ReturnType<typeof divideNumber>;

/**
 * Here we are using the ReturnType generic to define a type as
 * the inferred return type of the divideNumber function.
 */

Now we are able to use this as a property in another local function.

const verifyDivision = ({ dividend, divisor, quotient }: DivisionObject) => {
  return divisor * dividend === quotient;
};

/**
 * Here we're taking the type we defined and defining it as the
 * first property of the verifyDivision function.
 */

🎉 Awesome! This is so much better!

Nested, Unnamed Types

Sometimes we do have an exported type, but we just want one property of that type. Again, if you're unfamiliar with TypeScript your first instinct might be to simply redeclare the type. However, we can actually access that by simply using our handy square brackets.

Let’s say we have the following interface.

interface HumanBeing {
  firstName: string;
  lastName: string;
  locale: {
    country: string;
    language: "english" | "french" | "spanish";
    timeZone: string;
  };
}

Now let's say we want to create a function that checks if a human being’s language is English.

type HumanBeingLanguage = HumanBeing["locale"]["language"];

const isLanguageEnglish = (language: HumanBeingLanguage) => {
  return language === "english";
};

✨ Easy peasy, right?

Variable Unnamed Object Type Signatures

This one is a little more obscure, but something I ran into while creating a custom Notion renderer for the latest version of my personal portfolio. If we have an array where we have multiple possible type signatures of objects, and the possible object types in question are not named, things can get yucky very quickly.

type CustomHTMLElement =
  | {
      tag: "img";
      attributes: {
        src: string;
        alt: string;
      };
    }
  | {
      tag: "video";
      attributes: {
        src: string;
        type: string;
      };
    };

/**
 * As you can see, the above type can have multiple different
 * object type signatures, despite being under the same namespace.
 */

As you can see, the attributes are inconsistent.

Let’s define an array of objects which utilizes our CustomHTMLElement type.

const customElements: CustomHTMLElement[] = [
  {
    tag: "img",
    attributes: {
      src: "https://example.com/image.png",
      alt: "Example image",
    },
  },
  {
    tag: "video",
    attributes: {
      src: "https://example.com/video.mp4",
      type: "video/mp4",
    },
  },
];

Let's say we want to get a list of all the img elements, our first instinct might be to use the raw Array#filter method.

const getAllImgElements = () => {
  return customElements.filter(({ tag }) => tag === "img");
};

getAllImgElements().forEach((element) => {
  element.attributes.alt; /** Property 'alt' does not exist on type
                            '{ src: string; alt: string; }
                           | { src: string; type: string; }'.
                                                    */
});

/**
 * Unfortunately, using filter with this type, we get an 
 * error since TypeScript cannot make an inference from this
 * method.
 */

As you can see, the problem with this is Array#filter does not immediately respect type inferences. TypeScript still has no idea that any of the other object types have been eliminated as a possibility.

In this case, the inferred type of the return type of the getAllImgElements function is () => CustomHTMLElement[], so we still have the exact same original degree of ambiguity.

Thankfully, we can leverage the Extract generic type available in TypeScript 2.8+ combined with a TypeScript predicate to tell TypeScript what to expect after we’ve filtered.

type CustomHTMLElementTag<T> = Extract<CustomHTMLElement, { tag: T }>;

const getAllImgElements = () => {
  return customElements.filter(
    (element): element is CustomHTMLElementTag<"img"> => element.tag === "img"
  );
};

getAllImgElements().forEach((element) => {
  element.attributes.alt; /** TypeScript is happy! 🎉 */
});

/**
 * Here, we're using a type guard, a type predicate, and the
 * TypeScript Extract generic to tell TypeScript which type
 * is making it out the other end. 
 */

Conclusion

TypeScript is an absolute beast, but because of the nature of its subset language: JavaScript, things can get a little funky sometimes. Luckily, we all love a challenge.

You can read more content like this on my personal blog!

If you liked this post, check me out on Twitter to be kept up to date on future posts! ❤️

How to Not Expose the Personal Data of 19,577 Canadians

Rida F'kih — Tue, 12 Apr 2022 17:34:46 +0000

A few months ago I spoke with CBC news to give an overview of a plethora of security flaws I found in PORTpass, an attempt to bring digital proof-of-vaccine to Canadians. While that article was meant for a broader audience, today I will outline their security flaws from a technical perspective for all the developers out there.

My Background

My name is Rida F’kih, I am a 21 year old Canadian software developer & reverse engineer at MaxRewards.

My development journey started at 15, from reverse-engineering to scammer-vigilantism then teaching coding to kids to web & mobile development.

What is PORTpass?

PORTpass was a private attempt by a local Calgarian entrepreneur to bring vaccine passports to Canadians.

What went wrong?

First, we must familiarize ourselves with Murphy’s Law.

Murphy’s law is an adage or epigram that is typically stated as: “Anything that can go wrong will go wrong."

— Wikipedia, Murphy’s Law

I’d argue that PORTpass was the epitome of Murphy's Law from the perspective of the user, and criminal negligence on behalf of its creator due to their inaction after these issues were brought to light.

The Data at Risk

The data at risk wasn’t light stuff.

PORTpass had the business requirement of collecting loads of personal data, collecting photos of government IDs, health card numbers, verification selfies, full names, dates of births, blood types, and more.

The data on PORTpass would be enough to be at risk of social engineering, or even have financial accounts opened in your name.

The Vulnerability

The primary vulnerability is called “Improper Access Control,” which is described by the Common Weakness Enumeration—a community-developed list of software & hardware weakness types—as “software [that] does not restrict or incorrectly restricts access to a resource from what should be an unauthorized actor.”

Some pseudo-code to describe a properly managed & created endpoint may appear as follows.

import express from "express";
import { loggedInUser } from "@/utils/authentication";
import { getUserInfo } from "@/utils/users";

const app = express();

app.get("/user/:userId", (request, response) => {
  const { userId } = request.params;
  const authenticatedUserId = loggedInUser(request);

   if (!authenticatedUserId  || authenticatedUserId !== userId)
     return response.status(401).send("Unauthorized");
   else
     return response.status(200).json(getUserInfo(userId));
});

Here, we would send a GET request to /user/[userId], and receive back user data only if we are authenticated into the same user we are requesting.

A poorly architected endpoint may be coded as follows.

app.get("/user/:userId", (request, response) => {
 const { userId } = request.params;
 if (!loggedInUser(request))
  response.status(401).send("Unauthorized");
 else
  response.status(200).json(getUserInfo(userId));
});

Here, we’re not checking which user is authenticated, only if the user is authenticated. Thus, an authenticated user could request ANY resource, even if it doesn’t belong to them. For public posts this is appropriate, for private information like government-issued photo IDs, health care cards, and confirmation portraits, this is a massive flaw.

The Catalysts

Sequential User IDs

PORTpass users requested their resource by using sequential user IDs. This means that if you were the first user to sign up for their service, your ID would be 1, if you were the second, it would be 2, etc.

Had they used a cryptographic solution—such as UUIDv4—scraping user information would have been significantly more difficult, however in this case formulating a script to collect all registered user data would be trivial, and would look something like...

/**
 * Gets the user profile from the PortPass API.
 * @param {number|string} userId The user ID of the target user.
 * @returns {Promise<any>} A user object.
 */
const getUserProfile = async (userId) => {
  const profile = await axios
    .get(USER_PROFILE_URI + userId.toString())
    .then((response) => response?.data)
    .catch(() => ({}));

  return profile;
};

for (let i = 0; i < 19577; i++)
  getUserProfile(i + 1).then(saveUserData);

No SSL

Since PORTpass didn't have SSL certificates, packets that your device sends or receives could be altered or intercepted. With websites, its easy to identify a secure website by finding the little "lock icon" next to the URL, however with applications its a little more ambiguous.

Exposing Developer Tooling

PORTpass' backend was created using Django, which has an interface which allows you to test endpoints from your browser without having to use REST tooling like Postman, or Insomnia.

Optimally, PORTpass would have secured their endpoints so knowing their paths would provide no additional capabilities, however, they didn't, and thus traversing their entire backend was trivial.

Conclusion

We all want to get our projects out there, but if we don't have the experience necessary to accommodate for basic security considerations, getting your code reviewed or learning the basics of security should be considered good options.

In this case, a non-technical founder wanted to hastily get a product out there, so they hired a developer from overseas without the ability to evaluate the quality of code.

I'm very thankful to the CBC for their help in finally being able to hold the creator of PORTpass accountable, an address these concerns rather than simply ignoring them or claiming to be defamed.

You can read this article on Medium or my personal website.

If you enjoyed this content please consider following me on Twitter!