Is php site protection sufficient?

Question

PHP

I recently started learning php and, despite the fact that the Internet is full of information, the question of implementing a reliable user authorization system remains open to me. Next, I will try to show how I see the situation and give my (or not my) reasoning on what I could find.

Here, let's say I wanted to make a site that hosts a "standard" authorization form using php, which looks something like this
: - if everything is OK, then the login + the generated and saved access code is written to the cookies.

• By default, in the settings, access to the database is only from localhost
  
• SSL is used
  

What protection measures have I found and want to use

• The username and password are hashed. This seems like a safe way to store data, especially if the pure database leaks. But this does not protect against MiitM, since the hashing happens on the server side. It makes little sense to implement hashing on the client side, because then the hash becomes a password and "reading" the data between the client and the server, by and large, is still a hash or a password in its pure form. (well, or you can use hashing on both sides).
  
• php with sql injection protection (although this can also be written in .htaccess)
  
• Everything from php authorization is protected from direct access via .htaccess. In fact, this is a very useful file in which you can write a lot.
  

Of course, if the database contains nothing but an id, a hashed login and password, and the site does not provide for administration, then in this case the security described above can be neglected altogether .
But, firstly, I still have not come across a site where authorization would be implemented in pure php (why are they not there, if everything is so "easy"?, or am I just not attentive?). Secondly, I really want to upgrade my knowledge and skills in this topic (therefore, I will be grateful if you write in the comments in which direction to dig in terms of security), and thirdly, security requirements are constantly becoming more complicated, so if I think about making a serious project, such knowledge is very useful.

Actually the question is, how justified is it to apply all this in this form, what important points have I missed and what else should I look for on this topic?

Answer 1

Security is a complex thing and much depends on the specific implementation. The fact that in one place is closed (and that is not a fact, since the implementation is not known) one vector has little effect on overall security.
For example, you may have a super secure site, but next to you in the next folder you have an application that takes a command from user input and puts it in exec (). Or the web server is configured in such a way that, upon separate requests to other virtual hosts, it returns the contents of the config files. Or the nuances of cutting corners during development (we will add more thorough field filtering later. aha). Or suddenly it turned out that there is a fundamental vulnerability in the version of your PL, a specific library or subd.
Want to take a holistic approach? Dig towards the study of materials from OWASP. For example,https://owasp.org/www-project-web-security-testing... There are quite a lot of materials for checklists. Or see ready-made checklists of what to check. For example, https://github.com/0xRadi/OWASP-Web-Checklist (I'm not saying this is the best checklist, but look at the number of points for a quick estimate).
Want to get even more complex? Start with a book for beginners on finding vulnerabilities - The Bug Trap. Field Guide to Web Hacking | Jaworsky Peter https://www.piter.com/product_by_id/196618476
And then, for example, pay attention to a more complex book on how to build protection in applications
Safely by design | Berg Johnson D, Deogan D, Savano D. https://www.piter.com/product/bezopasno-by-design
There, the idea is already more thoroughly brought up how to build protection based on architecture.

Answer 2

Main page - Page with authorization form - php authorization
Everything from php authorization is protected from direct access via .htaccess.

Google "php routing|routing".
And to become attached to a specific Apache now is not worth it.

sql injection protection file - MySQL database connection file

If you want pure PHP, PDO and prepared queries cover both.
In general, you should take an interest in PSR and frameworks - they, suddenly, do not gather crutches and shit code, but the very best practices that you don’t know where to read. Did you come across Phptherightway at all?

Login and password are hashed

Fucking login? So that at the next registration you don’t know if this one is used or not?

Answer 3

What is a "sql injection protected file"? It sounds like "I will never get AIDS, because when I have sex, in the next room I have a special bedside table with a bunch of condoms." The condom must be used in the process, and not kept in a separate bedside table. Only then will he help.
"although this can also be written in .htaccess" - this is some kind of idiocy, and obviously harmful
"Everything, starting with php authorization, is protected from direct access" - this is also, although simply useless
".htaccess. In fact, this is very useful file" - the usefulness of the .htaccess file is greatly exaggerated. It is rather a crutch for cripples who do not know how to set up the system correctly. Not even speaking about,
In general, from what is described, in addition to a few senseless gestures, I see problems here on three points
1. Some kind of strange "injection protection", which most likely does not protect against anything, but only corrupts the data
2. Big question, how exactly the access code is "generated".
3. No XSS protection mentioned at all. Well, CSRF, for that matter
. Plus, there are likely holes in a specific implementation, when it seems to be correct in words, but it is implemented crookedly in the code. of type location to protect pages from being accessed. Well, in general, you need to see the code. Maybe some ingenious incude $_GET['page'];

Answer 4

the question is general, and not only for php
1. It is not necessary to hash the login, and the main thing is to hash correctly, PBKDF2, Argon2, etc.
2 SSL just to protect against MiitM
3 .htaccess does not protect against sql injections
well, authorization and authentication are different things

firstly, I still have not come across a site where authorization would be implemented in pure php

how did you determine it?
PS and most importantly, use ready-made solutions, not your bikes

Answer 5

As many have already written, you should not now write something yourself that has long been implemented according to best practices. At a minimum, you should use PDO or ORM.
Better yet, use all this together with some popular framework like Laravel. Everything is already implemented there: from authentication and authorization to requests to third-party APIs.
If you want to write something of your own without frameworks, then nothing specific can be advised on security. There are certain rules that most developers adhere to.
- use SSL on the site
- the password in the database must be stored in a hashed form.
etc.
The most common threats are described in OWASP TOP 10. Read at your leisure.
Hashing the password on the client is also correct. The task of the service is not only to deny access to the service to intruders, but also to keep the client's password secret. By passing the password to the server in clear text, even if over a secure connection, you can give it to attackers. At a minimum, requests can be logged, and the password in plaintext will be stored in the logs. An attacker can somehow gain access to the server and steal the passwords of thousands or millions of users. Or, embed a specific code in the PHP script that will transfer passwords to a remote server (if you have access to the backend server).
Yes, you can stick out only the balancer or frontend, and keep the backends without access to the external network. But what if the attacker is a developer/employee who can pull data from this server?
Hashing the password on the client is good practice. Facebook is doing something similar. In this case, neither the service owner nor the attacker will be able to access the user's public password. This will protect other user accounts (if he uses the same password or the main part of the password in other services).