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"];
}
Related
For example
$var = '10/2';
Is there a way for me to output the value 5 from that easily?
So something like this:
$foo = ($var) + 5;
I want $foo to have a value of 10?
Currently, the best way I know is to explode $var and then divide $var[0] by $var[1]. Is there a quicker way?
Another way of asking; Is there a way to tell the system to treat '10/2' as an equation instead of a string?
Could be you can use a solution like this
$foo = eval('return '.$var +5 .';');
print $foo;
eval require a line of code .. so you could build a valid code line
eval() to either assign in place or return:
eval("\$foo = ($var) + 5;");
$foo = eval("return ($var) + 5;");
First things first, EVAL IS HAZARDOUS AND SHOULD NEVER BE USED UNLESS YOU KNOW WHAT YOU'RE DOING! As an addendum to this, you don't know what you're doing. No matter how experienced you are as a programmer, when it comes to eval just assume you don't know what you're doing. Believe me, in the long run your sanity will thank you.
As for your problem, you're basically asking how to write an equation parser. Writing a full blown one that can handle all cases of valid input (and reliably identify invalid input) is a much bigger job than you might at first think, so if you really do need to parse string equations it may be better to look for a library that will do it for you because the chances are whoever wrote the library thought of a lot of stuff that you didn't, such as handling operator precedence and how parenthesis can modify it, how to pass strings in scientific notation, etc.
One of your comments suggests using PHP Math Parser. I've never personally used it, but I know the author by reputation well enough to believe it's a reliable library.
If your use case is always going to be as simple as your example then you can simply split the string and process the resulting fragments.
$parts = explode ("/", $var);
$foo = $parts[0] / $parts[1];
Netbeans seems to suggest too many assignments is quite bad and should be changed.
i.e.
$foo = ' bar ';
$foo = trim($foo);
Should better coded as
$foo = ' bar ';
$trimmed_foo = trim($foo);
Is this acceptable? If so why? I know I can switch this particular hint type off in setting, but just checking if someone spotted anything for this.
Ths is a new warning, circa mid 2012.
Since you used the trim example I'm guessing that you have read this https://blogs.oracle.com/netbeansphp/entry/several_new_hints, which tries to explain the warning. My take on this warning is that it's trying to warn you about accidental reuse of a variable. As such it is very handy. In the trim case you give it seems a bit heavy handed. If the reassignment is on he following line, it's probably not accidental.
Ideally the variable name should describe the contents. If you are repeatedly assigning to the same variable, it suggests that the variables contents are not well defined.
Additionally, if your code has something like this:
$foo = ' bar ';
// some code, mybe 100 lines of it
// now do something with $foo
What happens if you update the code to add $foo = trim($foo); up above? You break the code below.
Those variants make no difference. If anything the first is better because it avoids cluttering the scope with variables.
I think what the warning really means is that you should try to do
$foo = trim(' bar ');
directly (or whatever $foo is really being set to in the first place), instead of storing it in a temporary. Of course, this isn't always possible.
If you don't like this hint, you can simply deactivate it in Tools -> Options -> Editor -> Hints -> PHP -> Immutable Variables
IMHO, first way is ok for more performance comparing second.
On the other hand, second approach can be more helpful if you need more descriptive variables. Also this may help more if multiple persons are working on same project.
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);
Is escaping eval variables safe enough from security point of view. For e.g.
$path = "a"; //sample value; is generated dynamically
$var = "phpinfo()"; //sample attack value; is generated dynamically
eval("\$struct$path = \$var;");
this seems to be working safely to me. Although there seems to be no reason of using the code in the first place, now that it is in, it cannot be removed without a reason.
Is there any way (any value for $var or $path) that can break this eval or is it that i am simply worrying too much :-) and this is a safe case???
It depends on where $path is coming from.
This value breaks it:
=0;unlink('/important/file');//
I have no clue what your eval code is actually supposed to do. But if it's just about a dynamic varname how about something like that:
extract(array("\$struct$path", "\$var"));
Faster.
You could need eval to implement a plugin system with hooks... But you should never execute dynamic content with it (like phpinfo).
I use this:
function safeClean($n)
{
$n = trim($n);
if(get_magic_quotes_gpc())
{
$n = stripslashes($n);
}
$n = mysql_escape_string($n);
$n = htmlentities($n);
return $n;
}
To prevent any type of MySQL injection or anything like that. Whenever I use it to wrap around $_POST like this:
$username = safeClean($_POST['user']);
$password = md5(safeClean($_POST['password']));
$vpassword = md5(safeClean($_POST['verify']));
$email = safeClean($_POST['email']);
It doesn't even work, but I have attached functions.php and the directory is correct but doesn't work at all because it just shows a blank page... If I remove the safeClean() from each $_POST it works.
How come this isn't working at all?
In my opinion, this sort of general sanitization approach isn't the best way to think about things. For one thing, parameterized queries (probably most convenient using PDO) are a much better way to approach the SQL safety issue. But in general...
I know the developer impulse is to try and reduce the number of things you have to think about. So, naturally, you want to see if you can come up with an all-purpose sanitization function you can just hand all inputs over to and not have to worry any more. Inputs are one arena, though, where if you really want security, you need to think specifically about what each incoming piece of data is supposed to be and where it's going to end up. If you go on auto-pilot here, you will introduce a security issue at some point.
Try using mysql_real_escape_string() rather than mysql_escape_string().
Almost everything in your code is wrong.
get_magic_quotes_gpc is misplaced, htmlentities is misplaced and even term "sanitization" is misused.
As a matter of fact, you shouldn't sanitize anything for the database. But just follow syntax rules.
Take a look at the very similar question, I've explained SQL matters pretty well: In PHP when submitting strings to the database should I take care of illegal characters using htmlspecialchars() or use a regular expression?
And as of the blank page, you have to learn primer of debugging. You have to turn error reporting on to see error messages instead of blank page. To start with it you can refer to this article:
Link to start: http://www.ibm.com/developerworks/library/os-debug/
you can start from adding these lines at the top of your cript
ini_set('display_errors',1);
error_reporting(E_ALL);
and this code to the query execution:
$result = mysql_query($query);
if (!$result) trigger_error(mysql_error());