Preface

Software security is one of those subjects that often gets overlooked, both in academia and in professional projects, unless you're specifically working with some existing security-related element (e.g. you're taking a course on security basics, or updating your password hashing algorithm). As a result, we frequently see stories of rather catastrophic data leaks from otherwise reputable businesses, leaks which should have been entirely preventable with even the most basic of safeguards in place.

With that in mind, I thought I would switch things up and discuss something security-related this time.

Background

It's commonplace for complex software systems to avoid unnecessarily large expenses, especially in terms of technical debt and the capital involved in the initial development costs of building entire systems for e.g. geolocation or financial transactions. Instead of reinventing the wheel and effectively building a parallel business, we instead integrate with existing third-party systems, typically by using an API.

The problem, however, is that sometimes these third-party systems process requests over a long period of time, potentially on the order of minutes, hours, days, or even longer. If, for example, you have users who want to purchase something using your online platform, then it's not a particularly good idea to having potentially thousands of open connections to that third-party system all sitting there waiting multiple business days for funds to clear. That would just be stupid. So, how do we handle this in a way that isn't incredibly stupid?

There are two commonly accepted methods to avoid having to wait around:

1. We can periodically contact the third-party system and ask for the current status of a request, or
2. We can give the third-party system a way to contact us and let us know when they're finished with a request.

Both of these methods work, but obviously there will be a potentially significant delay in #1 between when a request finishes and when we know that it has finished (with a maximum delay of the wait time between status updates), whereas in #2 that delay is practically non-existent. Using #1 is also incredibly inefficient due to the number of wasted status update requests, whereas #2 allows us to avoid that kind of waste. Clearly #2 seems like the ideal option.

Method #2 is what we call a webhook.

May I see your ID?

The problem with webhooks is that when you're implementing one, it's far too easy to forget that you need to restrict access to it. After all, that third-party system isn't a user, right? They're not a human. They can't just give us a username and password like we want them to. They don't understand the specific requirements for our individual, custom-designed system.

But what happens if some malicious actor figures out what the webhook endpoint is? Let's say that all we do is log webhook requests somewhere in a non-capped file or database table/collection. Barring all other possible attack vectors, we suddenly find ourselves susceptible to that malicious actor sending us thousands, possibly millions of fraudulent data payloads in a small amount of time thanks to a botnet, and now our server's I/O utilization is spiking and the entire system is grinding to a halt--we're experiencing a DDoS!

We don't want just anyone to be able to talk to our webhook. We want to make sure that anyone who does is verified and trusted. But since we can't require a username and password, since we can't guarantee that the third-party system will even know how to make use of them, what can we do?

The answer is to use some form of token-based authentication--we generate a unique token, kind of like an ID card, and we attach it to our webhook endpoint (e.g. https://example.com/my_webhook/{unique_token}). We can then check that token for validity every time someone touches our webhook, ensuring that only someone we trust can get in.

Class is in Session

Just as there are two commonly accepted models for how to handle receiving updates from third-party systems, there are also two common models for how to assign a webhook to those systems:

1. Hard-coding the webhook in your account settings, or
2. Passing a webhook as part of request payload.

Model #1 is, in my experience, the most common of the two. In this model, our authentication token is typically directly linked to some user or user-like object in our system. This token is intended to be persisted and reused indefinitely, only scrapped in the event of a breach or a termination of integration with the service that uses it. Unfortunately, if the token is present within the URL, it's possible for your token to be viewed in plaintext in your logs.

In model #2, it's perfectly feasible to mirror the behavior of model #1 by simply passing the same webhook endpoint with the same token in every new request; however, there is a far better solution. We can, instead, generate a brand new token for each new request to the third-party system, and each new token can be associated with the request itself on our own system. Rather than only validating the token itself, we then validate that the token and the request it's supposed to be associated with are both valid. This ensures that even in the event of a breach, a leaked authentication token's extent of damage is limited only to the domain of the request it's associated with! In addition, we can automatically expire these tokens after receiving a certain number of requests, ensuring that a DDoS using a single valid token and request payload isn't possible. As with model #1, however, we still run into problems of token exposure if the token is present in the URL.

Model #2 treats each individual authentication token not as a session for an entire third-party system, but as a session for a single request on that system. These per-request session tokens require greater effort to implement, but are inherently safer due to the increased granularity of our authentication and our flexibility in allowing ourselves to expire the tokens at will.

Final Thoughts

Security is hard. Even with per-request session tokens, webhooks still aren't as secure as we might like them to be. Some systems allow us to define tokens that will be inserted into the request payload, but more often than not you'll find that only a webhook URL is possible to specify. Ideally we would stuff those tokens right into the POST request payload for all of our third-party systems so they would never be so easily exposed in plaintext in log files, but legacy systems tend to be slow to catch up and newer systems often don't have developers with the security background to consider it.

Still, as far as securing webhooks goes, having some sort of cryptographically secure authentication token is far better than leaving the door wide open for any script kiddie having a bad day to waltz right in and set the whole place on fire. If you're integrating with any third-party system, your job isn't to make it impossible for them to get their hands on a key, but to make it really difficult and to make sure you don't leave any gasoline lying around in case they do.

I hope I’m posting this in the correct place. I’ve been having a disagreement with someone over the abilities of hackers. I kinda hope Deimorz pops in because he wrote automod.

I said that the only way for someone to gain access to a subreddit to make changes is if they steal a moderator’s account password or they are added to the mod team. The person I’m having a disagreement with believes that adding text to the wiki for users to view (like the extensive wiki r/skincareaddiction has) would make it easier for hackers to insert malicious code in order to gain access to the sub. This person also mentioned being able to change the subreddit through browser tools. She insists the sidebar and wiki are potential access points for scripting attacks. Automod just so happens to be enabled which is why I mentioned Deimorz.

I’m not an IT professional. My brothers currently are which helped me learn most of what I know. I’ve supplemented that over the years with whatever info I came across online. What she’s saying sounds like crazy town to me. But since I’m not a hacker, is there a way to use the sidebar or wiki area to hack into a subreddit?

Thanks in advance to anyone who pities me by providing a detailed answer to this thinly veiled request to help me win an internet argument 🙇🏾‍♀️.

Got this phishing SMSmessage today. I spun up a VM and investigated the domain provided in the message. Found the provider and reported it to them.

The phishing page is a replica Coinbase login page.

https://imgur.com/a/ZSzNKO7

Firefox recently introduced DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) in nightly builds for Firefox 62.

DoH and TRR are intended to help mitigate these potential privacy and security concerns:

1. Untrustworthy DNS resolvers tracking your requests, or tampering with responses from DNS servers.
2. On-path routers tracking or tampering in the same way.
3. DNS servers tracking your DNS requests.

DNS over HTTPs (DoH) encrypts DNS requests and responses, protecting against on-path eavesdropping, tracking, and response tampering.

Trusted Recursive Resolver (TRR) allows Firefox to use a DNS resolver that's different from your machines network settings. You can use any recursive resolver that is compatible with DoH, but it should be a trusted resolver (one that won't sell users’ data or trick users with spoofed DNS). Mozilla is partnering with Cloudflare (but not using the 1.1.1.1 address) as the initial default TRR, however it's possible to use another 3rd party TRR or run your own.

Cloudflare is providing a recursive resolution service with a pro-user privacy policy. They have committed to throwing away all personally identifiable data after 24 hours, and to never pass that data along to third-parties. And there will be regular audits to ensure that data is being cleared as expected.

Additionally, Cloudflare will be doing QNAME minimization where the DNS resolver no longer sends the full original QNAME (foo.bar.baz.example.com) to the upstream name server. Instead it will only include the label for the zone it's trying to resolve.

For example, let's assume the DNS resolver is trying to find foo.bar.baz.example.com, and already knows that ns1.nic.example.com is authoritative for .example.com, but does not know a more specific authoritative name server.

1. It will send the query for just baz.example.com to ns1.nic.example.com which returns the authoritative name server for baz.example.com.
2. The resolver then sends a query for bar.baz.example.com to the nameserver for baz.example.com, and gets a response with the authoritative nameserver for bar.baz.example.com
3. Finally the resolver sends the query for foo.bar.baz.example.com to bar.baz.example.com's nameserver.
   In doing this the full queried name (foo.bar.baz.example.com) is not exposed to intermediate name servers (bar.baz.example.com, baz.example.com, example.com, or even the .com root nameservers)

Collectively DNS over HTTPs (DoH), Trusted Recursive Resolver (TRR), and QNAME Minimization are a step in the right direction, this does not fix DNS related data leaks entirely:

After you do the DNS lookup to find the IP address, you still need to connect to the web server at that address. To do this, you send an initial request. This request includes a server name indication, which says which site on the server you want to connect to. And this request is unencrypted.
That means that your ISP can still figure out which sites you’re visiting, because it’s right there in the server name indication. Plus, the routers that pass that initial request from your browser to the web server can see that info too.

So How do I enable it?
DoH and TRR can be enabled in Firefox 62 or newer by going to about:config:

• Set network.trr.mode to 2
  • Here's the possible network.trr.mode settings:
    • 0 - Off (default): Use standard native resolving only (don't use TRR at all)
    • 1 - Race: Native vs. TRR. Do them both in parallel and go with the one that returns a result first.
    • 2 - First: Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
    • 3 - Only: Only use TRR. Never use the native (after the initial setup).
    • 4 - Shadow: Runs the TRR resolves in parallel with the native for timing and measurements but uses only the native resolver results.
    • 5 - Off by choice: This is the same as 0 but marks it as done by choice and not done by default.
• Set network.trr.uri to your DoH Server:
  • Cloudflare’s is https://mozilla.cloudflare-dns.com/dns-query
    (but you can use any DoH compliant endpoint)
• The DNS Tab on about:networking will show which names were resolved using TRR via DoH.

Links:
A cartoon intro to DNS over HTTPS
Improving DNS Privacy in Firefox
DNS Query Name Minimization to Improve Privacy
TRR Preferences

I'm not affiliated with Mozilla or Firefox, I just thought ~ would find this interesting.

Hey guys -- I wrote a blog that I'd love some feedback on. I'm an identity product manager and have been trying to train my users to use passphrases. Do these read friendly enough? I want it to be readable by all users, but my target audience is other people in product and software.

https://medium.com/@toritxtornado/training-your-users-to-use-passphrases-2a42fd69e141