DAMN Redirects

Today on "Things my client and I learned", we find out the internet (via redirects), when it wants to, will 'eff up your sanity.

I've been on a bender with so many of my stories focusing on DNS, but it's the backbone of the internet so it can't help but get in the way. And although the issue here isn't a DNS issue (that I can identify,) I bring it up because the story starts with a change made to the DNS.

First, if you don't know anything about DNS other than it means "Domain Name System," know that DNS is damn hard and easy to mess up. Making changes to the DNS can be flat out terrifying. So after you make changes, if you find out something isn’t working (related to changes or not,) you immediately ask for help (or in my case a casual, "I noticed when I got to my site, it's not my site.") But you're not always able to explain what happened or why, all you can say is that things aren't working as they should. I will say, the client may have seemed nonchalant, but I certainly panicked for them.

Let me summarize the events that led to all this panicking.

• I had a client.
• Client sends B2B newsletters.
• Client gets LOTS of bot clicks.
• Client's ESP does not filter out bot clicks or provide ways to deep dive into the data to identify them.
• Client uses partner content (likely one reason there are lots of bot clicks) and uses it as a key strategy to keep the newsletter funded.
• Partners are unhappy that client is claiming their newsletter is driving traffic when it's not (based on ESP reporting that can't weed that junk out).
• Client is desperate for a solution.
• Client reaches out to others sending newsletters to see what they do.
• Client finds a redirect service. They will use that service to send clickers to their site and then redirect them from their site to their partner. This puts the control in their hands so they can filter out bot activities and send only "humans" to their partner sites. The bots they'll just drop.
• I provide advice around how this can look shady as $heets and could cause problems. I did suggest that they redirect those they don't want visiting the partner site to their site and not just drop them as they were planning on doing. This would at least let a real user who clicks, but looks like a bot (maybe VPN) to see their content or go to a site hosted by them where they can then point the visitor to their partner from there.
• I advise they should make sure they use unique subdomains for these redirects so the activity is as isolated as possible to email activity and the partner advertising.
• Client updates DNS for a subdomain to point to this redirect service and rolls out redirect/subdomain in email content.
• Check in with client, bots are under control. AWWWW YEA!
• Client says as an aside that when they go to their site, they go somewhere else.
• Sorry, what?????
• Visit site, but what is displayed is not their site.
• Ok that's odd. Looks mundane and odd

Image above pulled using urlscan.io.

• Do preliminary DNS lookup on another monitor and, suddenly, from the corner of my eye, I see the page changes...

Also pulled from urlscan.io. "It's a beaut, Clark!"

• WHAT THE <ENTER THE MOTHER OF ALL CURSE WORDS>? RED ALERT. PANIC! WEE WOO, WEE WOO, HELP, HELP, HELP!

So maybe the panic level that was induced was, maybe, perhaps, a little over-stated above, but the internet can be a SCARY place. And once you get that paranoia in ya, it's hard to let go.

Insert spoiler: Reddit discussed the second site/link above and outed it as a phishing site. I don't know if any of my client's visitors were lured in, but the quick identification and next steps certainly helped to reduce if not eliminate any impact.

Research time!

I did a quick DNS lookup checking the A record. It showed what we expected to see for the IP, BUT DNS lookups don't do much here because a lot of decisioning happens once you get to that server (especially if you use a service with shared IPs.) I asked the client if there were any DNS entries for redirects set in their DNS UI (perhaps there was a typo.) Nothing.

So commences Google searches and outreach to people to see what could lead to this site when the client didn't change anything relating to where their page is hosted or any backend code. 

The first "researcher" confirmed something be screwy, but the way everything was mapped, it made it hard to see what or where. We knew they were on Cloudflare and the page they were going to was hosted by Google so it didn't appear to be an internal routing issue on the Cloudflare side. 

As a suggestion, I was told to have them look at the .htaccess file (or it's equivalent), or at least have whoever codes their site review settings that controlled how the site operates. I don't believe they ever did this or knew how to, likely perhaps they didn't even know what an .htaccess file is. I had to Google it meself.

One.com shared the following about .htaccess files: 

"Configuration files are used to set up the initial settings of a program or server. The .htaccess file specifically configures how the server operates.

Each function is represented by a line of text or code that instructs the server on what to do. You can modify the server's behaviour by adding or changing the code within the .htaccess file.
You can, for example, use it to:

• Protect your site with a password.
• Create a custom-made error page.
• Redirect visitors to another page."

Another "researcher" identified that the redirects for http were working, but https wasn't. In my initial queries this didn't come up because I assumed (yes, never assume, but I'm guilty of it!) the redirect on the https would be the same. DAMN IT, ISKTBN! 

This gave even more detail around where the issue was happening.

Lemme show you what I'm talking about.

Using the Redirect Checker on whatsmydns.net, we typed in the client's site. To protect the identity of my client's site, I'll be using clientwebsite.io as a placeholder.

Here's the first query. By default, the results for http popped up.

Hitting (http://) clientwebsite.io redirected to http://www.clientwebsite.io, which redirected to the secure version using https. Cool, cool, cool (any Brooklyn Nine-Nine fans out there?).

As we can see from the redirect image above, "www" redirects to the proper landing page, but we check it anyway. Checking (or clicking) the final stop, just results in "200 OK". So far so good!

To get to the https results, I had to manually add in the https in the lookup request. 

Aside: There has almost been a user training that the https will automatically appear when you enter a URL into a browser. This is likely because some browsers force the https. And site owners often put in redirects to the https site and that little hop mostly goes unseen creating a feel for https as default for lookups in browsers. That same sentiment (that https will automatically be used) can traverse to other entries, but https isn't the default in this tool. The takeaway here is: Don't forget to check https.

Https with the "www" automatically works as we can see in the above two, but what other https is out there to check? https://clientwebsite.io!

📚 Bonus reading! If you are curious what the redirect codes are, check out Namecheap's article on redirects. One reason for using redirects in one way or another is for SEO reasons to maintain link ranking/equity.

If one decided to visit this site by entering in "http" manually instead of just the site, they'd be peachy. If one either added the "s" with their http because they wanna be all secure (or they let the browser do it because we don't really think about these things), they'd end up going to the WRONG site. Isn't that a bit ironic? You're taking the action to add in that "s" for the 'security' of protecting the data flow and you end up being less protected. And, yes, "s" doesn't guarantee anything about the site quality, but that doesn't mean an end user understands that or connects those dots. All they know (if they know) is that they should add it and/or look for it (and the lock icon.)

To this day, I don't know what caused the issue. It's not a new thing. Others have asked about this over 10 years ago on StackExchange. And a lot has changed about the internet since then so there are even more considerations.

And because I don't know what caused the issue, this still sits in the back of my mind as 'unresolved'. For all I know there is still some configuration issue sitting there unattended or if there was a compromise, it was never addressed and who knows what's was or is still being fiddled with. BUT, contrary to my lingering about resolution status, my client was able to "resolve" this...again, not confident this was the best solution, but it's what they moved forward with. And what was that solution, my dear reader?

They added in a redirect to point https://clientwebsite.io to https://www.clientwebsite.io using the redirect service they onboarded for click tracking.

DAMN Redirects. 🎶Thanks for the memories🎶 (a.k.a. panic attack)

And if you want to comment on all the ways you should protect your site and set your redirects and where, please do so!