Website security is something we don’t usually think about until it’s too late. I recently discovered that links on several of my websites were redirecting to a different, malicious website. Here’s how I discovered the malware, what I’ve been doing since then to stay alert, and tips I’ve been learning in Launch School to keep my websites safe.
Routing out the malware
The very first thing I did when I discovered the malware was to change my account passwords. The next step was to contact my hosting service to see what steps they recommended. I followed their suggestions to run a malware scan on my computer and to restore backup files from a few weeks prior to my discovery. This briefly worked, but a few days later, I discovered that the redirects had come back. This alerted me to the fact that something was actively infiltrating my website’s code. Simply restoring older files would not fix the problem because it would keep coming back.
I then followed more suggestions, like installing and running a popular malware detection plugin (this did not work), removing unused themes and plugins, and making sure everything was up-to-date, including the site’s PHP version. This is when I noticed something odd: a plugin was present on my site that I could not delete. A brief internet search showed me that a few other people had the same issue. Some people suggested that the plugin was placed there by the hosting service, whereas others said it was a type of malware.
In this search, the people who said it was a type of malware shared that malware code usually contains the words “encrypt” and “64-bit”. I decided to do a string search for these characters and found some strings with these characters. These strings were super long. The string search showed me the location of these strings: in a file in the plugin folder.
I went to this folder in my file manager and discovered a weird file called DELETE_ME, as well as many files with a long string of random characters as a title. I deleted this entire plugin folder. When I went to my WordPress dashboard to see which plugin had been deleted, I saw that it was the plugin that I previously had not been able to delete.
Since then, I have actively pored over the files in my file manager, looking for new changes. I have also monitored my website using different devices and incognito sessions, which will allow me to see the site as it is currently instead of the cached version.
I am thankful that this happened on my personal website instead of a client’s website. I usually download a recommended, free security plugin, but I learned that this is not sufficient. I believe this malware got on to my site through an out-of-date plugin. I learned many things, including:
- Make sure WordPress, plugins, and themes are able to update automatically. If not, keep on top of the updates.
- Regular backups could also help prevent malware. You could compare a much older backup to the current one and see what changes have been made.
- For a client site with time-sensitive material like an online store, it pays to include purchased malware services in the proposal. Free malware plugins just don’t cut it. I really like Astra‘s malware cleanup services option.
Other security concerns
I’m in the middle of learning about the internet and how it works with Launch School. Their online HTTP book talks about some basic security concerns that all web developers need to be aware of.
- HTTPS is an essential for all websites. Most security issues can be solved by using HTTPS instead of HTTP. When we go to a website, we are sending a request to the server. The server then assigns us a unique identifier called a session ID that allows the server to “remember” us. Every time we interact with the website, our browser sends this ID to the server and the server keeps tabs on any changes to our session, for example if we add an item to a cart. With HTTP, this session ID is visible in the request. If someone is able to listen in to our request, they can easily see the session ID and will be able to pose as us without needing access to our password or username. HTTPS encrypts the request before sending it, so our ID is not visible to an attacker as we interact with a website. It is scary how many websites do not use HTTPS, especially since it is possible to get a basic certificate for free. It is not a good idea to interact with a website that does not use HTTPS, since it could infect your computer or steal your info.
- Prevent session hijacking. If an attacker gets access to a user’s session ID, it is possible to limit the amount of time they have to do damage by putting an expiration time on the session ID. This is why banks and other webpages with sensitive info will log you out if you haven’t been active. You can also have users sign in again before doing something sensitive like changing a password or making a purchase – this will generate a new session ID and will invalidate the attacker’s stolen session ID.
- Prevent XSS. A website that allows users to input text in a comment box should prevent cross-site scripting, or XSS. If the user is allowed to input text that is code, they could put a popup on the website or even change the website’s code on the server to make their attacks, such as be able to steal future users’ session IDs and pose as them. All comment boxes or spaces where a user can input text should be “sanitized” by not allowing HTML/Javascript in those spaces.