One can argue for a long time why some people like to spoil and break the fruits of the labors of other people so much, but one way or another this is a fact that is also relevant for the virtual world. Even at the dawn of the birth of home PCs, i.e. when everyone began to get access to them, this plague began. The first virus was written, a website was hacked for the first time … nowadays, this is no longer surprising. Many are already used to seeing inscriptions like “I was a super-duper hacker here” and other manifestations of computer vandalism from time to time.
Most of these attacks occur as a result of exploiting holes in server scripts. It is about covering these very loopholes for hackers that will be discussed in this article.
So, as mentioned, a hacker can access a website through server scripts (of course, there are many other possibilities, for example, steal a password – by a Trojan, a sniffer, or even brazenly, from a user’s computer, but this is a separate topic). Why server rooms? Yes, because with the client – those that are executed on the machine of the site visitor, he will not do anything. They do not have any access rights to the server, except that they can receive information from it and only, but in no case, client scripts will not be able to independently change something on the server.
The most common server technology today is PHP. I think, since you are reading this article, you should not dwell again on what it is, especially since there have already been many good articles on this topic. Well, let’s get over it.
First of all, I want to say that the examples presented here do not guarantee 100% that no one will hack you, this is simply impossible. There are always bottlenecks, even in the most widespread and perfect systems, an example of this is a sensation six months ago, when a gross error called SQL Injection was found in queries in the universally recognized SQL language (Structured Query Language) on sites around the world … But at the same time, you will see the most frequent fatal mistakes in protection and will be able to protect yourself at the proper level from the attack of not only an amateur, but also a professional hacker.
To begin with, you only need to remember one thing – never trust the data received from the visitor – after all, they can be a malicious script, which, by the way, can be both server-side and client-side (it will work on the machines of visitors). And this is quite enough, of course, if critical errors are not allowed in the scripts themselves and the server itself is properly configured, but first things first.
The first example that comes to mind is that you’ve decided to write a guestbook. So you need a field to enter a name, email address and the message itself. PHP script takes data from the form and saves it to a special file for later display when reading the guestbook. It seems that there is nothing dangerous, but the hacker does not think so, in the absence of appropriate security measures, he can use this form for his own purposes. Well, we won’t give him a chance.
For starters, it would be a good idea to limit the length of the name and email address. This is not only one of the many methods of partial protection, but also protection from pranksters who think that a name several hundred characters long is very funny. So let’s write in the input field, say, maxlength = 25, for example:
<input type=text name=user_email maxlength=25>
In this way, no one can enter more than 25 characters in this field. However, this will only stop virtual vandals-newbies because in the address bar you can easily write something like:
As you can see, after clicking the Ok button, the data, before being passed to the guest.php script, is checked by the checK function, if the entered address is empty or contains prohibited characters, the user will receive a message: “Specify an email address.” or “Invalid email address. \ n Please try again.” accordingly (\ n – line break), note that the messages will be in the window: alert () and no page reload will even happen: return false, and the cursor will highlight the erroneous input: f.email.focus (); or f.email.select () which is very convenient for the user, especially if there is more than one input field on the page.
Let”s continue to look at the authorization and session tracking issues. But before we consider this topic, let”s stop for a moment at a very important point – the protection of information about the structure of files and folders on the server.
On the same day as the first article of this series was published, I received the first letter. The reader, who asked to remain incognito, thanked for the article and asked to check in practice how he protected his creation. Everything was fine until I touched on something that was not mentioned in the article. It was not mentioned primarily due to the fact that it actually has nothing to do with PHP. However, non-observance of some elementary rules can nullify all efforts to protect the site from hacking through PHP scripts.
So what did I find there? Basically, nothing special, except that in some, including “secret” directories, there were no index.html files (or other index. * Interpreted as starting ones). In addition, there were no corresponding access rights settings. What follows from this? When such an address is typed into a directory without an index. * File in the address bar, an attacker will open the entire contents of the folder right in the browser with all possible consequences (this depends on what is stored there).
How to prevent this? Enough in each folder on the server, if there is no index. * File, put it there. In the file itself you can write whatever you want – from “No entry” or an empty file to redirection, for example, to the start page of the site. The second option is preferable, again, with a careful look of the webmaster towards conscientious visitors. If someone has forgotten, let me remind you how to carry out a reader: