If you really consider "security" this library already has problems by itself and others that can be created by you.
Password without null filter (0x00)
Using $hashPasswd = password_hash($password, PASSWORD_DEFAULT);
assuming $password
is a password entered by the user, as used here , is a problem.
PHP has big problems with null bytes, it has always had problems with this and apparently always will have. Not today. PHP was already vulnerable to nulls in include()
which allowed removing the file extension.
In the case of password_hash()
if the user enters the password 123%004567
, in fact that is equal to 123
, the string will be interrupted in 0x00
.
If you want proof of this:
var_dump(password_verify('a', password_hash(pack('H*', '6100626364'), PASSWORD_DEFAULT)));
// Resposta: True
There is no CSRF protection
I'll give the example logout page . I can simply make a <img src="https://seusite.com/logout.php">
onmywebsiteandwhentheuseraccessititwilldisconnectfromyourwebsite.
AsimplewaytosolvethisistocreateaCSRF-Token,auniqueandprintablecode(fortheattacker)andcompareitsecurely.
Inotherwords:
if(!hash_equals($_SESSION['CSRF'],$_GET['CSRF-Token'])){echo'Tokenerrado';}
The$_SESSION['CSRF']
wouldbegeneratedusing$_SESSION['CSRF']=unpack('H*',random_bytes(64)[1]);
,sotheclientshouldsendthiscodesothatitcouldlogout.
Thesameappliestoallotherwebsiteoperations.Youcanalsocodeforeachactivityassoonastheuseraccessesthewebsite,aswellasyoucanderivethespecifickeyforeachpageaccessed.
Theremaybeothererrors.Anexampleistheabsenceoffilters(theemailcanbeanyarbitrarystring,whichisnotanemail)andthereisnoconfirmationiftheemailistrue,forexample.
Inaddition,thesessionisstatic(doesnotusesession_regenerate_id
).TheBCryptdifficultyisthedefault(10,Ifinditparticularlylow)anddoesnotusepassword_needs_rehash
thatcouldbeusedtoincreasethedifficultyofoldpasswords(whentheuserwasaccessing).
Thencomesyourquestion:
WhatdoIneedtotakeintoaccountifmyloginandsessionaresecure?
Severalthings,butIwillmentionwhatIconsidermostimportant:
Preventamaliciousscriptfromreadingsessioncookies,thePHPsessionusesanidentificationcookie(PHPSESSID)ifsomeonehasaccesstoit,youwillhaveaccesstotheconnectedaccount.
Preventanattackerfromsettingthecookiethatthevictimwilluse.Similartowhathappensin"1", but now instead of the attacker reading the cookie it makes the victim use the cookie of their choice.
Prevent someone who intercepts packets from being able to view the information. Specifically you must do something so that you can not get the session identifiers. Just as in the worst case prevent the user from connecting to a fake website.
Preventing an external website from abusing the cookies already started by you, an external website should be unable to use an open session, if not exposed to a CSRF, mentioned in the example above.
The session identifier (the cookie, the PHPSESSID) must be printable and strong enough to prevent anyone from entering other accounts.
Of course, prevent the attacker from entering the server and accessing the folder where the sessions are stored. In general, I think I've commented on these problems here .
Of course, it's important to validate, sanitize data, but ... and what can I do to make the system safer?
I think I answered above. There are N things that can make the system unsafe or secure, many of which may not even be in the code itself, but in the environment around it.