Jacques1

What's new is a bunch of experiments with the inner workings of PHP. If you're a hardcore PHP fan who specializes in low-level language design, that might actually be interesting, but I think the majority of PHP programmers neither understands nor cares about the details (especially not at this early stage). There are no spectacular new features to talk about, so what's the point of this discussion? Do you want to dive into abstract syntax trees and just-in-time compilers?

What do you want to discuss?

Throwing all search results into one big string is indeed a poor choice. This may make sense for the shell of an operating system, but it makes absolutely no sense for a programming language. So, yes, do return an array. Besides that, why do you use stristr()? This gives you the entire substring from the first occurence of the search term. But you just want to know whether the search term exists within the string. That's what stripos() is for.

Did you read the manual? What did you not understand?

Again: What is your specific question? Where are you stuck? Write it down, and we might be able to help you. Your 300 lines of code and the vague request for “little hel to add couple lines” doesn't tell us anything.

We neither write code for free nor provide MyBB support. If you have a concrete question, ask it and post the relevant(!) bits of code. Otherwise, this is probably the wrong place for your request.

Unfortunately, there are much worse problems than the 500 error. Instead of trying to debug this, I'd rather throw away the code, learn PHP and start from scratch. Sorry for being so harsh, but you appearently had a very, very bad teacher. Where do I start? If you happily drop any user input into your query strings, then you invite the whole world to change the queries and see what they can find in your database. They'll start with the plaintext passwords of your users. Plaintext passwords? Seriously? Removing spaces from the password is not a good idea. They are actually significant. How could $user or $password ever be empty when you've defined them as "'$user1'" and "'$pass1'"? A string with single quotes isn't empty. Why you would add quotes at this point is beyond me. Why do you have a loop for fetching all users with the provided username? Shouldn't there be at most one user per name? If you don't stop the script after doing a redirect, then it happily keeps running. That's probably not what you want and can lead to major security issues. There's absolutely no session security. However, I do admit that PHP sessions are difficult to handle for beginners. ...

Not quite. Use \A and \z instead of ^ and $. The former are unambigious, whereas the latter have different meanings depending on the modifiers. Always escape backslashes, especially if you're using double-quoted strings. A blackslash within a PHP string actually has a meaning, and that can result in unexpected characters or syntax errors. If you want a backslash in a regex, that's a double backslash in the regex strings. Don't use double-quoted strings for regexes. They have special parsing rules which again can turn your regex string into something unexpected. No need to put \d into a character class. It's a character class by itself. So a proper regex string would look something like this: $my_regex = '/\\A\\+\\d+\\z/'; When you're dealing with more complex regexes which would require an excessive amount of backslashes, use nowdocs instead: $my_regex = <<<'REGEX' /\A\+\d+\z/ REGEX; Then and only then you can use simple backslashes.

I have no idea what you mean and what you're trying to achieve. You keep talking about salts and hashes, but I'm not sure if you know what this actually means. Anyway: Where does the client-side code come from? The server! This is simply server-side encryption in disguise. As I've already tried to explain, you cannot protect data from your self. If you control the encryption process, then you have access to the data. Period. Exchanging passwords is also a bit ... dated. That was before the year 1970. Nowadays, we have tools like GPG which use asymmetric encryption. Again: What salt? Do you mean the key?

You do realize that PHP has a $_GET superglobal which contains all URL parameters, right? The OP simply didn't know when and when not to escape URLs.

C'mon, there are literally thousands of tutorials, books, videos and whatnot about how to access a MySQL database with PHP. This is one of the most basic features of the language. So sit down, Google for it and learn. We can't do that for you. We're not gonna spend the rest of the day giving you private PHP lessons when the learning material is readily available for everybody.

That's not really related to encryption, so you should post it into the right forum. Actually, there is a thread about it already.

So what's the concrete problem? What's your current code (only the relevant parts, please), and what do you not understand?

The structure of the XML data is fixed, at least in the examples you've posted. Sure, not all items have all data (sometimes the address isn't given, sometimes there's no fax number etc.). But that doesn't mean the structure is different. It means the values are missing, which is exactly what the SQL NULL is for. For example, if we don't have the address, then we simply use NULL in all address fields. The question is what you want to do: Do you just want to collect random data from OpenStreetMap? Or do you actually want to give the fields a meaning and use them in your application? In the latter case, you need a fixed schema anyway.

Start with standard web security: prepared statements, HTML-escaping, proper session handling, secure random numbers etc. There's an excellent online book which explains the basics. You don't have to understand every detail, but you should know the most common risks and how to deal with them. This is simply part of being a web developer. Then take care of the parts which are specific to user management. For example: How should passwords be stored? Any competent developer will be able to tell you that we use bcrypt and that PHP has a native bcrypt implementation as well as a compatbility library in case you're running some older PHP version. If you get this right, your code will already be better than most of the stuff floating around on the Internet. But what's much more important is that you're actually becoming a programmer. You don't just copy code from other people. You write your own code and use your own abilities. The last step (which really never ends) is that you deepen your knowledge and keep up-to-date. How do the security techniques actually work? Which other ideas do people come up with? What about more exotic attacks? This is a long journey of reading, thinking, playing around and discussing. Either way, it's great that you want to take this route, and I'm sure everybody will gladly help you with your questions. People who actually want to learn something and get better are always welcome.

This actually leaves a lot to be desired, even if it may “work” (whatever that means). Numbering variables or keys is awful, don't do that. We have arrays for this purpose: Simple use the name photo_descriptions[] (the brackets are important) for all input fields, and $_POST['photo_descriptions'] will be an array of all values. Please don't tell me you've created a separate table for every single photo. When you ask people the enter 131 friggin' photo descriptions, it's time to worry about write conflicts. Imagine the following scenario: User A and user B both open the form (it could also be one person with two tabs). A makes major changes and saves them. B only changes a few descriptions and also saves the form. Now B has unknowingly overwritten the entire work of A. I'd be pissed. Do you really want to run all 131 queries even if the user has only changed a single description? There's absolutely no need to manually check every query for errors. MySQLi can report errors itself.

First of all, I am not against encryption in general. Quite the opposite: Using the right tool for the right reasons is fantastic, and I applaud everybody who does it. The problem is that there's way too much bad cryptography. It's easy to call a bunch of Mcrypt functions, store the ciphertext somewhere and tell everybody that their data is now super-secure. This requires little more than common sense. But it's damn hard to define a concrete security context, choose the right tool and use it in the right way. Unless you actually have a security background and a lot of experience, I'd say it's as realistic as a layman managing to perform a brain surgery. Even worse: Screwing up cryptography does not mean that you're simply back to square one. You've invested a lot of time and trust, and if the solution then turns out to be broken, that's a real problem. While you were busy encypting your stuff, other security techniques had to wait. While you thought that your data is safe, it wasn't. In other words, a failure makes you actually lose something. If there's little to gain, a lot to lose and a poor success rate, the usual answer is to not do it. Let's take your database encryption as an example. I do agree that this sounds like a good idea at first. But it's easier said than done: How do you encrypt the data? If you use AES_ENCRYPT() within MySQL, you've already lost, because this gives you the extremely insecure “Electronic Code Book” mode (known from the Adobe password leak). The plaintext may also pop up in the query log. So you use Mcrypt instead, which is not exactly the best choice either. Are you sure you're using it correctly? Large frameworks like Yii or Laravel have already screwed up, so you need to be better then those. How do you manage the initialization vectors? Every single piece of data needs a perfectly random string next to it. How do you manage the keys? You need a way to change them in case they have been compromised. That means decrypting all ciphertext, regenerating all initialization vectors and encrypting all plaintext again. Not exactly trivial. Encryption alone only provides confidentiality, it does not help against manipulation. For example, if the attacker is able to change the initialization vector, they control the resulting plaintext. That's probably not what you want. If you decide to add a message authentication code as well, that means three times as much effort and an even bigger risk of screwing up. Sure, this is all doable. But is it really a good idea to spend a large part of the development process on a very fragile security feature which only helps in a specific scenario? Playing with cryptography to learn from it is an entirely different story. If that's your goal, do whatever you like. But don't even think about using it in production.

I wouldn't necessarily say it's the norm. Server-side encryption is actually fairly popular, but for the wrong reasons. Users like it, because they're lazy and usually can't tell the difference between actual security and security theater. And service providers like it, because it allows them to throw around fancy terms like “RSA” or “military-grade AES-256 encryption”. The question is whether encryption makes sense in this case. What's the concrete benefit? What does it protect against? A good example for this discussion is the now-defunct e-mail provider Lavabit (I'm sure you've heard about it). They also used all kinds of fancy encryption and made big promises. As long as no unauthorized persons had access to the server, things indeed went well. But when they were forced to hand over their private TLS key, the whole encryption layer more or less vanished. In other words, they had the exact same problem like a run-of-the-mill provider which does not encrypt their e-mails. So what was the whole point of this project? To make people feel secure when they aren't? Personally, I prefer honesty. I don't make promises I cannot keep. If users send their plaintext messages to the server, they're not secure. I could make the situation a bit less bad, but I cannot escape the basic fact. So I rather make it clear that the messages are unprotected unless client-side encryption is used.

No, the code is simply wrong, and switching from MySQLi to PDO for a single script also doesn't make a lot of sense. I'm not sure why people immediately adopt anything somebody posts into a forum. It doesn't matter whether or not you used a prepared statement in this specific piece of code. The point is that the PDO configuration is broken, and this affects the entire application or at least the whole script. Also note that the query() method does in fact create a prepared statement internally.

@ jazzman: He uses MySQLi, not PDO. And the only reason why your code “works” is because your configuration is broken. You haven't turned off emulated prepared statements, which means that all prepared statements are replaced with client-side escaping. This is a major security risk and can lead to SQL injection vulnerabilities. @ Maze: Backticks are not only superfluos. They're downright harmful, because they can lead to very, very ugly bugs. Let's say you want to use the qualified identifier pois.id in one of your queries, but instead of `pois`.`id`, you accidentally write `pois.id`. Due to the backticks, this is still a syntactically valid identifier, so MySQL will complain about a missing column instead of poiting out the actual mistake. Even worse, the error message looks like the column pois.id is missing (which of course isn't the case). I've seen people spend hours on this. A DEFAULT NULL declaration is not needed, because MySQL does this automatically if NULL is allowed and no explicit default value is given. You can use this for clarity, though. I don't know what you mean by “i have specified NOT NULL then set the default to null ('')”. The empty string is not the same as NULL. Those are two entirely different things. Last but not least, you should remove the length arguments of the integer types. For example, BIGINT(20) should simply be BIGINT. The argument specifies the padding length which you almost certainly won't ever need.

Literally inserting PHP values into a JavaScript context is a very, very bad idea. There's a huge risk that you end up with unwanted code injections. In best case, the script simply crashes, in the worst case, people will actively exploit this bug to perform a cross-site scripting attack. For example, if mogosselin doesn't escape $var1 and $var2 at all, then obviously you can inject a single quote to break out of the string and inject arbitrary code into the script element. But even if he escapes the values with something like addslashes(), there are still ways to inject code: <?php $user_input = ' </script> <script> alert(String.fromCharCode(89,111,117,32,104,97,118,101,32,98,101,101,110,32,88,83,83,101,100,46)); </script> <script> '; ?> <script> // We escape all quotes with addslashes(), so everything should be fine, right? Except that it's not. var foo = '<?= addslashes($user_input) ?>'; </script> Do you know every crazy syntax rule of HTML and JavaScript? I don't. So it's best to avoid this arms race altogether. Instead, separate JavaScript and PHP. This is generally a good idea. Create a single static JavaScript file with the main logic. Create a PHP script which serves the user-specific data as JSON. In the main JavaScript file, make an Ajax request to the PHP script to load the data. If you're not using a JavaScript framework like jQuery yet, now is the time.

Like I said, you can't have multiple statements. The only workaround would be the multi_query() method in the MySQLi extension, but see the comment about security.

You cannot execute multiple queries at once. Well, some database extensions do provide methods for this, but you should never use them due to the huge security risk (if there's any SQL injection vulnerability, the attacker is now able to write custom queries and not just manipulate existing ones).

Not sure if you've understood this correctly. The messages are encrypted. They're just not encrypted by you but by the users themselves – if they choose to do this. The idea of encrypting the data on the server so that you can't see it is rather silly. If you respect the privacy of you users, just don't read the messages. You may set up a database view so that you won't “accidentally” see them. If you don't respect the privacy of your users, why do you care about encryption in the first place? The point of encryption is to make it impossible for unauthorized people to read the data. It's not about “covering your eyes”. If that's your goal, there are much better tools like the already mentioned database view.

Barand just told you how to do it. You set up a script which is regularly executed by the operating system, checks if there are any messages to be sent, and if that's the case, it sends them.