Jacques1

@NotionCommotion: Your code checks the permissions of the script owner, but you need to know the UID of the process: var_dump( posix_getuid() ); That most definitely isn't “NotionCommotion”, rather something like “www-data”. If you want PHP to create directories, you need to make www-data (or whatever the user is called) the owner of the parent directory.

Look, I completely understand that you want to get this stuff done as quickly as possible, but critical code simply cannot be written in the usual trial-and-error fashion. You need to actually understand what you're doing. At least half of the code is downright harmful and will, in the worst case, leave you with empty passwords and duplicate usernames. That's pretty serious. Sure, you can keep adding bugfixes, but in the end, it's still just trial-and-error. So again: If you want to write this yourself, you need time, and you have to do a lot of research before you write a single line of code. Do you have that time and patience? If not, forget about it. You're better off using a premade solution.

Please don't resurrect two-year-old threads only to post a wall of uncommented, obsolete and insecure code. This may be well-meant, but it doesn't help.

There's also this thing called social pressure. Most marketplaces and customers (at least the serious ones) actually have in interest in keeping their code clean, so if one programmer starts to plagiarize everybody else and violate all kinds of licenses, he will get into trouble, regardless of what the law says. So again: I fail to see the real problem here. Yes, theoretically, we could all go out right now and “steal” any open-source project. There's no technical barrier to prevent this. But that doesn't mean we would get away with it.

No, this is not secure, and appearently it's not even your own code. You seem to have randomly copied and pasted all kinds of nonsense you found somewhere on the Internet (without attribution). Ironically, you've even copied comments like this: // Did not work So the original author clearly states that he has no idea what he's doing and needs help himself, yet you want to use his code in production? I think this kind of Frankenstein code is pointless. You should make a clear decision: Do you want to write your own code, or do you want to use existing code? If you want to use code, it's important to follow some basic rules: Make sure the author actually knows what he's doing. The code needs to be organized in an actively maintained library so that you get bugfixes and updates. Respect the author. I understand that copy-and-paste is extremely common in the PHP universe, but not everybody is OK with that. Some authors want to be attributed, others use a specific license. Make sure you don't violate any “terms of use”. If you want to write your own code, forget about copy-and-paste. Learn the basics of security, learn how to hash passwords, and then actually write code. This won't be an easy task, so this may take weeks or even months.

You could combine an arbitrary username with a known password by using a UNION: SELECT username, password FROM users WHERE username = ' -- begin injection ' UNION SELECT 'admin', password FROM users WHERE username = 'my_own_username -- end injection ' So your own password would match for a different user. But all of those examples really trivialize the threat of SQL injections. This isn't about logging in as somebody else and doing some shenanigans. A single injection vulnerability is enough to download the entire database and maybe even take over the server (since MySQL has the ability to write output files, a poorly administered server will allow you to place arbitrary scripts in the filesystem). In that regard, it doesn't matter how the vulnerable query looks like or how many input values it takes. Any injection vulnerabiltiy can potentially compromise the entire server.

$_POST['username'] = "username'-- "; $query = "SELECT * FROM users WHERE username = '{$_POST['username']}'"; $res = mysql_query($query); var_dump(mysql_fetch_assoc($res));

Nobody said anything about professional code. I'm talking about code that at least won't cause damage. Your hobby is to implement multilingual contact forms, painfully debug every single problem over a course of many days and then throw everything away? OK.

No offense, but if you don't know anything about PHP, use templates from a company that doesn't give a damn and rely on a hoster that doesn't give a damn either, I doubt that we can help you. You'll need to hire a competent sysadmin/programmer to recover from the attack and set up a secure system for the future. There's really no other way.

You'd have to do it every single time, which is why you should set up a proper PHP configuration file instead of messing with the settings at runtime. See the manual.

With all due respect, lingo5: You should just throw your code away and start from scratch, this time with a proper mailer library and a basic understanding of security. What you've written there is malware (even if that certainly wasn't intended). You allow anybody to inject arbritrary content into the e-mail and send it to arbitrary people over your server. This is called an open mail relay, and it's one of the reasons why our inboxes keep getting flooded with spam. As soon your hoster realizes that your application spreads Viagra spam, you can be pretty sure that you're not welcome anymore. In the worst case, the hoster itself will end up on a spam blacklist, and that's when people really get pissed off. So, please, don't just upload code you found somewhere on the Internet. Learn the basics of security and use established libraries instead of copy-pasting crap code.

You said your hoster doesn't allow you to access the /tmp folder directly. Have you considered using a save path which you do have access to? It would make things a lot easier, because you could actually see what's going on. Otherwise, this looks like you need to contact support. I don't see how we could fix your server configuration problems from here, especially when you don't even have sufficient permissions.

No, you're not using exceptions correctly. It would be insane to write a separate try statement for every single action that could possibly go wrong. You'd have to clutter your code with thousands of statements all doing the exact same thing. Actually, the whole point of exceptions is that you do not have to manually check for errors all the time: Since exceptions “bubble up” the call stack, you can just leave them alone. Either catch them on a higher level or let the PHP error handler do its job (which is what you usually want). Secondly, exceptions are just a small subset of all possible errors. As you're probably aware, PHP wasn't designed as an object-oriented language. It started out as a purely procedural language, and a lot of core functions rely on notices, warnings etc. rather than exceptions. So your logger needs to handle all kinds of errors, not just exceptions. Since this is clearly a global error strategy which you want to apply to your entire application, the right approach is to set up an error handler. This allows you to specify how PHP should handle errors. Besides the logging, you'll also need to make sure that the user gets an appropriate HTTP code and sees an error page (but do not print any internal PHP errors on the screen; it's not the job of your users to debug your code). Besides that, your try statement makes no sense. Always catch and throw specific exceptions (e. g. InvalidArgumentException), and always terminate the script if there's no way to recover from the error. If you keep running after an error (like you currently do), you're likely to cause havoc. As a more extreme example: <?php // DO NOT USE THIS try { do_something_critical(); } catch (Exception $error) { // your error logging stuff } // Script execution continues Since Exception is the superclass of all exceptions, the above try statement will catch every exceptions that can possibly exist. It could be anything from “There's a tiny problem with an argument.” to “Russian hackers have pwned your server, need to shut down immediately!”. Do you really want to take responsibility for every possible error (most of which you don't even know), just log it and then keep going? That would be insane. Don't use Pokémon exception handling. Unless you have a specific error handling strategy for a specific exception, just leave it alone.

Nope, I just warned the OP that if the application relies on global variables being imported, the wrapper will break this mechanism (this can be fixed, of course). I use wrappers in the same way that you do, but I commonly see people use require to import database connections, configuration data and whatnot.

The fact that global variables are imported into the scope of the wrapper function rather than the global scope of the including script may actually break things. 0x00, if you commonly define global variables in auxiliary scripts (e. g. $database_connection in something like db.inc.php) and then expect them to be available in your main script, the wrapper won't work. You'll have to explicitly mark the global variables by using the $GLOBALS array or not import any globals at all (like requinix) or forget about the wrapper function and do the logging in the included scripts themselves

The output of bcrypt has the following pattern: $2y$<cost>$<encoded salt><encoded hash> The <cost> part consists of exactly two decimal digits, <encoded salt> has exactly 22 Base64 digits (to encode 128 salt bits), and <encoded hash> has exactly 31 Base64 digits (to encode 184 hash bits). That's a total of 60 ASCII characters, hence CHAR(60). The definite source is the implementation. Or the function reference. Algorithms other than bcrypt may of course need a different length.

When you design a database schema, it's usually good idea to forget about PHP code, MySQL queries etc. and just look at the data. Write down what you want to store and how the different entities are related. Diagrams are also helpful.

The problem is that you're stuffing all kinds of different entities into this weird updates table, and then you try to separate them again using cryptic type identifiers like “a”, “b”, “c”. I've checked your problem a couple of times, but then I just gave up, because none of this makes sense to me. Even if we could somehow fix your query, that wouldn't really help, because the underlying design would still be broken. So I strongly recommend that you fix your database schema before you write any line of code. SQL isn't Excel. When you have different entities, you need to put them into different tables rather than using some kind of gigantic spreadsheet for everything. You should also use clear, unambiguous identifiers which other people (and your future self) can actually understand. What is “os_id” supposed to mean? Why is there both an “account_name” and an “author”? What do “a”, “b” and “c” represent again? This is just incredibly confusing and makes it difficult to understand even this trivial task.

I don't need PHPMailer. I can download that myself. I'm talking about the code where you use PHPMailer. Somewhere in your application there must be a section where you actually instantiate the class to send an e-mail. That's what's relevant. And again: Are you sure you're allowed to relay e-mails through the SMTP server you're using for PHPMailer? Is it your own mail server?

I doubt that anybody can help you based on the info you've provided. All I see is a lot of HTML markup not really related to the problem. Where's the actual code to send the e-mail (minus your credentials, of course)? Are you sure you're allowed to relay e-mails through the SMTP server you're using?

Are you absolutely sure that the path should have a leading slash? According to your original code, the images are actually in a subfolder called “Images”. In that case, the path needs to look like this: Images/$template[0] Otherwise, all images are searched directly in the document root.

Man, that's so funny.

You cannot put raw double quotes into a double-quoted string. How is PHP supposed to figure out which ones are literal quotes and which ones are string delimiters? If you insist on using double quotes for the HTML attributes (instead of single quotes as suggested by Barand), you'll have to escape them: echo "<img src=\"/$template[0]\" alt=\"random image\">"; If this was serious code, you would of course have to HTML-escape the path before inserting it into the HTML attribute: echo '<img src="/'.htmlspecialchars($template[0], ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8').'" alt="random image">';

So you're saying that when you var_dump() your $updateid variable, literally copy it into the query string and run the query, you do get results? Are you sure you're accessing the right database? What happens when you hard-code the ID into the PDO query?

An empty array is not an error. Are you absolutely sure that the query should return rows? Have you checked it by running the underlying query in phpmyadmin?