Checking PHP engine for durability
Hello everyone, I recently wondered to write a PHP engine for my needs, so to speak, to increase the level and get something useful. Almost immediately I wondered how easy it would be to hack it? It's not a secret that anything can be hacked, but the question is, how problematic will it be and can every hacker be able to do it?
Perhaps the most frequent vulnerability in any project, be it a comment form, or a login form. Without good checks, this thing is worth nothing.
One common mistake is to save everything you got:
Anyone can add his own item to the same debugger, even if it doesn’t do much hacking, but the thing is extremely unpleasant.
I came to this conclusion:
I think the first is the most reliable, but if there is nowhere without them, then there are several recommendations.
Once I had a project and I needed to do something with the form of uploading photos, when I looked at the code, there were no file checks at all, even file type checks, it's just that it comes and records. My first thought was: "What the x?". Having rummaged a little more, I realized that this form is processed by the JS script. Fortunately, it was the admin and not everyone could get there.
So, the conclusion. So you can not do!
There are two reasons.
Pay more attention to checking files, size, type, if this is a picture, then width, height. Often, when displaying a picture, they make a check, only on one side, in width or height, and now imagine that some clever person filled the picture with 20000x50px or vice versa, the spectacle will not be pleasant.
Although this is a handy thing that will save you from yawning in your mail or records and searching for a password, but see what you can do if this computer falls into the hands of your "friend."
He can at least two ways to open the settings and see the saved passwords there, the second through the debugger to change the field type from password to text.
')
For those who are in the tank - this is the introduction of the SQL code of a simple user, through the address bar or through the same forms.
There is one rule:
If you constantly remember it, you can save yourself from many problems in the future.
Check what the user sent you, if in the password field he specifies “lol 'OR (1 = 1) #”, this will not affect you in any way.
The easiest way to get rid of this is to use mysql_real_escape_string, this function escapes all special characters in SQL, and also removes all slashes using the stripcslashes function.
On many sites, to get into the admin panel, just enter the address / [admin | admin.php | administrator | etc]. There are not so many options, so you can find the right one, but if you use the admin panel with the generated characters, you may not worry (example: 7NVmE10SaJ.php), for some it may seem paranoid, but I think there is never much security. if a user gets to the login page of the administrator and password, it brings him a step closer to uncovering all the secrets of the back-end part of the site.
In order to avoid the loss of any accounts, do not let users create passwords themselves, but if they do, try to make it make the password as difficult as possible. Recently, I started using this link to create a password md5 ($ secret_key. $ Password. $ Salt);
In my opinion this is a good defense. The md5 hash is built from the secret key, which is sewn into the engine config (located somewhere in the code), from the user password and salt, which is stored in the database, next to the user password md5 hash, and each user has his own salt. What does this give us? If someone steals a database from us, without a secret key, he will not receive a password, even if he receives both the base and the engine, then he will not get any sense from this without a password either, just use terabyte rainbow tables.
It's all the same as with the admin panel, you can't give the opportunity to get into phpmyadmin by typing just the address / [phpmyadmin | myadmin | pma | and so on]. Well, it is natural to use the logins root | 123 is also prohibited.
The most frequent use of sessions is to support user authorization, but storing sessions is also a huge topic. The first thing to remember is not to keep the session ID in the clear, or even better, store it in the database, and do not let several users sit under one session, check everything, ip, user_agent, so that an intruder cannot steal anything. I also advise you to look in the direction of anti-spoofing, so that the hacker could not fake ip.
Cookies are needed for data storage by the browser, often many people store id sessions in cookies, which I do not recommend, especially in the open form. If you store something in cookies, then encrypt, and even more check, because here, as with the forms, you can not trust what came, because changing is not a problem either. By the way, the salt that was used for the user's password can help you here again.
It is necessary to think out the architecture of your project correctly, if you do the whole project with crutches and bicycles, it will not lead to anything good, only to holes. Try to use MVC, it will help to delimit your code, into logical components.
It's clear that this should be Linux. I don’t know about security, but if a person’s hands grow from where it is necessary, then you can configure any server.
From the words of the people it is clear that Vindos can be customized, so the decision is yours.
If someone offended with winds, sorry, but I did not have to work with him, the opinion was expressed based on the feedback from friends.
You can also write about traffic analysis, but I didn’t do it, so I can’t know for sure, there are experts for that.
From the above, the following conclusions can be made:
All these tips will not save you from the threat of hacking, but will help to complicate it very much, so now not every hacker can crack it. Just remember that data validation via javascript is only half the story, as you can safely turn it off, double check all data, because of all your code, only 10% is output or work with information, everything else is validation and data validation .
Ps. About Vindos, I said that I did not know for sure. Just everything that I read about her speak badly, so sorry if offended anyone.
These tips are for beginners, there is no point in telling them about any PDO and ORM.
I know that this information is known to many, but I did not find an article where at least so much information will be presented.
I was not going to surprise anyone, I wanted people who did not understand much about it.
Forms
Perhaps the most frequent vulnerability in any project, be it a comment form, or a login form. Without good checks, this thing is worth nothing.
One common mistake is to save everything you got:
foreach( $_POST as $item ){} Anyone can add his own item to the same debugger, even if it doesn’t do much hacking, but the thing is extremely unpleasant.
File Upload Forms
I came to this conclusion:
You can protect your engine only if you do not have a single form for downloading files, or they are and are checked well enough
I think the first is the most reliable, but if there is nowhere without them, then there are several recommendations.
- One check is never enough!
- Learn about the content of all.
Once I had a project and I needed to do something with the form of uploading photos, when I looked at the code, there were no file checks at all, even file type checks, it's just that it comes and records. My first thought was: "What the x?". Having rummaged a little more, I realized that this form is processed by the JS script. Fortunately, it was the admin and not everyone could get there.
So, the conclusion. So you can not do!
There are two reasons.
- The user can be disabled JS
- User can change JS in debugger
Pay more attention to checking files, size, type, if this is a picture, then width, height. Often, when displaying a picture, they make a check, only on one side, in width or height, and now imagine that some clever person filled the picture with 20000x50px or vice versa, the spectacle will not be pleasant.
Password storage
Although this is a handy thing that will save you from yawning in your mail or records and searching for a password, but see what you can do if this computer falls into the hands of your "friend."
He can at least two ways to open the settings and see the saved passwords there, the second through the debugger to change the field type from password to text.
')
SQL Injection (SQL Injection)
For those who are in the tank - this is the introduction of the SQL code of a simple user, through the address bar or through the same forms.
There is one rule:
" Never trust what the user sent you. "
If you constantly remember it, you can save yourself from many problems in the future.
Check what the user sent you, if in the password field he specifies “lol 'OR (1 = 1) #”, this will not affect you in any way.
The easiest way to get rid of this is to use mysql_real_escape_string, this function escapes all special characters in SQL, and also removes all slashes using the stripcslashes function.
Admin panel
On many sites, to get into the admin panel, just enter the address / [admin | admin.php | administrator | etc]. There are not so many options, so you can find the right one, but if you use the admin panel with the generated characters, you may not worry (example: 7NVmE10SaJ.php), for some it may seem paranoid, but I think there is never much security. if a user gets to the login page of the administrator and password, it brings him a step closer to uncovering all the secrets of the back-end part of the site.
Passwords
In order to avoid the loss of any accounts, do not let users create passwords themselves, but if they do, try to make it make the password as difficult as possible. Recently, I started using this link to create a password md5 ($ secret_key. $ Password. $ Salt);
In my opinion this is a good defense. The md5 hash is built from the secret key, which is sewn into the engine config (located somewhere in the code), from the user password and salt, which is stored in the database, next to the user password md5 hash, and each user has his own salt. What does this give us? If someone steals a database from us, without a secret key, he will not receive a password, even if he receives both the base and the engine, then he will not get any sense from this without a password either, just use terabyte rainbow tables.
phpmyadmin
It's all the same as with the admin panel, you can't give the opportunity to get into phpmyadmin by typing just the address / [phpmyadmin | myadmin | pma | and so on]. Well, it is natural to use the logins root | 123 is also prohibited.
Sessions
The most frequent use of sessions is to support user authorization, but storing sessions is also a huge topic. The first thing to remember is not to keep the session ID in the clear, or even better, store it in the database, and do not let several users sit under one session, check everything, ip, user_agent, so that an intruder cannot steal anything. I also advise you to look in the direction of anti-spoofing, so that the hacker could not fake ip.
Cookies
Cookies are needed for data storage by the browser, often many people store id sessions in cookies, which I do not recommend, especially in the open form. If you store something in cookies, then encrypt, and even more check, because here, as with the forms, you can not trust what came, because changing is not a problem either. By the way, the salt that was used for the user's password can help you here again.
Architecture
It is necessary to think out the architecture of your project correctly, if you do the whole project with crutches and bicycles, it will not lead to anything good, only to holes. Try to use MVC, it will help to delimit your code, into logical components.
Operating Systems
It's clear that this should be Linux. I don’t know about security, but if a person’s hands grow from where it is necessary, then you can configure any server.
From the words of the people it is clear that Vindos can be customized, so the decision is yours.
If someone offended with winds, sorry, but I did not have to work with him, the opinion was expressed based on the feedback from friends.
You can also write about traffic analysis, but I didn’t do it, so I can’t know for sure, there are experts for that.
Conclusion
From the above, the following conclusions can be made:
- Information sent by the user is considered unreliable by default.
- Handle any incoming information
- Strong passwords
- Literate architecture
- Monitor the names of potentially vulnerable files.
- Do not use other people's scripts, if you use something, check it several times. The API does not include this number, but use them at your own risk.
- Sessions, cookies and SQL queries. Watch them!
- OS selection
- Incoming traffic
All these tips will not save you from the threat of hacking, but will help to complicate it very much, so now not every hacker can crack it. Just remember that data validation via javascript is only half the story, as you can safely turn it off, double check all data, because of all your code, only 10% is output or work with information, everything else is validation and data validation .
Ps. About Vindos, I said that I did not know for sure. Just everything that I read about her speak badly, so sorry if offended anyone.
These tips are for beginners, there is no point in telling them about any PDO and ORM.
I know that this information is known to many, but I did not find an article where at least so much information will be presented.
I was not going to surprise anyone, I wanted people who did not understand much about it.
Source: https://habr.com/ru/post/173701/
All Articles