Regarding Composer, your view is understandable. I can understand the need to have a stand-in solution until a solution is implemented.
For you use case the stated use case that makes sense.
Per support of 5.5, if we (class / package providers) do not provide motivation to our users to upgrade; who will? Project Managers? Sales? Marketing? IMO, the role of technologist evangelist is squarely in the realm of the owner of the logic.
Not validating user input opens a large risk to RCE (remote code execution). Passing logic to the server via the form field. When the interpreter process the value the value is code, so the interpreter executes it. A basic step would be to us PHP's filter input function (php.net/manual/en/function.filter-...) as a start.
I am aware of RCE. Most these types of attack relies in exec() or eval(). RCE could be done in case of buffer overflow, however this type of exploitation take advantage of bugs in functions that manipulate strings, like crypt() or serialize(). It's valid to mention that this script doesn't perform any string manipulation except hashing the user input password.
So, about the security issues, If an old version of PHP (like 5.5) is used, it's security problems could be exploited to do a buffer overflow attack, or some kind of session attack.
Well, your insights really helped me. If I want to support 5.5, I should minimize the possible attacks that could be made. I will Now the script validates the username and password to only accept ASCII printable characters.
I want to state that I am relying totally in the PHP's capacity to protect his own session data, so any ideas to improve this script, without forgetting it's main goal, are welcome.
Thanks David.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Regarding Composer, your view is understandable. I can understand the need to have a stand-in solution until a solution is implemented.
For you use case the stated use case that makes sense.
Per support of 5.5, if we (class / package providers) do not provide motivation to our users to upgrade; who will? Project Managers? Sales? Marketing? IMO, the role of technologist evangelist is squarely in the realm of the owner of the logic.
Also, stats say what you want them to. seld.be/notes/php-versions-stats-2... (PHP 5 < 22%).
Not validating user input opens a large risk to RCE (remote code execution). Passing logic to the server via the form field. When the interpreter process the value the value is code, so the interpreter executes it. A basic step would be to us PHP's filter input function (php.net/manual/en/function.filter-...) as a start.
I am aware of RCE. Most these types of attack relies in exec() or eval(). RCE could be done in case of buffer overflow, however this type of exploitation take advantage of bugs in functions that manipulate strings, like crypt() or serialize(). It's valid to mention that this script doesn't perform any string manipulation except hashing the user input password.
So, about the security issues, If an old version of PHP (like 5.5) is used, it's security problems could be exploited to do a buffer overflow attack, or some kind of session attack.
Well, your insights really helped me. If I want to support 5.5, I should minimize the possible attacks that could be made.
I willNow the script validates the username and password to only accept ASCII printable characters.I want to state that I am relying totally in the PHP's capacity to protect his own session data, so any ideas to improve this script, without forgetting it's main goal, are welcome.
Thanks David.