Jacques1

He doesn't want multiple values for the radio buttons. He has multiple grades, and each grade has a set of radio buttons. The rest is unclear. Besides the fudged up MySQLi code, there seems to be an issue with doubles quotes vs. single quotes: Insert into tblimprovements(id,grade_id,Status_ID,Remarks,Attachment) Values('1','2','3","some remark","some attachment') Maybe that's the issue?

What exactly is your problem? Are you getting an error? An unexpected result? Do you have a specific question? We need to know if you want us to help you. In any case, you definitely need to learn the basics of MySQLi. Your database code makes no sense. When you need to pass PHP values to a query, use a prepared statement. Literally inserting variables into query strings is mostly obsolete and dangerous, because it's easy to forget the escaping (as you can see). Never show SQL errors on the screen (I'm talking about the die(...) stuff). This is extremely confusing for legitimate users, and at the same time it helps attackers gain information about your system. Your users are not your database administrators, so SQL errors are none of their business. Log the error and show a generic error message. Don't use intval(), it has problems. You generally should never change the user input. If you want a specific format, then validate the input accordingly, e. g. with ctype_digit(). MySQLi can actually take care of the error reporting on its on: $mysqli_driver = new mysqli_driver(); $mysqli_driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT If you put this before your database connection code, MySQLi will throw an exception whenever a query fails.

The query is nonsensical and very poorly written, so I'd consider just ignoring it and moving to a better learning resource. In any case, don't adopt this style. The result set isn't even deterministic, because the query groups by the book title and then selects columns which aren't functionally dependend on the title (like the publisher). For example: If two books have the same title but different publishers, who is “the” publisher of the title? This obviously makes no sense, and a properly configured MySQL server will actually throw an error. If you do not get an error, that's because MySQL ignores your mistake and selects any publisher. Nondeterministic results are generally a bad thing when dealing with data. The GROUP BY clause is meant for aggregate functions (like SUM or AVG). Since there are no aggregate functions anywhere in the query, the clause simply doesn't belong there. It's appearently being abused to hide the problem just mentioned. Do not use FaNcY identifiers with both lowercase and uppercase letters. They may be pretty, but they're extremely confusing and error-prone, because different operating systems handle them differently. While I tested the query, I got this wrong all the time. Make your identifiers all-lowercase and separate them with underscores. The database name should be all-lowercase as well. Never, ever use cryptic aliases like “t1” and “t2” (like benanamen already said). Once the query becomes more complex, you'll hate yourself for it. And should you ever work in a team, everybody else will hate you as well. Using comma-separated tables in the FROM clause is obsolete and comes with a lot of limitations. Always use explicit joins like “book JOIN publisher ON book.publisher_code = publisher.publisher_code”. A sanitized version of the query might look like this: SELECT book.code, book.title, book.type, publisher.code, author.last_name, author.first_name FROM book JOIN publisher ON book.publisher_code = publisher.code JOIN wrote ON book.code = wrote.book_code JOIN author ON wrote.author_number = author.number ; This would select all books together with the publisher and the authors. Of course you need to fix your column names before you can actually run the query, but you get the idea.

Don't worry so much. A lot of those tests are supposed to weed out complete morons who cannot write any code at all. Since you clearly don't fall into that category, there's nothing to be afraid of. Even if you do make a mistake somewhere or need a bit longer, it's obvious that you can program. So don't waste your time with stuff like “Fizz Buzz”.

So we agree that our goal is to prevent both server-side and client-side scripts from being executed, right? My point is that MIME sniffing simply doesn't help with that: The PHP handler doesn't care about PNG signatures, it goes by the file extension (and of course it can be explicitly disabled). If the file ends with “.php”, then it will be executed, regardless or whether or not a PNG signature is present. If a file does not end with “.php”, then it will not be executed, regardless of whether or not a PNG signature is present. So the PNG signature is irrelevant. UAs generally don't care about PNG signatures either, they go by the Content-Type header. If a file is declared as an HTML document (or something similar), then any embedded code will be executed, regardless of whether or not a PNG signature is present. If a file is declared as an image, then embedded code will not be executed, regardless of whether or not a PNG signature is present. There are some edge cases like a missing Content-Type header or legacy IEs doing shenigans. But then server-side MIME sniffing still won't help, because the UA may come to an entirely different conclusion (hence the problem of chameleon files). So again the PNG signature is irrelevant. No matter how you look at it, the theoretical benefit of server-side MIME sniffing is extremely low. It really only helps in the following scenario: You've screwed up by not proving a Content-Type header. The client has screwed up by using some IE fossile. The attacker is too dumb to exploit MIME detection weaknesses. In this edge case of an edge case of an edge case, MIME sniffing might actually help, which is why I haven't written it off entirely. But I think we should care more about real solutions to real cases. Hardening the server configuration and getting a subdomain is much more useful than an entire PHP script full of MIME checks.

See the two links above. I'd do this step-by-step: Start with the basics, then move on to databases, and finally learn the specifics of authentication (password hashing, session management etc.). Like I said, we can definitely help you if you have any questions. Unfortunately, there's no shortcut. Sure, there's free PHP code all over the place, but pretty much all of it is crap and won't get you anywhere. You'll only learn wrong practices and maybe even damage your server. Sure, there are complete authentication systems, but they're very complex and not something you can just copy and adjust.

I'd simply check the extension, and if it's valid, generate a random name and append the validated extension: <?php function html_escape($raw_input, $encoding) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_HTML5 | ENT_SUBSTITUTE, $encoding); } // the set of all valid file extensions const VALID_EXTENSIONS = [ 'jpg' => true, 'jpeg' => true, 'png' => true, 'gif' => true, ]; // test data $user_filename = 'foo.jg'; $user_extension = pathinfo($user_filename , PATHINFO_EXTENSION); $normalized_user_extension = strtolower($user_extension); if (array_key_exists($normalized_user_extension, VALID_EXTENSIONS)) { $rand_bytes = openssl_random_pseudo_bytes(16); $real_filename = bin2hex($rand_bytes).'.'.$normalized_user_extension; echo html_escape('The file will be stored as '.$real_filename, 'UTF-8'); } else { echo html_escape('Invalid file extension. Please use one of the following: '.implode(', ', array_keys(VALID_EXTENSIONS)).'.', 'UTF-8'); }

This code is malware. I don't know if the original author was actually evil-minded or just incompetent, but the result is the same: If you upload this to any server, it will take 5 minutes until the first script kiddie breaks in. So throw this crap away and stop copy-pasting stuff you found “somewhere on the Internet”. I mean, you wouldn't run executables you found “somewhere on the Internet”, right? Learn PHP, learn the basics of security and then write your own code. It's not that hard, and I'm sure we can help you with it. But I don't think anybody is willing to resurrect some garbage script from the 90s. Let it rest in peace.

You keep mixing up different security measures. Whether or not you allow a file named “evil.php” has nothing to do with whether or not you perform MIME sniffing. Let's do a real comparison: Option 1: Permitting arbitrary file extensions and arbitrary file content An attacker can upload a file named “evil.php” and execute embedded code. Option 2: Permitting arbitrary file extensions and performing server-side MIME sniffing An attacker can upload a file named “evil.php” and execute embedded code. Option 3: Enforcing an image file extension and permitting arbitrary file content (my approach) An attacker can only upload files like “evil.png” and not execute any embedded code. Option 4: Enforcing an image file extension and performing server-side MIME sniffing (your approach) An attacker can only upload files like “evil.png” and not execute any embedded code. As you can see: The MIME sniffing has absolutely no effect. It's about the other factors (namely the file extension). And, no, embedding code in an image structure is not difficult at all. I already answered that question: I look at the user-provided file extension. Security-wise, both the file extension and the file structure can easily be faked, so one is just as good as the other. And with regard to legitimate users, the file extension tends to be extremely reliable, because a) most people will never mess with it, and b) if they do mess with it, they'll quickly run into problems (at least on Windows which maps extensions to programs). Then store the image as a BLOB in the database, if that makes you feel better.

I already pointed you to an article (see #6) which explains the problem of chamaleon files in great detail and describes several concrete attacks. If you search for “mime sniffing xss”, you'll find plenty of other cases. I can also provide an example file for older IE browsers, if that helps. What you really need to understand is that MIME sniffing is no exact science. Just because getimagesize() thinks that a particular file is an image doesn't mean that all UAs will come to the same conclusion. For example, UAs will also scan for HTML tags, so if they find one, they may very well conclude that your “image” is actually an HTML document. In case you don't provide any additional client-side protection (separate domains, CSP), your user is now vulnerable to XSS attacks. Older versions of Internet Explorer will even override explicit content type declarations provided by the server. So server-side MIME sniffing is, at best, a vague approximation of how the file may be interpreted. It's much more important to explicitly declare the content type, isolate the files on a separate domain and set up CSP. No, I'm not under that impression. As I already said multiple times, MIME sniffing is OK as long as we all agree that it's just a nice bonus feature to detect errors and maybe increase security a tiny bit. But don't claim that getimagesize() will make the file safe for storage, and don't blame the UA when that turns out to be wrong. And one also needs to implement XSS protection specifically for uploads. But it's OK to store as bunch of executables and PDF documents as long as they start with a PNG signature? I mean, I understand where you're coming from. It “feels good” to at least do something with the data. But if you think about it, it's pretty useless. And storing unfiltered data is what we do most of the time. There's no getimagesize() for text input.

I'm saying that this is an output problem, not an input problem. Trying to make files “safe” by running them through getimagesize() is like trying to make text input “safe” by applying one of those silly “sanitization” functions. Both approaches are entirely missing the point. The MIME heuristics make even less sense, because they merely check the presence of some magic bytes. That doesn't prevent anything. You might as well force the user to click a checkbox saying “I hereby promise that my file isn't malicious.” How does that help anybody? It's just a useless bureaucratic rule. So the input part is more or less irrelevant. I usually determine the file type by the original extension. Since most people still use Windows which is very picky about extensions, that works reasonably well. If the extension is missing, I might use MIME sniffing as a fallback. What's important is the output part: Isolating the files on a separate (sub-)domain, using Content Security Policy etc. I'm talking about client-side code (JavaScript, JScript, whatever).

Unfortunately, attackers don't always adhere to our definitions. Maybe we can sue them for violating The Divine Law Of PNG. Yeah, let's remove all this silly HTML-escaping from our applications, because if the user executes embedded code, that's definitely their fault. That's not our department. Being safe for viewers is the whole friggin' point of a website. Covering your own ass (meaning: the server) isn't quite enough. It. doesn't. matter. Use the filename, use your beloved MIME heuristics, flip a coin, it doesn't matter.

I repeat: You cannot tell if a file “is an image”. What does that even mean? Is a PHP script an image if only it starts with a PNG signature? Is it an image if I put the code into a bunch of PNG chunks? Your personal definition of an image is completely irrelevant. The question is: How does it get interpreted? And that's a lot more complex than doing a bit of PHP MIME detection magic. As I've already said, I'm not against MIME heuristics. They can catch obvious user errors, and they may increase security a tiny bit. But that's really just a bonus feature. All other measures I've mentioned are much, much more important. Either way: Claiming that a file is safe if only it has passed the getimagesize() check is definitely wrong.

No, no, no. First of all, do not copy-and-paste code from w3schools, not even as an example. I feel slighly insulted that you actually wanted us to debug that crap. In fact, do not copy-and-paste any code from any website. 99% of it is absolute garbage and will turn your server into a playground for script kiddies. Secondly, forget about strip_tags(). It's a shame that this function even exists in PHP, because it's complete nonsense. All it does is mangle the input and leave you with broken data. Third, forget about assembling your own extension check with strpos(). Thousands of people have tried it before you, and they've all failed miserably. As I've already said above, you need to choose the extension. Don't allow the user to do it.

No, it's not. You're assuming that the webserver will determine the MIME type of a file by scanning the content, but that's generally not the case. Many webservers only check the extension, so a file called “foo.php” will in fact be treated as a PHP script, even if its structure happens to resemble an image. You're also assuming that all MIME detection heuristics are the same, but they're vastly different. There's an entire class of attacks which consists of assembling “chameleon files” to exploit those differences. For example, the server may interpret a particular file as an image, but a UA may interpret the exact same file as an HTML document. So, no, checking the file with getimagesize() doesn't do much. I'm not against it, but it's one of the less important security measures.

Just because Web Sockets haven't been formally standardized yet doesn't mean you cannot use them. The only problem would be legacy browsers. However, I'd still stick to your current approach (polling). Sure, it's not super-efficient, but who cares when you clearly aren't running a big professional website? Making a request every few seconds is perfectly fine.

So this project is just for fun, right? The data isn't really important, is it? Because if the data is important, stop it. You do in fact have to be an expert to protect critical data. Broken cryptography isn't worth anything; it's actually worse than nothing, because people will assume that their data is safe when it's not. But even if this is a fun project, a lot of this doesn't even make sense. What does the key have to do with UTF-8 encoding? The key is not a password! It must be a sequence of exactly 32 bytes (for AES-256) or 16 bytes (for AES-128) obtained from a cryptographically secure random number generator (e. g. /dev/random on Unix machines).

No, it doesn't. Just because a file is formally an image doesn't mean it's free of any malicious code. For example, the PNG format allows arbitrary text comments within an image. So it's perfectly possible to craft a file which behaves like an image, even looks like an image but immediately turns into malware as soon as the webserver executes it. There is no image/non-image duality. A file can be both, depending on the context.

You're inserting the original data instead of the filtered data. But like you already said yourself: This code desparately needs an update. Blocking less-than signs as a “security measure” may have been acceptable in the 90s, but nowadays people are used to professional software which doesn't choke on a simple input character.

That's a bit strange, but there's no rule saying that WP malware can only infect WP-based applications. Anyway, all of the above still applies. If you've written the code yourself, replace “Update your application” with “Learn the basics of PHP security and fix your code accordingly”.

This is not fine. While you're at least doing some basic checks, this code is still extremely insecure. To name just a few problems: You happily accept multiple extensions as long as the last extension is an image extension. So anybody can upload a file named “malicious.php.jpg” with embedded PHP code, and chances are your webserver will actually execute it. You let the user choose an arbitrary filename, and that name is then reserved forever. This is obviously a problem, because common names will be taken after a short while. It's even possible to create hidden files by simply uploading a file without a name (e. g. “.jpg”). You cannot use file_exists() in a web application where many processes may run in parallel. If two processes request the same unreserved name at (almost) the same time, then file_exists() returns true in both processes. So one of the uploads will later be overwritten by the other. Implementing a secure and robust file upload is a lot harder than it may seem. I strongly recommend that you read up on common risks before you jump to the implementation. Basic security requires at least the following steps: You must choose the filename while making sure that no two processes will ever get the same name. If the username is already unique and every user can only have single avatar, you might simply choose the username. Another typical solution is to use a random number generator like openssl_random_pseudo_bytes() to create unique names. If possible, store the uploads outside of the document root and make them accessible through a PHP script. This will prevent a lot of security problems. For example, you can explicitly set the right Content-Type without relying on the webserver to figure it out (so you don't even need a file extension). There's also a much smaller risk of malicious server-side code being executed. If you do put the uploaded files directly into the document root, extra care must be taken. You need to choose the file extension, and you must explicitly disable script execution in the upload directory. Use Content Security Policy to prevent execution of client-side scripts. For example, the header Content-Security-Policy: default-src 'none'; sandbox will block any JavaScript code that may be embedded in the file.

$con is not an object. It doesn't have a query() method (or any other method).

Why are you checking $con->query()? There is no $con variable anywhere in your code. Did you copy-and-paste this error check from somebody else? At best, you'd check $i. That's your query result. If it's false, then there's an error.

No doubt about that. So in case my previous reply wasn't clear enough: Both the server configuration and Wordpress need to be fixed. This includes all plug-ins, because a lot of vulnerabilities are in fact introduced through poorly written third-party additions.

You need to fix the logic of your code. Right now, you fetch the first row (which may not even exist) and extract the item title and username. Then you iterate over the remaining rows, but you just keep echoing the title and username of the first row. Get rid of the extra code for the first row and extract the title and name for each row within the loop.