Jacques1

Both the key and the IV must be raw, unencoded strings with exactly 128 bits (or 16 bytes). Right now, all your strings are hex-encoded and also way too long. const CRYPTO = require('crypto'); const CIPHER = "AES-128-CBC"; const MASTER_KEY_HEX = "5e2a0626516f3108e55e25e4bb6a6283"; const MASTER_KEY = new Buffer(MASTER_KEY_HEX, "hex"); // encrypt var plaintext = new Buffer("attack at dawn"); var initVector = CRYPTO.randomBytes(16); var cipher = CRYPTO.createCipheriv(CIPHER, MASTER_KEY, initVector); var ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]); console.log( ciphertext.toString("hex") ); // decrypt var decipher = CRYPTO.createDecipheriv(CIPHER, MASTER_KEY, initVector); var decryptedPlaintext = Buffer.concat([decipher.update(ciphertext), decipher.final()]); console.log( decryptedPlaintext.toString() );

Why not do it directly in GPG? gpg2 --export-secret-keys --armor (your ID) > sec.asc gpg2 --export --armor (your ID) > pub.asc gpg2 --export-ownertrust > trust.asc

The best way is to repair your database design and store the data in a normalized manner. One field is for one piece of data. When the layout is so broken that you can't even do a simple join, it's definitely time for a fix.

First off: I hope this is not your actual master key? If it is, you now need a new key. Node.js is perfectly capable of performing cryptographic operations. In fact, it's a lot better than the half-assed PHP/OpenSSL extension we're stuck with. Just make sure to use crypto.createCipheriv() so that you can pass the stored initialization vector and master key to the function. The master key should be placed in a separate configuration file outside of the document root (this is also a lot safer than embedding it in the application code).

First off: Forget about your REPLACE queries. Right now, you have much more important issues, namely an attack (or at least a huge problem with your software). You haven't really provided any relevant information, so it's hard to give concrete advice. But you should definitely take this seriously. Shut down the webserver or at least this specific site. If you use insecure protocols like FTP, stop it. Use SSH/SCP/SFTP with public-key authentication. Also download a password manager like KeePass to generate purely random passwords for admin accounts etc. Did you write the code yourself, or is this standard software? If it's a common application, check for updates and carefully read the changelogs as well as all current security advisories. If it's your own code, you need to learn the basics of security and then review every single script. Check your logfiles, especially the PHP error log and the database query log. This may give you important information about what has happened. Fix the problems and restore your data from a clean backup (you do have backups, right?). Also make sure there are no backdoors left anywhere on the server. Check the overall security of your server. Are file permissions kept to a minimum? Does the database role of the application only have the required privileges? That's a lot, but don't underestimate the problem. Right now, it may look like a harmless script kiddie playing around with your data (or even just a bug), but we don't know that.

intval() is harmful even for integers, because it will truncate big numbers. And inserting the data straight into the query comes with the risk of SQL injections or at least syntax errors. The IDs may be safe right now, but this can change. In fact, this should change, because hard-coded magic strings buried somewhere in the application code suck. Use a prepared statement instead: $tree_ids = [ 'FBR-15', 'FBR-16', 'FBR-17', 'FBR-18', 'FBR-19', 'FBR-20', 'FBR-500', ]; $tree_stmt = $database_connection->prepare(' SELECT tree_code FROM tree_tbl WHERE id IN ('.implode(',', array_fill(0, count($tree_ids), '?')).') '); $bind_args = []; $bind_args[] = str_repeat('s', count($tree_ids)); for ($i = 0; $i < count($tree_ids); $i++) { $bind_args[] = &$tree_ids[$i]; } call_user_func_array([$tree_stmt, 'bind_param'], $bind_args); $tree_stmt->execute(); $tree_stmt->bind_result($tree_code); while ($tree_stmt->fetch()) { var_dump($tree_code); } Yes, this is unbelievably cumbersome with MySQLi, which is why we generally recommend PDO.

It doesn't make sense to concentrate on exceptions in particular, because they're just one way of how PHP handles errors. In fact, large parts of the PHP core still rely on classical errors. You should take care of all errors instead. This automatically includes exceptions, because PHP turns unhandled exceptions into fatal errors. Catching an exception in the code only makes sense if you have a concrete solution for a specific problem. This is very rare. 99% of the time, the problem cannot be solved at runtime, and the exception should simply be left alone. It's also unnecessary to implement basic features like logging, error pages etc. yourself, because PHP can already do that. To enable logging, simply turn log_errors on and point error_log to the logfile. Error pages can be displayed by the webserver: If PHP encounters a fatal error while display_errors is disabled and no output has been produced yet, it will emit a 500 status code. The webserver can detect this code and show a custom error page. Showing custom errors is very easy with modern webservers like nginx: fastcgi_intercept_errors on; error_page 500 /error_pages/5xx.html; location /error_pages { internal; # the error pages should not be publicly accessible } I think it's slightly harder with Apache. For more detailed info, see The mystery of errors and exceptions.

Indexing method? What do you mean? Either way, database-specific questions are more suited for the SQL forum.

You should definitely have a single database for the entire application. Creating a new database for every school is a bad idea. Not only is it insecure, it's also a huge problem for backups and updates, because you'd have to repeat everything for each database. MySQL was designed to handle hundreds of millions of rows. I'm fairly sure your school project needs a lot less than that.

So you're completely new to PHP, yet at the same time you've managed to assemble a bug-free state-of-the-art login mechanism? That's a bit hard to believe. Realistically, your forms are wide open to anybody who can type a URL on their keyboard. And even if we forget security for a moment, the idea of sending data to the PHP interpreter in the hopes that nothing will get executed is still incredibly bad. Yes, we can help you solve the underlying problem and show you a sane way of storing data. But, no, we will not help you shred your server.

The approach is very poor and very dangerous, because the text which you happily dump into a text file and then load into your script with an include statement is in fact treated as code. Nothing prevents an evil-minded user from actually putting PHP code into the file and having your server execute it. It's generally a bad idea to store data in text files, especially when you do it in a fire-and-forget fashion with no error checking, no locking, nothing. I can almost guarantee that your files will be filled with pure garbage after a while. Do you have an SQL database on your server? Something like MySQL? If not, there's still SQLite which stores the database in a single file. Learning the basics of SQL is easy, and it's definitely worth it. You'll never want to go back to your text files.

The logic is hard to follow, because you've piled up a large amount of PHPSQLHTMLJavaScript spaghetti code, odd design choices and parts which just don't make sense. Like this: $sql = "UPDATE `members` SET `" . $_POST['budget'][$index] . " WHERE `id`='" . $id . "'"; That's not a query. It's probably a query fragment and definitely an SQL injection vulnerability. Also, I still have no idea what exactly your problem is (maybe I've missed it). What are we supposed to do now? Try to guess what's on your screen? Quite frankly, I'd scrap the code and start over: Your database layout needs rework. Right now, you appearently have a gigantic Excel-style table where you keep all your users, all your projects and all membership information. And whenever there's a new project, you need to add a new column to the table schema. That's not how SQL works. You want one table for the user-related info (name, address, whatever), one table for the projects and one table which assigns users to projects. As ginerjm already said, you need to separate the PHP business logic from the HTML stuff. Personally, I'm a big fan of template engines like Twig, because they more or less force you to write clean code. PHP relies entirely on the programmer's discipline (which rarely works) and is actually very bad at generating dynamic HTML Start taking security into account. Use prepared statements instead of dumping user input into query strings. Checkboxes are tricky, because only the checked ones are actually submitted. Since you rely on an implicit numbering scheme, this may be a problem. There are more robust solutions, but you should first fix the issues above.

Pass true to the constructor to enable exceptions. Note that there are many different reasons for why a mail isn't delivered, and not all of them can be fixed with code. Anyway, let's see what PHP has to say.

PHP 7 has a nice null coalescing operator for exactly this purpose: $_SESSION["posY"] = $_SESSION["posY"] ?? 50; If $_SESSION["posY"] is already set, it's left alone, otherwise it's set to the default value 50. JavaScript and Ruby have the same thing, so it's a fairly common concept (PHP is just a bit late again).

OK. In that case, the code will be good enough. To distinguish between a duplicate name and a duplicate address, you can either parse the error message or make a second query after the INSERT query failed: Simply fetch all users where the name or the address matches the submitted data, then inspect the resulting row to find out which of the two has caused the problem.

In that case, you'll need a very different approach. When you first check the database and then insert a new row, there's a small timeframe where a different PHP process may also insert a new row and invalidate the result of your check. Your application won't see that and just keeping going. In the worst case, you now have two rows with the same data despite your checks. This situation is unlikely to happen by accident, but the bug can actively be exploited by anybody. A much more reliable solution is to let the database do the check. Add a UNIQUE constraint to the columns and then simply try to insert the new row. If that fails due to a constraint violation, you know the data is not unique. Otherwise everything is fine. <?php // database settings const DB_HOST = '...'; const DB_USER = '...'; const DB_PASSWORD = '...'; const DB_NAME = '...'; const DB_CHARSET = 'UTF8'; // MySQL error codes const MYSQL_ER_DUP_ENTRY = 1062; // Enable exceptions for MySQLi. $mysqli_driver = new mysqli_driver(); $mysqli_driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; $database_connection = new mysqli(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME); $database_connection->set_charset(DB_CHARSET); $test_name = 'foo'; $test_email_address = 'bar@example.com'; $user_registration_stmt = $database_connection->prepare(' INSERT INTO users SET public_name = ?, email_address = ? '); $user_registration_stmt->bind_param('ss', $test_name, $test_email_address); // Try to insert row. $user_registration_errors = []; try { $user_registration_stmt->execute(); } catch (mysqli_sql_exception $user_registration_exception) { // Was the error caused by a duplicate entry? if ($user_registration_exception->getCode() == MYSQL_ER_DUP_ENTRY) { $user_registration_errors[] = 'The username or e-mail address is already in use.'; } else { // It's some other problem, pass the exception on. throw $user_registration_exception; } } if ($user_registration_errors) { foreach ($user_registration_errors as $error) { echo htmlspecialchars($error, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8').'<br>'; } } else { echo 'Registration successful!'; } There's still a problem left: Usually, the e-mail addresses of users are private, so they must not be exposed, neither directly nor indirectly. Right now, anybody can check if an address is already in your database simply by trying to register with it. Is that different for your site? Do you have an agreement with your users that all e-mail addresses are public?

SELECT -- select concrete columns, not just "*" FROM mail_list JOIN rosters USING (Code) WHERE rosters.SectorDate IN ('2016-01-04', '2016-01-24') GROUP BY -- repeat all the columns from the SELECT part HAVING COUNT(DISTINCT rosters.SectorDate) = 2 ;

Create your own thread with a specific problem description instead of hijacking ancient threads from other users. Also note this is a help forum, not a Gimme-the-code forum. Explain what you've tried and where you got stuck (in the new thread).

What is the purpose of this check? Is it the usual uniqueness check for a user registration script? In that case, there are much better alternatives. Also, you generally must not expose the e-mail addresses of your users to the public. Whether a particular address is registered at your site is none of anyone's business. Instead, you would send out a mail telling the user that they already have an account.

Please don't resurrect dead threads. Write a private message to muppet77 or create your own thread with a concrete problem description.

This will disable certificate verification entirely, leaving the communication wide open to man-in-the-middle attacks and defeating the entire purpose of HTTPS. If you don't care at all about the data you're fetching, and if your entire application is built on the premise that the data can be malicious, then, yes, this might be good enough for a quick hack. But don't use this is a general solution.

Can you create a simple file within the target directory when there's no uploading involved? I mean something like file_put_contents(). Besides that, your code is extremely insecure and buggy. You let anybody upload malicious scripts to your server as long as they claim that the file is an image (the type in $_FILES can be set to anything by the client). I strongly recommend that you you learn the basics of secure file uploads before you even think about placing files on your server.

Try to slow down and write your code more cleanly. This includes proper formatting. When you rush it, you'll spend most of your time debugging errors (or waiting for others to debug them for you), which is somewhat frustrating. An IDE (integrated development environment) like Netbeans or Eclipse can help you write good code, because it will notify immediately when there's an obvious problem (like a parameter which isn't used anywhere).

You can instantiate the class. Look at the line number: The problem happens after that, namely when you try to call getProperty() on the class2 instance $obj (as I already assumed). And like I already said, class2 has no getProperty() method. It only has getProperty2().

Besides that, why on earth would anybody upload trial software to a public webserver? What are they supposed to do with it? Tell all their users about it and then take it offline 7 days later? I'm sorry, but your business model makes no sense. Also, why should I pay $50 per month when I can get an entire entry-level dedicated server plus a free(!) chat script for the same price? What makes your code so incredibly special compared to the thousands of open-source chat scripts on GitHub?