Leaderboard
Popular Content
Showing content with the highest reputation on 09/01/2020 in all areas
-
the username is a value that originally came from external submitted data. depending on your registration code's validation logic, it could contain anything, such as a hexadecimal encoded string, consisting of just letters and numbers (a hexadecimal encoded string, in a non-string context, will be decoded into whatever string it actually contains), or it could contain single-quotes, that if put directly into an sql query will allow sql injection. it sounds like you think that using a prepared query ONCE, when the data was first submitted and stored makes the value safe to use in all future queries. it does not. it only made that first query safe. any value that ever came from external, unknown, or dynamic data (recently, a year ago, or a year from now, when your application gets updated to get usernames via a call to an external api, where you don't know what type of characters it might contain) must treat the value as unsafe in whatever context the value is being used in (sql, html/css/javascript, email header, filename, system/shell, ...)1 point
-
It's not just about user input. It's about not knowing right there at that moment whether the value is safe. Can you guarantee that there is no possible way a username could have anything wrong with it? Not just in the database but also the value stored in the session? Modern day "hacks" are not about finding a single problem that gives someone complete access. They're about finding a series of small vulnerabilities that combine to form something large. In your case, perhaps there's a way to get a username that's kinda invalid into the database, and then maybe there's a flaw in some code that loads the username into the session, and then maybe there's a flaw in this particular script where the bad username in the session can turn into SQL injection. That's why application security is so difficult: to protect yourself you have to make sure that everything is covered, but for a malicious user all they have to do is find one or two problems.1 point
-
You're putting the entire table in there. The only thing you need you need to repeat is the data row (that being the second <tr> and what's inside it). You'll also have a bit of a problem with where your code is. The loop is before your <html> so you can't put the table row in there. Instead you need to move the loop itself. That also means moving the mysqli_close, since you can't very well read the query results once you've closed the connection. The good news is that you don't need to close the connection in the first place. PHP will do it for you when the script ends.1 point
-
your table header also has an extra <th> before user name1 point
-
That's true, as far as I can tell what you're talking about. But that loop you have only uses some variables. Every time through the loop it updates those same five variables to have five new values. By the time the loop ends, all you have left is whatever the five latest values were - everything that happened before is lost. You've got a loop that can go through all the results. You've got some HTML for a table row. Instead of using the loop for some variables, use the loop for the table row.1 point
This leaderboard is set to New York/GMT-04:00