You’ve probably seen the Twitter posts, Cookgroups “calling out” other servers for stealing their links and monitors without consent. Threats of legal action; typically without any follow-through due to the anonymity and effort required to pursue.
What if that wasn’t needed? For almost a year we’ve been using an internal system designed to prevent links from being leaked from the Express Notify Discord server. Today I am open-sourcing the majority of our system so that other servers can take advantage of our software to shorten, protect and track their link usage.
Before we jump into any technicalities, I want to explain more about link leaking, how it works and why it should bother you as a typical end-user or developer. When you think of leaking, you are probably thinking of a person sharing a link (maliciously or ignorantly) from one place to another without consent.
What if I told you that is just a small part of the leaking community, there are servers dedicated to stealing links, monitors and information from premium groups through user bots. A user bot is a regular Discord account that is being accessed and controlled by a script. There is no way to tell who is and isn’t a user bot, and although this is against Discord’s terms of service, there doesn’t seem to be much action to try and stop it. But why should there be? User bots can bring a lot of additional functionality to enhance your Discord experience. I’ve used them myself to mass-delete direct messages, amongst other things. They’re not inherently malicious except for in our community.
Here’s a little diagram I whipped up on MS Paint which shows how a user bot steals webhooks, this webhook theft can happen in under a second and currently there’s isn’t an easy solution to prevent it.
Oh sure, theoretically, you could restrict users one-by-one or in batches and see if your webhook still appears in the mirror server, narrowing down users slowly, but that’s messy. A competent developer could even check for when that is happening and throw you off track.
So why should this bother you? A cookgroup all comes down to their success, maybe there’s some hype to season it, but the regular user doesn’t want to pay a monthly subscription for something they’re not making money from (When the goal is to make money).
Imagine that you’re in a high-end cookgroup paying $50 a month. You might see 400 other members inside that server and think you’re getting access to the latest, most exclusive and best monitors and group buys. In reality, a single user inside that server could be mirroring that server and broadcasting the webhooks to a thousand other members in a different group, all because the links aren’t being protected.
You might blame yourself; you might think the reason you were unsuccessful during a group buy was that you’re slow, but you could be competing with a lot more users than you think.
I’m sure some of the developers reading this have burning questions right now; Allow me your time, and I will explain everything, there are several more benefits than just catching leakers.
What is Authcord?
Authcord is middleware that handles almost all the essential links that pass through Express Notify’s server. When a monitor sends a webhook, the URL we want the user redirected to is converted into a shorter, untranslatable link. When this link is clicked, Authcord checks if the user has a valid membership before continuing the redirect to wherever they were meant to go.
How does Authcord check if a user has a valid membership?
Although all this is configurable to the developer’s specification, by default, a user is allowed 2 IP addresses bound to their account. If the user is accessing from a bound IP address, it will automatically qualify them access without requiring any more validation.
IP Address verification alone could cause user experience problems caused by non-static IPs, VPNs & proxies. These delays in being able to access content could cause them to miss out on a group buy, or be just slightly too late to purchase during a restock.
To help prevent this, we also allow for five authenticated browser sessions, whenever a user signs in to your website, a cookie is set on their browser. This cookie is then checked against a database of valid sessions when they click a link. If a match is found, they’re allowed through to wherever they were heading.
Another method that you can optionally enable or disable would be user session verification. If the user is signed into their *insert cookgroup name here* account, then they’ll automatically be redirected, similar to browser authentication except it wouldn’t necessarily require querying a database; instead, it would just check for a valid user session.
What if my program first finds the link you’re protecting, then redirects that to the webhook instead?
NOTE: I’m going to ramble on now because I truly believe this system is almost perfect and unbeatable. Remember, it only takes catching a simple mistake (such as an unstripped query parameter) to track the leaker and ban them. Once tracked, it would be elementary to follow their IP/mistake to catch them in future attempts, capturing a single leaker could mean they’re banned from multiple servers too (Woohoo). Feel free to scroll past this section and take a look at some of the other, beautiful benefits Authcord can provide if you’re not interested.
You more advanced developers might have thought of this one. Possibly, somebody could create a bot which detects a webhook, authenticates themselves with one of the verification methods and then sends that modified link to their mirror server, right?
Wrong. Authcord has the option to give every user a different link on the redirection, using URL character randomization (in some places), useless query parameters and capitalization. These unique links mean every user is trackable and therefore responsible for where their link ends up; Undeniable evidence and a direct relationship between each user and their URL.
We could go really, really deep into this topic because theoretically, a bot could also detect all of those link randomization techniques and strip them before posting, we could fight back by using dynamic Javascript obfuscation and do client-side redirects instead of 3XX redirection (and other Antibot techniques).
Although I haven’t directly included any algorithm to detect who are and aren’t malicious; Here are just a few factors you could use beyond manual verification to automate malicious request recognition.
- How fast the link had an HTTP request made to it. (Bots would usually be instant, but a good developer could hide it purposely with a small delay)
- Are they using modern, non-bot user-agents? Are they using the correct headers which match their user agent?
- You could add an image/JS/CSS file and see if an HTTP request was made to that.
You might not always be able to use random query parameters or random text in replacement of other characters, how “advanced” you can make your redirect obfuscation is entirely up to the developer. Each type of link obfuscation would require a unique schema to be created by the leaker as the technique used to access each site is diverse, and a “global” schema to prevent all types of link obfuscation (such as stripping query parameters from every URL) would cause massive issues on some sites where they’re required to display the product.
If a user isn’t automating the link deobfuscation, it would require a lot of site knowledge about what is and isn’t necessary to access each site. Along with this, it would take a considerable amount of time to manually strip all the potential link obfuscating techniques (Even a few seconds would be a massive disadvantage for the leakers on a group buy or restock)
Even then! Let’s assume somebody has a perfect link deobfuscator.
Ok so let’s say somebody has beaten your deobfuscation tactics, they’re able to strip down each every link to its base form. How do they execute this without being caught? They can’t! Having a bot that accesses these shortlinks 24/7 with a low reaction time would be blatantly obvious, no real human is using Discord all day every day and clicking on every webhook sent, people miss restocks and webhooks all the time. Mirror bots do not.
So then what? The mirror server would have to program in real human delays, sleep cycles and purposely miss webhooks. If they get greedy they’ll get caught.
Does creating these links create a delay when redirecting users?
Yes, on our server running NGINX as a reverse proxy with SSL and a remote database (all on Google Cloud Platform) it adds about a 50ms delay when redirecting users; 1/20th of a second.
When we create these links, we synchronously generate a code and assume that the data will be saved correctly in the database before the Discord webhook arrives and users click onto the link. This means there’s no real delay at all when generating the links. There could be duplicate codes in the database, but they’re so rare that we can query the latest row for that code and the chance of clashing with another link in the same time-span is non-existent.
Apart from leak prevention, what are the other benefits that you get from using Authcord?
Shorter Links — Shorter links means you can fit more content inside a Discord webhook embed. At Express, using our custom redirect domain, we shortened our link lengths to just 25 characters from 50+. This shortening alone means we can usually fit an ATC link and two quicktask links per size. (3 links, per size, for up to 13 sizes in one embed). There’s nothing worse than missing a webhook because you went over the 1024 character embed limit.
Easy Add To Cart Links — With Authcord you can also choose to perform a link redirect with a POST request and provide form-data rather than only redirect via GET requests, I know you hate creating new routes every time you want to do an add to cart link.
Tracking — It’s just cool to know how your users use your server! You can use the data to see which monitors get ignored, which users are actively and consistently participating, which group buys are the most popular etc. This information is excellent for making informed business decisions and is a lot more reliable than “React if you want!”.
Extendable — You can extend Authcord to do almost anything you want, having middleware means you have more in-depth and fine-grain control over what users can and can’t do. An example of extending Authcord would be adding a queue system or a small game to restrict access to links until completed.
And that is all folks…
Sorry if there’s incorrect grammar or word usage; I don’t do much proof-reading. You can access the code via my Github here: This has been refactored, and although tested, I may have missed some things. https://github.com/unreleased/authcord
