Jacques1

Then good luck with your new friends. You're not a programmer and never will be, so this may be hard for you to understand, but programmers are looking for right answers, both in a technical and in an ethical sense. If you share this basic value, you can learn a lot from this community. You're not exactly the brightest bulb judging from your progress in the last 12 years, but I'm sure we can at least help you get to amateur level. If you don't share our values, go away. I'm not interested in stories about “school projects” or “super-isolated lab environments”. I've heard this bullshit far too often.

And the problem you're having is what?

You'll also want to learn how to use the debug tools of your browser (especially the JavaScript console) so that you can find and fix trivial problems like this yourself. Good IDEs like Netbeans or Eclipse can actually check your code as you write it. Saves a lot of time.

You are not learning “PHP6”. There's no such thing. This is 90s technology abused to the point that the application could do anything: crash, spill out sensitive data, compromise the whole system. It's literally malware. Just try entering the name “O'Reilly”. You have not completed the task. You haven't even developed a basic understanding of technology. If you think the code will be accepted, it just demonstrates how worthless this kind of education is.

Like I said, even authentication doesn't help when the same form hands out a CSRF vulnerability for free. The only way to make this halfway sane is to implement solid authentication within the application fix all current vulnerabilities, especially the ones which can be used to take actions on behalf of an authenticated user (CSRF, Clickjacking, ...) only accept references to predefined actions (e. g. “get_uptime” and “get_memory_usage”) create a separate unprivileged account, then create a public-key SSH access which can only execute a single command, namely run a shell script which maps the references to actual commands

The form lets you run arbitary commands without knowing the SSH credentials. The credentials are provided by the application. You just have to send a command of your choice, and then the application makes sure the servers will execute it. I haven't even seen any kind of session handling in any of the scripts posted by the OP in the last months. So chances are there's literally no authentication at all.

You must be kidding. We're talking about unrestricted access to an account on the server. The SSH credentials are provided by the application, which means the client doesn't even have to worry about them. There could be some home-made authentication scheme within the application, but a) we both know it's garbage and b) it can easily be circumvented through a CSRF attack. So the whole Internet has access to those two machines, and who knows what the accounts can do. I wouldn't be surprised if they're root or just one crappy password away from root. Even a standard account is enough to cause enormous damage. Besides that, have you not read the code? He just wants to execute two specific commands, but he's handing out an unrestricted shell. Does that not seem kinda sorta wrong? Guys, please, turn your brains back on. I know this is amateur hour, but let's at least not hurt anybody.

Do you understand that your form allows arbitrary users to issue arbitrary shell commands? And do you understand how dangerous that is?

Whether you prefer to get your results as objects or associative arrays is up to you. But you should set the default fetch mode globally in the PDO constructor rather than repeating the setting over and over again for each query. If you do the check in order to prevent username collisions, then none of the methods is correct. In fact, the whole approach is wrong, because there's a gap between the check and the insertion where another process may take the same name, essentially making the check useless (this is called a time-of-check-to-time-of-use bug). What you need to do is let the database system enforce unique names: Add a UNIQUE constraint to the column, simply insert the name and then check if the constraint has been violated (MySQL has error codes for this).

Why are you taking courses when you don't give a shit about the subject, refuse to learn anything about it and will have no benefits whatsoever? I can understand people who simply keep away from programming. It's not for everybody. But choosing to program when you have no interest in doing anything right is amazingly stupid. If your professor actually teaches that 90s garbage and accepts code which violates even the most basic programming principles, he needs to get fired. Good grief. The entire IT industry is already suffering greatly from clueless code monkeys and horrible code, but the courses of your university seem to actually create those “programmers”. Your code does not work. You don't even know what that means. All it does is look convincing enough to deceive your professor, and that's just sad.

This is what you gave us, honey: http://l.facebook.com/l.php?u=http%3A%2F%2Fchenschool.elementfx.com%2FCS334%2Flab10%2Fcontent.txt&h=FAQH-ZTp1

It would also help a lot if you posted the code here (using code tags) rather than giving us a Facebook link which points to a private page which now points to an empty file.

Dont't do that. Instead of cluttering your markup with non-breaking spaces or hard line breaks, use CSS for styling (as already mentioned by cyberRobot).

Good idea. Now we just have to convince people that the badge isn't the username either.

Well, you have no error checking at all, so it's only natural that you don't get any feedback. The second problem is that your From headers are lies: You send the mail from your server, but you claim it's coming from the user's mail server. Since this technique is commonly used for spam and other malicious purposes, some system won't accept such e-mails. Fix the headers. The From address is always the one which actually sends the mail, and you may add a Reply-To header with the user's address. Third, your code is wide open to mail header injection attacks (and potentially cross-site scripting), because you just dump the raw user input straight into the message structure. This can easily be abused and get your server blacklisted. Long story short: You should get rid of the mail() function altogether and switch to a proper libray like PHPMailer. This will fix many of the mistakes you've made, and it allows you to use an external mail server for testing and as a temporary workaround.

I'm pretty sure he's just trolling.

It amazes me how PHP “programmers” rather spend 3 hours making the same mistake over and over again instead of simply fixing their damn code. I even posted the statement template. No. He just cannot live without his SQL injection vulnerabilities.

I've just given you the solution. All you have to do now is stop complaining and start programming. In case you still haven't understood the problem: When you randomly dump PHP variables into query strings, you not only create vulnerabilities, you also screw up the SQL syntax. This is what happened. You claimed you already know how to properly pass values to queries. Do it then. It's all you need. If you don't know how to do this, look up prepared statements and then the solution for IN lists (note that mysqli is very cumbersome; in the long run, you might want to switch to PDO). Besides that, you definitely need to enable error reporting for mysqli, because you're obviously not willing to check each query manually (which I can understand). The template for the prepared statement is SELECT id FROM fruit WHERE fruit_name IN (?, ?, ...) -- this is where the list items go GROUP BY id HAVING COUNT(1) = ? -- this is where count($fruit_types) goes

Yeah. Maybe you should just stop writing quick and dirty code and do it properly. Then you'll simultaneously solve your injection problems and the PHP issues.

Several things: mysqli is a very cumbersome and counter-intuitive API compared to PDO, so unless you absolutely must use it, just switch to PDO. This is not really how prepared statements in mysqli work. You're supposed to get the result set with mysqli_stmt::bind_result() and mysqli_stmt::fetch(). mysqli_stmt::get_result() depends on a specific MySQL library (mysqlnd) and is not available on all systems. While mysqlnd has become the standard, there are still hosters which choose to deactivate it. Refrain from declaring your topics as “urgent”. It's just annoying.

Just don't. Don't rely on languages to guess what you mean when you juggle with nonsense values, and don't try to produce results from nonsense input. I know this is hard to believe for a PHP programmer, but many languages actually trigger an error when the program does weird things like trying to calculate sums of void values. You should do that too, because it's the most straightforward reaction. If you absolutely must produce a result, then return immediately after validation. No magic.

Have you checked the error log of your webserver? Have you tried an empty or extremely small file? Have you checked the network traffic in your browser?

$Clue_No isn't the same as $Clue_no. PHP variables are case-sensitive. If you get a proper IDE, it will actually point out trivial mistakes like this and save you a lot of time. Also note that your default case will trigger an error when you try to access $result, because there won't be such variable. You should fix your logic. Personally, I would avoid magic numbers and switch statements at all costs, because it quickly turns the code into an unreadable mess.

If a parameter isn't present at all, that's a much more fundamental problem than a blank field, so I would treat that differently and maybe even log it as an error. It probably means there's a defect in your application (it could also come from a broken client, but that's rare). A blank field, on the other hand, is a perfectly normal user error.

The tutorial is garbage from top to bottom. It must have been written ~20 years ago and never updated since. A lot of the functions don't even exist in modern PHP versions. In other words, you'll have to start over in any case -- and I doubt you'll want to rewrite the entire application when it has grown and is already in use. So now is the best time. If you read the above PDO tutorial, use the new password hash API and exercise common sense, your code will be much, much better than any “tutorial” on the Internet.