There are a few different types of redirects. Some of which occur server side, others occur clients side and of course, things like DNS poisoning to cover the in between. In this article, we are covering client side redirects.
Let’s first talk about what tools you will need to troubleshoot a redirect. The first and usually most telling tool is the webpage source code. You can achieve this by preluding the url with ‘view-source:’, without the single quotes obviously. Client side redirects like a JavaScript injections and meta refresh tags will be rendered useless by this tool. The JavaScript and meta tags will simply be rendered and not executed. If the redirect still occurs with this enabled, the redirect is server side.
The browser console, which can be opened in most browsers with F12, some with “Crtl + Shift + I”, has quite a few useful tools when it comes to web development and design but what about that “Network” tab? What information can we gather about redirects using a tool we would normally use for measuring site load times? Each asset request made is logged on this tab, we can enable “Preserve Log” and allow the redirect to occur, now, we can cycle through these logs searching for the domain we were redirected to. When we locate the asset request associated with that domain, we will also now see the file which requested it. Useful for removing these annoying injections.
Adminer. I think the most important thing to know about this tool is it’s pronounced “admin er” not “ad miner”. Great, now that that is sorted, we can move on. This tool is used to manage a remote database without creating an SQL dump of the database. It also allows us to work without a database interface like phpmyadmin which we need access to the hosting account access for.
Cool, let’s get to what we came here for. To get more granular from an user perspective, server side redirects, cause by a hacked .htaccess file, or 301 redirects setup in cPanel for instance, are usually instantaneous. The browser address bar will change to the new URL and the browser console will only have very few events in the network tab. Client side redirects are usually not the first to load and several other assets from the site will load and display in the network tab before the redirect takes place.
When dealing with JavaScript injections, we find these in many forms. Some as simple as a <script> tag injected into the header.php others as complex as a filter added to the functions.php which calls an escaped serialized string, which when unescaped and deserialized is a simple <script> tag containing a redirect. Knowing where to look can take some patience but is not impossible. If you have determined the redirect is client side, let’s look at how we can locate them in the files. Generally, when viewing the page source, the redirect is shown, unmodified in plain text. We can usually grep for this in the files. If no results return, we can then start searching the database. Keep in mind, when strings are stored in the database, they are likely to be escaped. So searching a SQL dump for http://crazy_redirect.com/ would return no results unless we search for the escaped version, http:\/\/crazy\_redirect.com\/ for example. I personally usually lean toward searching for only the domain and excluding the protocol. If you are brave enough to tackle searching an SQL dump, here is all the characters you should expect to have to escape.
Escape Sequence | Character Represented by Sequence |
\0 | An ASCII NUL (X’00’) character |
\’ | A single quote (‘) character |
\” | A double quote (“) character |
\b | A backspace character |
\n | A newline (linefeed) character |
\r | A carriage return character |
\t | A tab character |
\Z | ASCII 26 (Control+Z); see note following the table |
\\ | A backslash (\) character |
\% | A % character; see note following the table |
\_ | A _ character; see note following the table |
If you determine the redirect to be server side, these are usually quite easy to correct. Renaming all .htaccess files is a good start as well as logging into the control panel and verifying there are no 301 redirects present. Looking deeper into this requires a whole other article.
Until next time. Stay Frosty Friends.