Jacques1

That's why every programmer/administrator in their right mind uses a defense-in-depth approach: You need to take care of the OS and the webserver and the applications and the database system etc. Keeping your Wordpress up-to-date is a good start, but it's not enough. I don't care if there are valid reasons for giving Wordpress write access to PHP files. Considering the security record of this software, I wouldn't do it, especially when it's a private website which can easily be maintained by hand. It's a different story for professional applications (which this thread isn't about). But even then you need a damn good reason for relaxing the read-only policy.

There may certainly be a vulnerability in your code, but the real issue is that your PHP scripts are writable. An application must never be able to change arbitrary files on your server, no matter how broken it is. So before you jump to Wordpress-specific fixes, you should take care of basic server security: Are you using a plaintext protocol like FTP? Then you need to switch to SFTP or SCP. Do you use password-based authentication? Then generate a new long, random password with a password manager like KeePass. Also consider switching to public-key authentication. Check your file permissions and reduce them to the absolute minimum. PHP scripts only have to be readable (by the webserver), not writable and not executable. Check the security of your database. Never use the database superuser for applications, and make sure you have a strong password. Those simple steps will prevent a lot of attacks. We won't be able to make Wordpress (or similar software) perfectly secure, but we can definitely ensure that an application vulnerability won't compromise our entire server.

If you didn't put the code into the scripts, then it's malware. This particular snippet seems to be known Wordpress malware which loads content from an external URL and embeds it into your site. But the details don't matter. Take your site down right now, grab somebody who understands system administration and carefully reinstall everything from the ground up, this time with proper security. There's something very, very wrong with your server when people can change your PHP scripts.

I just told you that you do have a choice: Use a callback.

Some characters obviously have a special meaning when used in an HTML context (like “<” or “&”). If your PHP variables happen to include those characters, you'll quickly end up with all kinds of bugs and security vulnerabilities. Escaping prevents that by turning the special characters into HTML entities. For example, the less-than sign is converted into < which denotes a literal less-than sign rather than the beginning of an HTML element. URL-encoding does the same thing for URLs. Sometimes escaping may seem unnecessary, because you believe that the data is harmless (e. g. a simple number). You should still escape it to avoid any risks. Advanced template engines like Twig automatically escape all input by default. No, you're using an outdated PHP version. Those constants were introduced in PHP 5.4. All versions before 5.5 have reached end-of-life and are no longer supported. So it's time for an update (or a proper hoster). For now, you can just remove the two offending constants (do not turn them into strings). They're not critical.

What are you even trying to do, spock9458? So your hoster has updated your PHP version, and your old code has “stopped working”. But instead of actually investing the problem, you've started to randomly insert new PHP features you found somewhere on the Internet, and now the code “doesn't work” in any PHP version. That helps you how exactly? Do you just want to get your application online again? Then don't change things that never caused any problems in the first place. Identify the actual incompatibilities by analyzing the error log and reading the PHP 5.3 Migration Guide. Or do you want to clean up your entire code and make it ready for the future? Then you need to actually understand the current state of PHP. Appending the letter “i” to your mysql_* functions doesn't cut it. Why did you pick the MySQLi extension in the first place? Just because the name looked familiar? This extension is very cumbersome, it's naturally restricted to the MySQL database system, and a lot of users are very unhappy with it. So before you make a choice, you should consider the alternatives like PDO. Both PDO and MySQLi are very different from the old MySQL extension, they're not a drop-in replacement. Dynamic queries are now implemented with prepared statements, and the manual error handling has been replaced with more intelligent approaches. So before you use the new extensions, learn them. Your error handling is generally nonsensical. You've cluttered your entire code with die(mysql_error()) statements which print the error messages right on the user's screen. Why would you do that? Are your users supposed to somehow debug your database issues? Again: Learn and understand the features, don't just copy-and-paste stuff you found somewhere on the Internet. You currently have no security whatsoever. You just insert all kinds of variables into all kinds of contexts. Never heard of cross-site scripting? SQL injections? Your PHPSQLHTMLCSS mixture makes the code extremely hard to read. Consider using a template engine like Twig and putting the style declarations into separate CSS files. I know this is a lot, and of course you cannot do this all at once. My point is: Get clear about what you want to do and what the tasks are. Then write the code. Right now, you have it backwards.

Check your code: echo "<li><a href='products.php?product=$id'>$nm</a></li>\n"; if (isset($cats[$id])) { displayList($cats, $id, $level+1); //increment level } You're closing the li element before you call displayList(), but you must close it afterwards. Because displayList() generates the ul element with the sub-entries. You also can't just insert PHP variables directory into URLs or HTML markup. They have to be escaped and encoded: <?php function html_escape($value, $encoding) { return htmlspecialchars($value, ENT_QUOTES | ENT_HTML5 | ENT_SUBSTITUTE, $encoding); } $product_url = 'products.php?'.http_build_query(['id' => $id]); echo '<li><a href="'.html_escape($product_url, 'UTF-8').'">'.html_escape($nm, 'UTF-8').'</a>'; if (isset($cats[$id])) { displayList($cats, $id, $level + 1); } echo '</li>';

The last words of a programmer: “What could possibly go wrong?” Things do go wrong. Even if your application makes perfect sense in the localhost bubble, that doesn't mean it will survive in the real world: There are dozens of crazy syntax variations and browser quirks which none of us has ever heard of. Applications have bugs. Applications have security vulnerabilities. A single successful SQL injection attack is enough to insert all kinds of malicious data into your “safe” fields. If you're working in a team, there will always be an imbecile who changes the data directly and bypasses your filter. So you cannot rely on anything. The only chance to make an application secure is to write robust code and avoid as many risks as possible. This excludes dynamically generated JavaScript code.

Read the replies. The whole approach is simply wrong. What if the name contains a double quote? What if the name ends with a backslash? What if the name contains "}]; stealAdminSession(); //? What if the name contains </script><script>stealAdminSession();</script>?

Silently redirecting to an error page is a bad idea, because that's simply not how the HTTP protocol works. The status of the response is determined by the response code. If you do a redirect, that means: “Everything is fine, but the content is now at ...”. That's obviously nonsense in your case, because what you actually want to say is that the user isn't authorized to view the page (which is an error). Sure, a human with good eyes will look at the page and figure out that your “Everything is fine” really means “You've made a mistake”, but not every webclient is a human, and not all processing is done by humans not every human has good eyes So don't rely on clients to figure out the status from purely visual information. Always set the appropriate error code. Unfortunately, Apache seems to have trouble showing the right error page when the response code is generated by PHP. As a workaround, I'd display the error page and at the same time use http_response_code(401): <?php http_response_code(401); readfile('/path/to/custom/401/page'); (You can also define a function which automates those two steps.)

You actually can assign multiple values to a single parameter, but PHP wants you to mark this parameter with square brackets: <?php function html_escape($value, $encoding) { return htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, $encoding); } if (isset($_GET['x'])) { echo 'The following values have been passed to the parameter x:<br>'; foreach ($_GET['x'] as $x) { echo html_escape($x, 'UTF-8').'<br>'; } } ?> <a href="test.php?x[]=1&x[]=2&x[]=3">Click me</a> (The brackets should be URL-encoded as %5B and %5D, since they're reserved characters. This is only a demo.)

As requinix already told you in the beginning of the thread (see reply #2), JavaScript doesn't work like this. The web_socket_open() function doesn't wait for the inner function. It registers the inner function as a handler for the readystatechange event and then returns immediately, long before your return statements take effect. Your statements also refer to the inner function, not web_socket_open(). This actually works like with any other event handler. In your main JavaScript code, you probably assign a lot of functions to click events, mouseover events etc. Does your entire code pause until the user has finally clicked on some button and made the event handler return? No, the code just registers the event handler, and then later the handlers are called. It's really important that you understand the asynchronic nature of JavaScript. If you want to do something based on whether or not the web socket was opened successfully, you need a callback function which you pass to web_socket_open(). As soon as the socket was opened, you call that function.

Do not try to generate JavaScript code. Seriously, don't. Even if you use json_encode(), you will end up with security vulnerabilties and tons of bugs. Generating formally valid JavaScript code is already hard enough (and your example code shows that you have no idea how to do that). But when you're in a web context, you also have to worry about your JavaScript code interacting with the HTML markup. And that's when things get out of hands. I know this task looks easy: Let's just take the PHP strings, wrap them into a bunch of quotes and braces, and we're done. But this is an incredibly stupid idea and will blow up your application sooner or later. Many people have tried this, and they've all failed. So don't even try. Separate your data from the code: Either use Ajax (that's when JSON-encoding is actually appropriate). Or embed the JSON-encoded data into a hidden HTML element. This is described in the link above.

The easiest option is to send the appropriate content type with header() and then show the file content with readfile(). <?php header('Content-Type: application/pdf'); readfile('/path/to/pdf'); A more sophisticated and efficient approach is to delegate the file transfer to the webserver: mod_xsendfile for Apache X-Accel for nginx

Not much. MCRYPT_RAND doesn't provide secure random numbers. It's the equivalent of rand(), so it's a primitive time-based pseudo-random number generator which is susceptible to collisions or even precomputation. The salt length is incorrect. bcrypt expects 128 bits (or 16 bytes). The salt encoding of bcrypt is very different from standard Base64, it's not enough to replace “+” with “.”. Using base64_encode() will yield “impossible” salts, and the only reason why this works at all is because the current bcrypt implementation has an error correction procedure. I wouldn't rely on that, though. The function fails to recognize errors, so it will happily return empty or broken hashes (PHP had several bugs in the bcrypt implementation). It doesn't even check if PHP actually used bcrypt and no fallback algorithm. The input length isn't checked. Everything above 56 bytes is outside of the bcrypt specifiction, and everything above 72 bytes will be truncated. The input isn't checked for null bytes. crypt() isn't binary-safe, so null bytes lead to truncation. There's no way to adjust the cost factor (which is the whole point of password hash algorithms). Using crypt() directly is really not a good idea. It's a terrible, hostile, bug-riddled function which needs tons of error checking to even make sense.

The password_compat library will emulate the functions in legacy PHP versions down to PHP 5.3.7. All previous versions have a defect in the core bcrypt implementation and cannot be used securely.

It's difficult to give advice for this extremely abstract scenario. Generally speaking, a method should make sense on its own and not have hidden dependencies all over the place. You should be able to give a clear description of what this particular method does. If you cannot do that, you should refactor it. Maybe you need an additional parameter, maybe you need to break the logic into multiple methods, maybe you have to do a lot more. That depends on the actual problem (which you haven't stated yet). Callbacks do make sense in some special scenarios, but you shouldn't use them as a standard pattern. When you're starting to pile up closures and your requirements are becoming weirder and weirder, it's definitely time to stop.

Well, there aren't many options. Either you import the entire $a array, or you extract one particular element and import that.

You seem to overuse closures a bit. Regarding your question: Can't you store $a['x'] in a temporary variable (like $x) and pass that to the closure?

Well, then appearently HostGator has decided to manually disable the standard mysqlnd driver (for whatever reason). So now we're talking about a nonstandard PHP setup. Try this: Enable SQL error reporting before you establish the database connection $mysqliDriver = new mysqli_driver(); $mysqliDriver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; A cleaned-up version of your original code $code_data = []; $code_query = $node_connection->prepare(' SELECT operation, `condition`, variable, `condition-variable`, `has-expiration`, `expiration-date` FROM promo_codes WHERE `'.$params['reference'].'` = ? '); $code_query->bind_param('s', $individual_code); $code_query->execute(); $code_query->bind_result($code_data['operation'], $code_data['condition'], $code_data['variable'], $code_data['condition-variable'], $code_data['has-expiration'], $code_data['expiration-date']); $code_query->fetch(); var_dump($code_data); You really need to get rid of those awful nonstandard identifiers. “condition” is a reserved word, and hyphens don't belong into SQL identifiers. Or is this a requirement as well?

What does php -i | grep mysqlnd say? Is this a PHP installation from a package?

Character encodings are a bit tricky, because there are many places where things can go wrong. The character encoding of your webpages should be declared in the Content-Type HTTP header. This can either be done by the webserver (which is preferrable) or within PHP: header('Content-Type: text/html; charset=UTF-8'); In addition to that, you might use a <meta> element. This is primarily meant as a fallback mechanism for offline documents (when the HTTP headers are no longer available). Note that the Content-Type header takes precedence over the <meta> element. Also note that the meta character encoding should be declared as early as possible, because browsers will only scan the first few bytes of the document. A good place is right after the opening <head> tag. If you do this, then, yes, both the input and the output will use the UTF-8 encoding. In case you store the data, you must also make sure that the database connection and the database itself use UTF-8. This is not the default. MySQL typically uses “Latin-1” (ISO-8859-1), so that's another common source for errors.

This isn't Rent-a-Coder. Multiple users have offerered to go through your current code and help you fix the problems. Appearently you don't want that (or maybe there never was any code in the first place). You want somebody to write a “super-simple one-liner” for you while you sit back and relax. It doesn't work like this.

Are you sure that the content of $text is ISO-8859-1-encoded? Because that's what utf8_encode() expects.

It's the default since 5.4, and everything below PHP 5.5 has already reached end-of-life. So there's no good reason for avoiding this.