I'm doing something where I need to store if statements in a mysql database. I need to pull these statements and use them, each one is an algorithm that I'm testing. I know you can store an if statement in a variable like "$abc = $x > 1 && $f == 1;" and if you run if($abc) {} it will work, I figured I could do the same here, but when I run if($abc) with $abc being an if statement from the database it's not working, it's running the code within the if statement because $abc exists. Code is as follows...
$getAlgorithms = mysqli_query($mysql_connect, "SELECT * FROM `algorithms2`");
while($algorithms = mysqli_fetch_array($getAlgorithms)) {
$algorithmID = $algorithms['id'];
$algorithm = $algorithms['algorithm'];
if($algorithm) {
echo("HELLO WORLD");
}
}
dummy example of what $algorithms['algorithm']; would pull: $r >= $var_x && $z <= $var_y && $lz >= $var_c
I'd really appreciate the help, this is very important. If you have any questions please ask.
NOTE: This is a 100% internal platform
Your code needs to make use of eval() to work as-is:
$getAlgorithms = mysqli_query($mysql_connect, "SELECT * FROM `algorithms2`");
while($algorithms = mysqli_fetch_array($getAlgorithms)) {
$algorithmID = $algorithms['id'];
$algorithm = $algorithms['algorithm'];
if(eval("return {$algorithm};")) {
echo("HELLO WORLD");
}
}
However, executing arbitrary code from an external source (the database) is potentially a horrible security risk: just because you're expecting $algorithm to be a benign arithmetic expression doesn't mean that it can't be a malicious function call or other statement, for example if someone can enter system('rm -rf /') as the algorithm into your database, you're probably going to have a bad day.
Without knowing the precise problem you're trying to solve, it's hard to suggest a better solution, but I'd favour putting the "algorithms" in an array or other hard-coded data-structure within your code rather than the database, it's far safer as anyone who can alter that list can already execute arbitrary code.
For further reference: http://php.net/manual/en/function.eval.php
Sounds like you're looking for eval(), but note that it is especially dangerous to use if there's any chance someone besides you will be creating the strings. There is probably a better, safer way to achieve whatever it is you are trying to do here.
Store the If condion in your db as string. And then execute it using eval() php function .
usage
mixed eval ( string $code )
PHP eval documentation
Related
I've gotten into the habit of writing the following sort of code:
$q = mysqli_query($mysqli,"SELECT * FROM table WHERE a='$a', b=$b;");
while ($row = mysqli_fetch_array($q)) {
// do something
}
Where $a is a string entered by the user (gotten through $_GET) and $b is a user-entered integer.
Obviously the code I have above is vulnerable to SQL injection attacks, so my habit is to rewrite it like this:
$q = mysqli_query($mysqli,"SELECT * FROM table WHERE a='".str_replace("'","",$a)."', b=".($b+0).";");
But this of course has problems if $a needs to have apostrophes (or quotation marks when quotation marks are used to mark the string).
Recently I learned about prepared statements in mysqli and started playing around with them. I wrote the following function to make it easier to make calls without having to change much of my code:
function safequery($a,$b,$c) {
global $mysqli;
$q = mysqli_prepare($mysqli,$a);
$e = "mysqli_stmt_bind_param(\$q,\$b";
$i = 0;
while ($i < count($c)) {
$e.=",";
$e.="\$c[$i]";
$i++;
}
$e.=");";
eval($e);
mysqli_stmt_execute($q);
return $q;
}
safequery("SELECT * FROM table WHERE a=? AND b=?;","si",array("unsafestring",37));
But what is returned from this function turns out not to be a mysqli_result and thus doesn't work with the first bit of code above. After some more research, I found an alternative, but it would require a complete rethink of how I write my code. Is this necessary or is it possible to protect against MySQL injection attacks with only small changes to the first bit of code (no new lines, same output style, etc.)?
I have looked around on StackOverflow and the rest of the web but I can't find a good simple solution; all of them require the edition of at least three more lines for every call and a different way of reading each row. I'd prefer to do this procedural-y...
Don't think half-measures are going to solve this problem. Commit to expunging all of the interpolation bugs from your code and be disciplined about using prepared statements. Your proposed fix only makes things worse, it gives you a false sense of security. It's also considerably more work than using prepared statements so I'm not sure why you'd even bother doing it this way.
One way to make this a lot easier to do is switch from using double quotes " to single quotes ' on your queries to disable interpolation. Any escaping errors become syntax problems, and if your editor highlights those you'll be able to spot them from across the room, and if something does by fluke work you'll be inserting harmless things like $a instead of actual data.
Another thing to consider is if you should be using an ORM like Doctrine or Propel given what you know about the sophistication of your application. These can make things considerably easier from an implementation perspective.
The code you have there is a ticking time bomb, get rid of it as soon as you can. Don't think replacing quotes is enough, that solves just one issue, there's actually a number of other methods your application can be vulnerable to injection bugs. Tools like SQLMap have an entire arsenal of things they can try to break your code and if you look at the list of things it can do if it finds a flaw you'll probably want to fix these problems right away.
One way you can find issues is using a tool like grep:
grep query `find -name '*.php'` | grep '\$'
That's not bulletproof, but it should probably turn up a lot of code you should fix right away.
Also as #ceejayoz suggests, purge that function with eval in it from your computer and never, ever do that again.
After talking with the commenters and looking at some of the other questions and things they linked to and suggested, I've rewritten the third code snippet to both solve the problem in question and fix the security holes that several commenters pointed out (if there are any remaining ones, please tell me).
First on my use of eval(). Though I can't see any immediate way it could cause problems (user strings are not executed as code in the eval()) it is certainly a round about and stupid way of solving my problem. #TadMan suggested call_user_func_array() which, once worked out, looks something like this:
function refValues($arr){
if (strnatcmp(phpversion(),'5.3') >= 0) //Reference is required for PHP 5.3+
{
$refs = array();
foreach($arr as $key => $value)
$refs[$key] = &$arr[$key];
return $refs;
}
return $arr;
}
function safequery($a,$b,$c) {
global $mysqli;
$q = mysqli_prepare($mysqli,$a);
call_user_func_array("mysqli_stmt_bind_param",refValues(array_merge(array($q,$b),$c)));
mysqli_stmt_execute($q);
return $q;
}
safequery("SELECT * FROM table WHERE a=? AND b=?;","si",array("unsafestring",37));
It turns out that mysqli_stmt_bind_param() takes only references, thus the new refValues() function (run into and solved before on StackOverflow: https://stackoverflow.com/a/16120923/5931472).
While this removes eval() and makes my code easier to understand, it still doesn't solve the original problem of returning the query response in a way that mysqli_fetch_array() can use. It turns out that the proper function to do this is mysqli_stmt_get_result() so the last line of safequery() is rewritten from:
return $q;
To:
return mysqli_stmt_get_result($q);
The result of safequery() is then a mysqli_result which can be used by mysqli_fetch_array().
I have code that looks like:
$id = (int) $_REQUEST['edit_id'];
$result = mysql_query("SELECT * FROM dis WHERE dis_id = $id ");
Can anyone do SQL injection in this code like I am using (int) to filter the raw data? If so, how can it be hacked and how can the hack be prevented?
This on itself won't hurt and this specific case will not lead to SQL injection.
However, teach yourself to always use prepared statements, to train your muscle memory and not take "shortcuts".
There’s nothing wrong with it, assuming there’s no way way to break the int filter. However, things break all the time (in this case there’s little to worry about). But I agree with the previous answer: use prepared statements so sanitization/validation is built in.
I usually don’t trust a single layer of security when I can make sure my data is sanitized/validated with a line or 2. I made a trait that checks for expected input, and reuse it from project to project if I’m patching something without prepared statements.
I usually create a bunch of custom php sanitisation scripts for my applications to sanitise incoming data and run these against the data just for peace of mind. For example...
function SanitiseIntegerData($data) {
if ( preg_match("/[^\d]/", $data ) == TRUE ) { //If data contains characters apart from integers
echo("ERROR: Invalid GET data");
$_SESSION = array();
session_destroy();
session_unset();
echo "<script>window.location='index.php'</script>";
}else{
return $data;
}
}
I haven't found this question on here yet, and I have done some quick Google research on this but I couldn't really find a clear or good answer to this question.
Is it possible to inject a piece of php code in an input field. that would actually work.
//for instance.
//Ill fill in '"test()"' in the field.
<input type="text" name="input" value="'"test()"'">
$injection = $_POST/*(or $_GET)*/['input']; // coming from the input
public function test(){
echo "injection successful";
}
So is this possible?
It is possible, but not like that. If you do what you do in your script, then the code would just be assigned as-is (as a string) to the variable $injection.
You can however execute it like this:
$injection = $_POST/*(or $_GET)*/['input'];
eval($injection);
There are other ways as well, but all have the same issue: you must actually evaluate the string as code to execute it. eval is the most obvious solution for that.
But be very careful when you implement this! If you open such a form for the outside world, everybody can execute any script, including ones that might destroy your server or steal your passwords.
The snippet you posted is harmless, but depending on what you do with user-supplied data, it can be used in an code-injection attack. The linked wiki has some examples, here's a couple of them:
$posted = $_POST['user_input'];
eval($posted);//<--- NEVER DO THIS
However, after 10 years, I've never ever even gotten close to the point where I had to even worry about dreaming of having to maybe go down this route.
Another, slightly less unlikely possible vulnerability is impropper escaping when passing user-data to exec:
$cmdArgument = $_POST['flag'];
exec('ls '.$cmdArgument, $return, $status);
Could leave you vulnerable if I passed this as a "flag" value:
-lta && /usr/bin/env php -r 'echo __DIR__;'
And use that input to start messing around with your file-system.
To protect agains this, use the escapeshellarg and escapeshellcmd functions to sanitize the input.
More common, equally dangerous, but easier to overlook, would be this:
$requested = $_GET['page'];
require $requested.'.php';
Instead, if you want to require scripts like this, a safer, and just as easy approach is this:
switch ($_GET['page'])
{
case 'admin':
require 'admin.php';
break;
case 'user':
require 'user.php';
break;
default:
require 'error.php';
break;
}
The PHP exec command can execute code posted to the server. Otherwise PHP code written in a text box will not be interpereted as PHP but just as a normal string.
I know some people may just respond "never" as long as there's user input. But suppose I have something like this:
$version = $_REQUEST['version'];
$test = 'return $version > 3;';
$success = eval($test);
This is obviously a simplified case, but is there anything that a user can input as version to get this to do something malicious? If I restrict the type of strings that $test can take on to comparing the value of certain variables to other variables, is there any way anybody can see to exploit that?
Edit
I've tried running the following script on the server and nothing happens:
<?php
$version = "exec('mkdir test') + 4";
$teststr = '$version > 3;';
$result = eval('return ' . $teststr);
var_dump($result);
?>
all I get is bool(false). No new directory is created. If I have a line that actually calls exec('mkdir test') before that, it actually does create the directory. It seems to be working correctly, in that it's just comparing a string converted to a number to another number and finding out the result is false.
Ohhhh boy!
$version = "exec('rm-rf/...') + 4"; // Return 4 so the return value is "true"
// after all, we're gentlemen!
$test = "return $version > 3";
eval($test);
:)
You would have to do at least a filter_var() or is_numeric() on the input value in this case.
By the way, the way you use eval (assigning its result to $success) doesn't work in PHP. You would have to put the assignment into the eval()ed string.
If you do this. Only accept ints.
If you must accept strings, don't.
If you still think you must. Don't!
And lastly, if you still, after that, think you need strings. JUST DON'T!
yes, anything. I would use $version = (int)$_REQUEST['version']; to validate the data.
You need to be more precise with your definitions of "malicious" or "safe". Consider for example
exec("rm -rf /");
echo "enlarge your rolex!";
while(true) echo "*";
all three snippets are "malicious" from the common sense point of view, however technically they are totally different. Protection techniques that may apply to #1, won't work with other two and vice versa.
The way to make this safe would be to ensure that $version is a number BEFORE you try to eval.
Use this code to remove everything except numbers (0-9): preg_replace('/[^0-9]+/', '', $version);
I found this line of code in the Virtuemart plugin for Joomla on line 2136 in administrator/components/com_virtuemart/classes/ps_product.php
eval ("\$text_including_tax = \"$text_including_tax\";");
Scrap my previous answer.
The reason this eval() is here is shown in the php eval docs
This is what's happening:
$text_including_tax = '$tax ...';
...
$tax = 10;
...
eval ("\$text_including_tax = \"$text_including_tax\";");
At the end of this $text_including_tax is equal to:
"10 ..."
The single quotes prevents $tax being included in the original definition of the string. By using eval() it forces it to re-evaluate the string and include the value for $tax in the string.
I'm not a fan of this particular method, but it is correct. An alternative could be to use sprintf()
This code seems to be a bad way of forcing $text_including_tax to be a string.
The reason it is bad is because if $text_including_tax can contain data entered by a user it is possible for them to execute arbitrary code.
For example if $text_include_tax was set to equal:
"\"; readfile('/etc/passwd'); $_dummy = \"";
The eval would become:
eval("$text_include_tax = \"\"; readfile('/etc/passwd'); $_dummy =\"\";");
Giving the malicious user a dump of the passwd file.
A more correct method for doing this would be to cast the variable to string:
$text_include_tax = (string) $text_include_tax;
or even just:
$text_include_tax = "$text_include_tax";
If the data $text_include_tax is only an internal variable or contains already validated content there isn't a security risk. But it's still a bad way to convert a variable to a string because there are more obvious and safer ways to do it.
I'm guessing that it's a funky way of forcing $text_including_tax to be a string and not a number.
Perhaps it's an attempt to cast the variable as a string? Just a guess.
You will need the eval to get the tax rate into the output. Just moved this to a new server and for some reason this line caused a server error. As a quick fix, I changed it to:
//eval ("\$text_including_tax = \"$text_including_tax\";");
$text_including_tax = str_replace('$tax', $tax, $text_including_tax);
It is evaluating the string as PHP code.
But it seems to be making a variable equal itself? Weird.
As others have pointed out, it's code written by someone who doesn't know what on earth they're doing.
I also had a quick browse of the code to find a total lack of text escaping when putting HTML/URIs/etc. together. There are probably many injection holes to be found here in addition to the eval issues, if you can be bothered to audit it properly.
I would not want this code running on my server.
I've looked through that codebase before. It's some of the worst PHP I have seen.
I imagine you'd do that kind of thing to cover up mistakes you made somewhere else.
No, it's doing this:
Say $text_including_tax = "flat". This code evaluates the line:
$flat = "flat";
It isn't necessarily good, but I did use a technique like this once to suck all the MySQL variables in an array like this:
while ($row = mysql_fetch_assoc($result)) {
$var = $row["Variable_name"];
$$var = $row["Value"];
}