Jacques1

Besides that, it's a bad idea to copy and paste code sections when you want to repeat a certain action multiple times. As you can see, you really just need a mapping from bad words to error messages and then loop over this mapping: <?php const BAD_WORDS = [ 'foo' => "You're not allowed to say 'foo'!", 'bar' => "You're not allowed to say 'bar'!", ]; $test_text = "This is foobar."; $error = false; $error_text = ''; foreach (BAD_WORDS as $word => $message) { if (strpos($test_text, $word) !== false) { $error = true; $error_text .= $message; break; } } if ($error) { echo $error_text; } else { echo 'Everything is fine.'; } Note that “bad word” filters, especially primitive ones like yours, cause more harm than good. Your filter will reject perfectly legitimate input just because happens to share a few characters with an insult (e. g. “assassination”). At the same time, anybody who wants to use insults can of course easily cirumvent the filter. I've actually had this problem on other forums, and I can assure you that it's annoying as hell. I understand that some countries are extremely sensitive about political correctness, but let's not overdo it.

They cannot help you either until you post the actual, full code. The error message indicates that, somewhere outside of the above code snippet, you try to call getProperty() on the class2 instance. But class2 only has a getProperty2() method, so PHP blows up, appearently delegating the exception to Laravel.

What do you mean? What's the problem?

You cannot have output before session_start(). Since HTML markup is output, your script blows up. To avoid this problem now and in the future, I strongly recommend you keep your PHP code and your HTML separate instead of mixing them: All the PHP logic goes to the top of the script, all the HTML markup goes to the bottom. The second problem is that you try to access $filename outside of the if statement which sets this variable. In other words, even when the condition isn't fulfilled and no variable set, you still try to use it. And of course the whole database code is obsolete and wide open to SQL injection attacks. We use PDO with prepared statements now.

The get_result() method is only available for the MySQL native driver (which your server appearently doesn't have). You either have to change the PHP installation or fetch the data with the classical bind_result/fetch. By the way, remove this filter_input() stuff. It will damage the incoming data and serves no purpose whatsoever.

PHP cannot access the file. Use an absolute path and make sure PHP has read permissions on the file. You can get the absolute path of the script directory with __DIR__ and then navigate to the file: <?php const CERTIFICATE_CHAIN_PATH = __DIR__.'/gd_bundle-g2.crt'; // testing certificate file if (!file_exists(CERTIFICATE_CHAIN_PATH)) { echo 'Certificate chain does not exist.'; } elseif (!is_readable(CERTIFICATE_CHAIN_PATH)) { echo 'Certificate chain exists but is not readable.'; } else { echo 'Certificate chain OK.'; }

Are you developing on a live server? Don't do that. Use a local development environment, make PHP display errors and turn error reporting all the way up. Then you'll actually see what's going on instead of just getting a 500 error.

Looks like cURL doesn't find the GoDaddy certificates. Download them manually and then point cURL to that file: curl_setopt($curl, CURLOPT_CAINFO, '/path/to/gd_bundle-g2.crt'); In the long run, consider moving to a Unix-like operating system for development (Debian, Ubuntu, whatever). Windows can be troublesome, and it makes even less sense to debug Windows-specific problems when your server actually uses Linux. You can simply use a virtual machine if you don't want to touch your current OS.

CodeAcademy is OK in the sense that it doesn't teach any wrong or bad techniques. However, it doesn't really teach anything at all. There's no PHP/SQL interaction, no templating, no sessions The PHP course is little more than an advanced “Hello world”, and I find the programming-by-numbers approach overly slow, superficial and limiting. I also ran into quite a lot of technical issues where the checker wouldn't recognize the solution until I changed the formatting, or the page got stuck completely. I your friend has never written a single line of code in any language, he may very well enjoy the introduction. But if he prefers a faster, more abstract, more thorough way of learning, CodeAcademy is probably not the best choice. It's indeed a crying shame that there doesn't seem to be a single good PHP book (something like “21st century PHP”). However, there are good resources for special topics like the Hashphp PDO tutorial or the marvellous PHP Security Book by Pádraic Brady.

You want to destroy code on somebody else's server? This is, thankfully, impossible. Once it's on their server, it's under their control, and there's nothing you could do about that. If you don't want people to actually use your code, don't give it to them. Put it onto your own server and make it available after some registration procedure. Then you can easily block access after a certain trial period.

There are still a lot of problems in your code. You appearently expect your functions to return booleans, but there's no return statement anywhere. Opening a new database connection for every function call is also a bad idea, because it's extremely inefficient and leads to a lot of duplicate code. Instead, open a single connection for the script and send all your queries to that connection. You can pass the MySQLi object to your functions or use a global variable for the connection.

Not for me. Either way, your code definitely needs error handling so that it doesn't just silently fail with a blank page: <?php const FETCH_URL = 'https://www.whoscored.com/Matches/829839/Live'; $curl = curl_init(FETCH_URL); if (!$curl) { trigger_error('Failed to initialize cURL.', E_USER_ERROR); } if (!curl_setopt($curl, CURLOPT_RETURNTRANSFER, true)) { trigger_error('Failed to set cURL option.', E_USER_ERROR); } if (!curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true)) { trigger_error('Failed to set cURL option.', E_USER_ERROR); } $curl_response = curl_exec($curl); if ($curl_response === false) { trigger_error('cURL error: '.curl_error($curl), E_USER_ERROR); } echo $curl_response; curl_close($curl); Make sure that your PHP error reporting is on and all the way up (only do this on your development machine, of course).

curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true);

The code makes no sense, neither syntactically nor semantically. You have misplaced parentheses, a mysterious “0” parameter (what is that supposed to do?), and the query() method simply doesn't work like this. You also shouldn't try to escape the input manually, because this is very error-prone. I don't even know what your sanitize() function does. Instead, use a prepared statement: $user_exists_stmt = $databaseConnection->prepare(' SELECT EXISTS ( SELECT 1 FROM users WHERE username = ? ) '); // Bind values to the parameters $user_exists_stmt->bind_param('s', $username); // Execute statement $user_exists_stmt->execute(); // Bind results to variables and fetch them $user_exists_stmt->bind_result($user_exists); $user_exists_stmt->fetch(); // Inspect result var_dump($user_exists);

You need the cURL library (which may already be installed) and then enable cURL support in the PHP configuration. Judging from your first post, you have a Windows server? Try uncommenting the line ; extension=php_curl.dll from your php.ini and then restart Apache (or whatever webserver you're using).

I'm talking about the configuration. Enabling allow_url_include or even just allow_url_fopen means that every single include statement is now a potential RFI vulnerability. Given the total lack of path sanitzation in many applications, it's actually a very real vulnerability. And then you still have to jump through hoops to prevent man-in-the-middle attacks. Depending on the PHP version, the configuration and the runtime settings, certificate verification is either impossible, disabled, defective or, if you're very lucky, enabled. cURL has none of those problems.

Yes: Stop using those remote fopen/file_get_contents hacks. Not only do they open your entire website to remote file inclusion attacks (you've just allowed PHP to load code from arbitrary URLs). They also have a long history of security vulnerabilities. For example, PHP won't even check the certificate by default, which turns the whole HTTPS thing into a joke. Use a proper HTTP/HTTPS library like cURL.

Yay. Here's your next batch of MD5 hashes, haveibeenpwned.com. What would the criminals do without PHP developers?

I'm afraid you haven't just missed a few years. Your code is ~15 years out of date. MD5 may have been acceptable in the 90s when PCs were relatively slow. Now it's 2016. A single stock PC can easily calculate billions(!) of MD5 hashes per second, which means you might as well store the passwords as plaintext. An attacker doesn't even care about your salts. The only way to keep your passwords relatively secure today is a specialized password hash algorithm like bcrypt. The rest of your code doesn't really look any better: The mysql_* functions are obsolete since more than a decade and have been removed from PHP. Nowadays, we use PDO. You don't seem to escape your query input anywhere, which is a gigantic security risk. Nowadays, we use prepared statements. The whole error handling is broken beyond repair. For some reason you think it's a good idea to display all internal error message to the user, making it easy for an attacker to gain information about your system. Frankly, I doubt that your code can be fixed. Removing all the atrocities in this small snippet alone takes longer than starting from scratch. Mabe you should just write it off as a sin of your youth, learn how to program in the 21st century and start over.

If you want help, you'll have to be a lot more specific and show some effort. Nobody is going to write a step-by-step guide just for you. So what exactly is your problem? What have you tried? AES in PHP is generally a bad choice. When you encrypt files, you should use authenticated encryption which provides both secrecy and integrity (plain encryption still allows an attacker to manipulate your files). AES has the “GCM” mode for that, but it's virtually nonexistent in PHP. A better choice would be ChaCha20-Poly1305 via the libsodium extension.

And that's why I'm answering your questions. No, it's not the best option, because then the password is still accessible to the Internet-facing PHP environment. But if you're running on some limited shared host where you can't create new accounts and cronjobs, this is the best you'll get.

The most secure way is to completely isolate the mail script from your Internet-facing Apache/PHP environment and run it as a cronjob under a separate Unix account. As long as the script is only readable by that account, it's relatively safe to store the plaintext password in it. If this is not an option, store the password in a configuration file outside(!) of the document root and make it reabable only by the Apache/PHP account (e. g. www-data). This isn't as secure as the above option, because a file inclusion vulnerability on your website can expose the password, but it's better than nothing. Either way, do not store the password inside the database. Since SQL injection vulnerabilities are so common, there's a huge risk of attackers simply fetching your “secret” data.

I think he wants to specifically restrict the domain of the addresses. Of course the obvious approach would be to simply split at the “@” sign. Note, however, that you need to split at the rightmost “@”, because this symbol is also allowed as a literal character within the local part. For example, foo\@bar@example.com is a valid address. <?php $address = 'foo@example.com'; $host = substr(strrchr($address, '@'), 1); var_dump( $host ); Alternatively, you could use an actual parser library. There are plenty on GitHub.

I think you're arguing against a statement which nobody made. Of course you can and should limit access to the files, which includes strict policies for employees. But the OP said that he has a website and now wants to prevent himself as well as all developers from accessing the files. This is nonsensical. If the encryption happens server-side, then anybody with sufficient rights (the site owner, admins, high-ranking developers) can subvert it, and it's very important to realize that. My point is: Before you write security-related code, you need to understand what you're protecting from whom. I don't think we're there yet. All I see is “Please give me some PHP magic to throw at the files, maybe it'll help.” “Brute-force the encryption”? What do you mean by that? Modern cryptography with sufficiently long keys cannot be broken by brute-force, which is really the whole point. If yours can be, there's a fundamental problem with your implementation.

No offense, but the stated goal is very naïve and simply impossible. You cannot protect the files and at the same time prevent yourself from breaking that protection – unless you have some kind of split personality. And I hope the serialization stuff was just a joke? Serialization has nothing whatsoever to do with security. So what do you really want? A bit of handwaving to create the illusion of security and maybe scare off a few kids? Or do you want actual security? If you just want to do some handwaving, I'll leave this topic to somebody else. If you want security, you'll need a realistic scenario, actual cryptography and a lot more knowledge than you currently have. In a nutshell, there are two basic scenarios: The users trust you to encrypt their files. This provides maximum usability, but it means that you and anybody with sufficient rights can access the plaintext data at any time. In fact, the users can't even tell if there's any encryption at all. The users encrypt the files themselves before they upload them (e. g. with GnuPG). This provides maximum security and indeed prevents you and your developers from accessing the data, but it's fairly inconvenient and requires a certain level of technical understanding (which the average user may not have). If you go with server-side encryption (the first option), install a good high-level library like libsodium, generate a single random key and store it in some configuration file outside of the document root. Then protect the files with authenticated encryption (this provides both secrecy and integrity). Theoretically, it's also possible to implement password-based encryption where the users “unlock” the files with their own password. But this is very complex and doesn't necessarily increase security, so I'd go with a single server key.