Help please it does not work..

[ajfmrf]

Again I have found a second free keno game that won't work.

Can anyone help explain the issue here:

web-user.info/games/keno/B/keno.html
web-user.info/games/keno/B/keno.js
web-user.info/games/keno/B/Read_First.txt
web-user.info/games/keno/B/playkeno.php
web-user.info/games/keno/B/playkeno.txt

Is this the same as the other one."Your server has got register globals off".You have to turn them on to get it to work?

The other script needed that done but my host said it would be a security risk

Bud

[jscheuer1]

It could be. I'm not sure under which circumstances or if that game program would be safe or not. See:

http://www.php.net/manual/en/security.globals.php

for information on Register Globals.

You could get another host, many - or at least some come with Register Globals on by default.

[ajfmrf]

John,I have been search like a nut and found two I like but it appears that they both require me to use the 'register globals' to be on and I am not willing to do that.

Any suggestions-know where I might find one-lol

Thanks,again John

[djr33]

Register globals is a setting that takes the contents of several standard arrays of information and makes them into real variables.

It's possible to imitate this (if a little awkward) by doing it manually.

Loop through each of the arrays and create a new variable by that name. It's something like this:


$arrays = array('_GET','_POST','_COOKIE');
foreach($arrays as $array) {
foreach($$array as $varname=>$varvalue) {
$$varname = $varvalue;
}
}
If you want to use this, put it at the very beginning of everything. That will simulate register globals, which runs before anything else.

I'm not recommending this necessarily. It IS a security risk. But if that's what the (bad) coding of the script you want to use requires, there's no easy way around it.

It's not necessarily just cookie, post and get. And I'm not sure what order they are supposed to go in. Technically there's an order for this so that if you have, for example, a variable with the same name in GET and POST, then one or the other will be stored second, causing the other to be over-written. You can look that up if it matters.

Secondly, this script may only require a certain subset of the above values. For example, maybe you only need POST.


Additionally, $_REQUEST includes all of those combined. So you could just use this:

foreach($_REQUEST as $varname=>$varvalue) {
$$varname = $varvalue;
}
I'm not sure if there's any difference. Maybe that's better because it's simpler.


Finally, if you can track down the individual values it requires (the actual variables it uses) then you can "fix" the script by ONLY globalizing those values. It's safer than globalizing all of them.


Here's the reason for it not being safe:
Let's say you have a variable called "$admin" where a value of 1 means the user is an admin. If you have register globals on (or this fake version of it), then if the user submit a url ending with ?admin=1 then that value from the GET array will become the new value for the real variable $admin and bypass your security.
A well written script should still in theory be protected from this, but it's very easy to forget something.


Finally, another way to do this safely would be the following:
Create a local context within a function. Then "globalize" the variables there-- using the functions I gave above. They won't actually be global-- they'll be local, but they will be available as those names ($variable, rather than $_GET['variable']). That should work for your script. Just remember that you'll need to run your script within the function.
This will be a dummy function. It will look like this:

function dummyfunction(){
//place ALL of your code here that is for THIS script.
//keep any security code, system configuration stuff, etc., outside the scope of this function (the normal way) and it will be safe from register globals interference
}
dummyfunction();

[traq]

if there's a notice about "register_globals," then the script is probably performing a check for that specific setting, so making a workaround might not make any difference.

[jscheuer1]

Ah, but if a workaround is achieved, that check could be removed.

[djr33]

That's true. You can check specifically whether register_globals (the configuration setting) is on. But finding where it checks and removing that is probably possible. Of course without that error you will need to be sure you've properly replaced it, since it will not work and it won't give you many helpful errors. (It might give you "$x is not set" type errors, and those could help.)

[ajfmrf]

There is nothing like 'being in over your head' as I am here,right now.

Thanks for all of the responses to my post.

How ever I don't know enough about what you are talking about to take anything to the next step.

I am sorry to have asked for help that I can not put to good use due to my inability to undestand what you are talking about.

Please accept my apology.

Bud

'clueless'

[jscheuer1]

That's true. You can check specifically whether register_globals (the configuration setting) is on. But finding where it checks and removing that is probably possible. Of course without that error you will need to be sure you've properly replaced it, since it will not work and it won't give you many helpful errors. (It might give you "$x is not set" type errors, and those could help.)

If you have the raw PHP code, you could just do a search for:

register_globals

You might get lucky.

[djr33]

Bud, I understand that this is confusing, but I think you can figure it out if you take it slowly.

First, integrating this with an existing script might be hard, but if you are just using this as an independent script, it will probably be fine.

The first change you should make is the following. Add this code to the top of your page where you include the other pages:

foreach($_REQUEST as $varname=>$varvalue) {
$$varname = $varvalue;
}

Then see if it works.

If it does not, then search through as John just described and try to find where it checks for register_globals-- then try to remove that line. If you need help at that point, post the code that checks it. An easy way to disable it (without messing with anything else) is the following:

Take any if statement:
if ($variable==TRUE) {

Then add a condition that will always be true:
if ($variable==TRUE || 1==1) {

That way you avoid changing the code, but it also will never be false.

[traq]

-- then try to remove that line.

a better way to "remove" a line of code is to comment it out - that way, the code is ignored, but you can still restore it easily if it turns out you needed it.
$example = "I like this code";

// $bad = "I think this line is a problem";

// <-- the two slashes make a one-line comment: everything after them (on the same line) is ignored by PHP.

/*
this is another way to make a comment.
the slash-and-star starts the comment,
and the star-and-slash ends it.
this is also useful in cases like below,
where you want to keep most of the code and only change one part:
*/

$variable = /*"bad value";*/ "good value";

[djr33]

Yes, I agree. I meant "remove" in a casual sense. Of course as a final step actually deleting it is fine if you're sure after testing that it works-- but save a backup. My suggestion was to just leave everything as is in case you're not sure what to comment out, and just find the single if statement that checks for register_globals, and maybe that always true (see my last post). Commenting it out is fine as well-- just make sure you disable a symmetrical part of the code-- eg, the same number of open { brackets and close } brackets, or you'll get a parse error.

[ajfmrf]

Wow,that worked for the first one I found,not the one I posted here in this thread.

Here I was not able to find any php in any of the files even the one with the php extension

But the first one I was told by the people that published it that the globals needed to be turned on.I asked my host if it was okay to do this before I added the file that xavermedia told me to add.

I was told it would pose a possible security issue.

I went back to the forum and posted what I was told and the removed the post and now I can do nothing.I can't get links to work at the forum or do anything but my profile.

xaviermedia.com/php/keno.phtml

Thanks for the help-I am soooooo happy to get the game working :)

[traq]

register_globals (http://us3.php.net/manual/en/security.globals.php) really is a security risk, especially for newer coders or those who didn't learn to code with strongly-typed languages (PHP is a "loosely typed" language, meaning you aren't required to define a variable's type before using it or giving it a value).

at best, register_globals can cause hard-to-track problems by allowing input from many different sources to create and/or overwrite variables. at worst, -since variables from html forms and query strings are among those "registered"- users can take control of your scripts by inserting values. example:

Warning:
This feature [register_globals] has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.
<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
$authorized = true;
}

// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>

[jscheuer1]

Wow,that worked for the first one I found,not the one I posted here in this thread.

Thanks for the help-I am soooooo happy to get the game working

Great!

I had a little trouble finding it on your site, but I did. Looks good!

[djr33]

What traq said is very important.

Generally, it's possible to avoid that if you always give your variables a default value. Since register_globals is set before everything else, your default value (even at the beginning of your script) will be applied after that and reset the value from whatever was "globally registered" from the input.

So fixing the code in traq's post:

<?php
$authorized = false; //DEFAULT VALUE, IMPORTANT!
if (authenticated_user()) {
$authorized = true;
}
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>


That said, it's still best to avoid register globals if you can or to apply it only when you need it-- not on the whole site, but for just the pages that actually required it. And really be sure that any "security" type variables are given a default value. That's crucial.