Originally Posted by jalexand42
If you can execute code, why in the world would you insert things just to select them back out. :P
Plenty of other resources for learning about injection attacks and prevention, not really interested in having a discussion for how to execute injection attacks in this forum. Discussion for proper code to prevent them is certainly welcome.
I would argue that educating coders about how attacks are used against them is precisely the way to discuss how to take measures to defend against those attacks.
Also, the line of reasoning that you teased OP with in your first statement is the exact reason that data breaches occur. The exact
Originally Posted by constarr
I was thinking and this came to mind, is something like this possible on a vulnerable site:
manage to inject a piece of code into the database, a piece of php code,
ex (Insert "<?php code; ?> into random_table) then use another sql command to access
that code and run it (select * from random_rable where column="<php? code; ?>")
I don't know too much about sql and injection in general and such but was wondering if something like this were plausable or if there isn't a way to take code out of a table to execute it.
Assuming the table has a long enough varchar to hold your code.
For hacking purposes: It would be used to upload code that downloads a remote file that would give you access to the server.
This is all theory and I have no intention of hacking anyone, lol. Just interested in website security and thinking about a career in it and this idea popped into my head
Despite the dismissive responses some have given, this is an outstanding question.
The posters were correct that it isn't technically an SQL injection, but it illustrates a couple of very important points about coding habits and filtering user inputted data.
First, this code absolutely could be executed by PHP with an eval() injection. For example, if $some_data contains a string from the database that contains PHP code, this will execute it:
This type of attack suddenly becomes more of a concern if you have passthru(), exec(), or system() enabled, which allow PHP to execute commands directly on the machine. Your question perfectly illustrates several important take aways:
1. Always, always, always filter user input.
2. The principle of least privilege -- configure your server settings to allow only the minimal privileges necessary to accomplish the task. If you don't need passthru() -- and you likely don't -- disable. (note: system access commands are probably disabled by default, but check anyway).
3. eval() is very dangerous if used incorrectly. There is almost always a safer method of accomplishing the same thing.
Of these, the first is probably the most significant because the second two nearly always rely on its failure. Moreover, the attacks resulting from failure to filter data vary greatly. For example, cross site scripting (XSS). This is where an attacker places malicious code in someone else's site.
Imagine you're running an online dating site that allows users to send messages to one another. Messages are stored in an SQL table. When a user clicks on it, the message is retrieved from the database and displayed on the user's screen in html. Now suppose that a user has poked around your site with Firebug and gathered the ids/classes of your html elements, and then decides to send a message to another user:
-- message start
Hi, I just wanted to send you a message and say...*whatever creepy stalkers say to their victims*...
var firstName = $("#firstNameTextField").val(),
lastName = $("#lastNameTextField").val(),
phoneNumber = $("#phoneTextField").val(),
email = $("#emailTextField").val();
var stolenPersonalData = firstName + lastName + phoneNumber + email;
-- message end
Here, the malicious user is using the Google API to load the jQuery library (if you aren't already using it), grabbing the victim's personal data from html elements present in the DOM, and then tacking them onto the end of the user's reply message when they hit send. If the victim does reply, the malicious user will get all of the victim's personal data delivered right to their inbox.
Fortunately, this is easy to defend against. In PHP, all you need to do is use the htmlspecialchars() function to filter data when it's being displayed on the screen (not before you enter it in the database):
This will replace all html brackets with their character entities so the browser displays it on the screen (like above) and won't interpret it as code. As simple as this solution is, XSS attacks occur constantly. They can take many different forms, but as long as you follow one rule, you'll be safe(r) -- always filter user inputted data, without exception.
As an aside, although no one has told me, I strongly suspect that the recent security concerns on this forum were a result of something along those lines.
Final note -- I applaud you for asking this sort of question, and you shouldn't feel at all compelled to defend yourself and point out that you're not planning to attack someone. Unless you truly understand how vulnerabilities can be exploited against you, you'll never be safe against them.