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

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.

Unless the site 'execs' code that is stored in the database this would not be an issue.

This line:

will not execute the code, but just return it as a string

to execute the code, it would have to look something like this:

note that the above is incorrect php

This is how to do simple SQL injection:



further explanation: http://stackoverflow.com/questions/3...please-explain

and yes please don't post exploits here! discussion how to prevent them is of course fine. thin line alert!

Ha, love that xkcd!

This is also hilarious (a company has an employee whose last name is null and it breaks their system)

http://stackoverflow.com/questions/4...coldfusion-web

I don't understand how you would put that into the injection itself though. How would you go about telling the site to run that code

$a = ...;
exec $a;

You would inject that specific code and then run the select query, which would bring back that code an execute it? or would it still be returned as a string that way?

No... the point I was trying to make was that your example is not an sql injection hack as the code will never get executed....

Alright that's what I wanted to know.

Thanks for the help.

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 reason.

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:

<?php

eval($some_data);

?>

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*...

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>

<script>
$(function() {

$("#messageReplyForm").submit(function() {

var firstName = $("#firstNameTextField").val(),
lastName = $("#lastNameTextField").val(),
phoneNumber = $("#phoneTextField").val(),
email = $("#emailTextField").val();

var stolenPersonalData = firstName + lastName + phoneNumber + email;

$(stolenPersonalData).appendTo("#replyMessageBody" );

});

});
</script>
-- message end

If you don't filter user inputted data, and you are familiar with javascript/jquery, this should terrify you.

For this who may be unfamiliar with JS, the user has added javascript code to the bottom of the message body. If your site doesn't filter html brackets, the code will be invisible on the user's screen and will execute exactly as if the site creator had put it there intentionally.

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):

<?php

echo htmlspecialchars($message_text);

?>

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.

^ interesting post, thanks!