Disclosure: Privacy Australia is community-supported. We may earn a commission when you buy a VPN through one of our links. Learn more.

By Will Ellis

• 
• 
• 

Last Updated on August 27, 2021

Website security is something that a lot of people don’t unfortunately really think about as an ongoing issue. This is especially the case if they’re using a big name to build their website, such as WordPress, and assume that it will do all the work for them. Unfortunately, that’s not the case and it’s just going to lead to heartbreak down the road.

So, to that end, we wanted to list some of the most common PHP vulnerabilities that bots on the internet go trawling for. That’s right, bots, because the good old days of humans and their slowness has long passed.

SQL Injection

Probably one of the most common and well-known PHP vulnerabilities is SQLi, and it’s a big problem.

Essentially how this works is by somebody inserting an SQL argument, such as a database statement, as a value in a form, or even possibly your URL. The PHP application may then consider it as valid code and run it, leaving you open to some potentially major problems. This can even include giving almost complete access to your whole website.

The best way to avoid this vulnerability or bug is to always check values entered into any field using prepared statements. This allows the data to be treated only as data, rather than potentially being run as code.

Remote File Inclusion

This one is relatively simple but can sometimes be overlooked. If you include a remote file in your application, you essentially tie yourself to their security practices. So if somebody compromises said remote file on their site, and then that file updates on yours, you’ve basically just gotten compromised. It’s essentially like sharing the same electric toothbrush without changing the head.

To avoid this, go into your php.ini and change ‘allow_url_fopen’ from on, which is the default, to off.

Cross-Site Scripting(XSS)

XSS is when some malicious code is allowed to load and run on a user’s browser, which as you can tell, probably isn’t great. Generally speaking, there are two types of XSS vulnerabilities: Reflected XSS and Stored XSS.

Reflect XSS is when a link with malicious code is created, and when it loads into a browser, the website itself servers up the code as part of the website’s content. One example is a search query without a sanitized URL that can then lead to some nefarious code being executed and everybody having a bad time.

Stored XSS on the other hand is when an attacker manages to store malicious code in the website itself which is then served to the user’s browser. For example, putting malicious code in a comment to a video or post, which then runs on another user’s browser when the page is served to them.

Directory Traversal

Otherwise known as the ../ attack (yep, literally pronounced dot, dot, slash). This is a simple look for a website with insecure directories where an attacker can potentially gain access to any page on the site.

To protect against it, just define what sort of pages can be returned depending on the request, which you can do with whitelisting.

Cross-Site Request Forgery(CSRF)

This attack plays on the sensibilities (or lack thereof) of an admin for the website. It essentially gets an admin for a website to click on a link which then runs malicious code using that privileged access. In most circumstances, and what makes it a CSRF is that the code would create a new admin user and password specifically for the malicious attacker.

An interesting way to protect against this, and the way that WordPress uses it, is something called ‘nonce’. This is basically a security token that is provided to an admin whenever they log in or take administrative action. So if a potential hacker wanted access, they would have to know the token as well, which in WordPress’ case, is changed every day.

Unfortunately, as with WordPress, some plugins don’t use this nonce authentication, which can introduce vulnerabilities to the site unexpectedly. The best bet is to make sure any plugins you use have this nonce system from WordPress, and if they don’t, just don’t use it.

Authentication Bypass

This vulnerability arises from a simple misunderstanding on the website coder’s part.

Sometimes a PHP developer will think they are checking the authentication of a privileged user when in fact they aren’t. The confusion arises from the name of the function ‘is_admin()’ which does not check if the user is an administrator. Instead, it checks if an admin page is being viewed or not.

The best way to not run into this issue is to always make sure the role that the user has before allowing access. That way you can avoid authentication bypass and make sure that the user has the right to view the page they are viewing.

Session Hijacking

As the name suggests, this is a vulnerability that involves hijacking the session of a user, usually an administrator.

Whenever a session is created between the server and a client, a session ID is created and stored in a cookie. As the ID is sent with the page request, gaining access to that session ID can give you session info. This can be particularly problematic if you’re an admin and your session key is stolen because then the attacker can take essentially any action they like.

So how to stop it? Well, for starters these IDs are usually stolen by an XSS attack, so protecting from those is a good start. You should also change the session ID as often as pragmatically possibly using ‘session_regenerate_id()’ (otherwise people get irritated if you do it too often). Finally, if you’re sharing hosting, make sure session ID isn’t being stored in globally accessibly folders like /tmp, that’s not great.