5
You are correct this implementation of constant-time string comparison will leak information about the length of some string that is being compared against an attacker controlled string.
However, if this is checking strings for authentication purposes, you never should be comparing raw strings. You would first hash (preferably with a salted key-...
3
Because when you do this <"script src="ATTACKING IP:PORT443/phpbackdoor.php"></script>
The file isn't executed server side at all instead it is executed by the victim browser and of course it doesn't work its a PHP file.The browser looks for javascript in that,for example try and PHP echo "VALID JAVASCRIPT" and it will get executed by the browser....
2
Yes
The presence of #!/usr/bin/env php as the first line means that this is meant to be used from a shell context - not from the web. When executing from the command line with a line like the above, the extension doesn't matter. So yes, this can be exploited in an attack.
If you found a file like this on your server and you didn't put it there, I would ...
2
There's not really anything else major you can do. There's a few minor things, which I'll get to, but the basic pattern you describe is used near-universally for good reason. Just based on the steps you describe, if somebody were to have their credentials compromised, I would very strongly suspect it to have nothing to do with your HTTPS or password handling,...
2
The only currently known SQL injection vulnerability in PDO parameterized prepared statements using the default of emulating prepared statements is if the client's and server's locale is out of sync.
Since locale is negotiated during the initial connection setup, and persists for that connection even if the server's default is changed, in order to get the ...
2
Generally, SQL Injections happens when an unsanitized variable is used in a query, regardless of wether there is a apostrophe or not.
In PHP you want to use prepared statements. This will transform your query into:
$sql = "UPDATE `users` SET
`user_age` = ?,
`user_sex` = ?,
`user_description` = ?,
`user_sound` = ?,
...
2
Nuke it from orbit!
An attacker compromised your server. It's no longer your server. re-Install the OS, fix the vulnerability in your application and then re-deploy
1
It definitely sounds like you could get clarity on a the task.
But if that's all you have, I would start here: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet
These are the 10 most common vulnerabilities for web applications. I would suggest going through each one following the instructions for checking whether they exist and steps to remediate ...
Only top voted, non community-wiki answers of a minimum length are eligible
