I'm pleased to say I've moved my domainsync service over to React, and at the same time moved the domain to badsec.io. Since these changes I've found it's much easier to compose complex services into simple components that simplifies code extension, modification and testing. The original back-end code is still JavaScript/ NodeJS, so check the services out and let me know your thoughts!

Along with domainsync I've created an SQL injection component that allows users to analyse a URL for SQL injection vulnerabilities. The true value here is that all the difficult set up and usage configuration is abstracted away. Intricate features like database extraction, table & column traversal and data dumping have been simplified through the UI. All you need is a few mouse clicks and you can demonstrate the perils of injection without complex pipelining.

Oh, and it's got dark mode.

Use Cases for Domain Analysis

My domain analysis tool now comprises three key utilities:

1. Certificate Transparency
2. Cookie Analysis
3. Domain Name Permutations

In this section I will demonstrate how each of these utilities work and go through a use case for each one.

Certificate Transparency

I've covered Certificate Transparency (CT) extensively in a previous blog post, so you may want to give that a read if the concept is new to you. One of the key benefits of understanding what Certificate Authorities (CA's) have issued a certificate for a domain is that, in some cases, it provides a birds-eye view of your domains' internet footprint.

Let's see an example.

Bug hunters love using CT logs because it allows them to understand what new services and subdomains have been created by that entity. You too, can leverage this information on your own domains.

Cookie Analysis

Cookies seem to be quite the hot topic as of late. Particularly so given major browsers are now starting to enforce blocking of third-party cookies in an effort to stamp out privacy invading trackers and others.

Apple have already released Intelligent Tracking Protection (ITP) into their Safari browser that blocks third-party cookies by default. Firefox, as of September 2019 are now blocking third-party cookies by default. It's said that in early 2020 Chrome will start blocking third-party cookies that do not specify the SameSite attribute.

To that end, if you want to understand what type of cookies and their attributes are being set for a given domain, now you can :-). Simply run the Cookie Analysis module and click-through to the associated table.

Domain Name Permutation

Perhaps my favourite component of the domain analysis suite is DNS permutation. The reason behind this is typically there's a pipeline of independent functions required to understand the context of a domain name.

It goes something like this:

performDNSMutation(domainName) 
	-> filter(CNAMEorARecord) 
	-> extract(recordValue) 
	-> groupBy(recordType) 
	-> view(recordValue)

That's quite a lengthy process just to understand whether someone has parked on a permutation of your domain, or whether a top-level-domain (TLD) variant of yours has been registered by somebody else. Imagine doing that for every single record?

I've built in a few additional features into this module to help streamline the process. Namely:

• DNS permutations - DNSTwist variant
• Default filtering for valid records
• Grouping by fuzzer (e.g., TLD's)
• Screenshot capabilities

Let's see an example.

All the screenshot operations are asynchronous. So getting a quick visual on a webpage is as easy as clicking the corresponding arrow next to the domain name. Easy, huh!

Have a look through some common domains and see if you can spot the bit-squatters and potential phishing sites. These are an easy give away. If the company is sufficiently large enough, typically you'll see an A record pattern where TLD's all seem to point to a similar location. It's the domains that don't adhere to that pattern which might be worth taking another look at.

A Use Case for Visualising SQLi

SQL injection is still #1 ranked on the OWASP Top 10, and in my experience most developers and IT generalists are aware of it, but few have seen it in action. I wanted to change that.

As part of your security awareness engagements you can now demonstrate injection attacks simply by browsing through the SQL component - and - no tools required! The component supports additional optimisation flags, session cookies and HTTP GET & POST methods.

Let's take a look at an example.

As you might've noticed there's only a handful of domains that are selectable for analysis.

This service is for educational purposes only. All the domains listed are testbed like sites where you are free to practice your SQLi-fu. Please only test domains for which you have explicit permission.

If you want to test this out on your own infrastructure I highly suggest you take a local copy of my tool which is freely available on Github. The only caveat here is that it's the jQuery version.

Final thoughts

Building security tools that are simple to use has been a passion of mine since way back! One way to do that is designing with user-centricity in mind. Don't get me wrong I'm a big fan of the cli (in fact I'm writing this blog post from one right now), though I believe that we'll do much better in terms of user engagement by developing interfaces that users are familiar with, especially so when highlighting risk is important. That was my goal here with badsec and I hope you'll enjoy these tools as much as I did when creating them! As always, I'd love to hear your thoughts and ideas for future developments.