http://mivo.truxoft.com
MIVO!
miva beyond limits

MIVA^®  SECURITY:  Variable Scope

From MEU, 04/18/2001: Brian R. Bullock, Adam Denning, Ivo Truxa

[SNIP] - (original message)

Very nice Ivo (as usual :). But one of your suggestions suprised me. Would you explain in more detail the security risk of using unscoped variable names?

Brian R. Bullock
MvTools, http://papercitysoftware.com

top

[SNIP] - (original message)

> I'm very interested in learning about scoping my variables- and how not
> doing so can be a security risk. I don't really have a good grasp
> on how to
> apply scoping. Global, of course can be accessed by anything (as its name
> implies), local can only be accessed from within, say a function or some
> other piece of MIVA code?

Right, local variables are only available within the function they run from (also if you run the same function more than once the locals are new each time. As soon as /MvFUNCTION is reached all locals are gone). The thing is, if you don't use the l. prefix you always create a global whether you are in a function or not. Say inside a function you write <MvASSIGN NAME="var" VALUE="1">. Since there is no explicit scope the Miva Engine will call it a global, so it would be the same effect as writing <MvASSIGN NAME="g.var" VALUE="1">. Outside of functions, the distinction between local/global doesn't really exist. If, outside of a function, you write <MvASSIGN NAME="l.var" VALUE="1">, Miva will treat this exactly the same as <MvASSIGN NAME="g.var" VALUE="1"> (or <MvASSIGN NAME="var" VALUE="1">).

Then there is also s.system and d.database scope. If you don't use scope when you use the variable, Miva will try to figure it out for you by checking for a local, database, system, then global.

I'm sure Ivo will explain what he meant in terms of security issues, but, regardless, not using scope is a bad habit IMHO. Not doing so makes scripts more prone to bugs and harder to read. You run the risk of inadvertently changing the value of a variable you don't mean to.

Adam Denning
STARBASE-21, Inc. -- http://miva.starbase21.com/

top

Well, Adam Denning already partially answered the question. In fact, there is no _direct_ danger coming from missing variable scopes. The sole fact that you do not use any variable scope does not set your script _necessarily_ vulnerable.

The danger is, that when you miss a variable scope, it _may_ be possible that your script processes other variable than you think you are going to execute: you carefully initialize a variable, encode it after a user input and even remove other dangerous characters and you think you are perfectly safe, but a hacker _may_ manage to create or use a variable of the same name, just with another scope with higher precedence and all your effort is worthless.

The best habit is using local variables anytime it is possible. Because of the scope preference it is more difficult to inject some code into a local variable then to a global one. Of course, it is true only inside of functions; within the script body, the global and the local variables are in fact identical and assigning to one overwrites the other, as Adam correctly explained.

It is very easy to inject code or any value into any global un-initialized variable. There are certain possibilities with system variables and injecting code into database or local variables may be possible indirectly through a glitch in coding or improper data handling in your script.

The variable scope precedence is little bit different than what Adam wrote. Correctly it is:

1. system
2. local
3. database
4. global

You can see that using global variables (the default scope if you do not assign it explicitly) is the most dangerous, because it may be overridden with three other levels (when using no scope prefix). Local variables are much securer. As for critical variables - you may consider placing them into the sitevars file and assigning them so the system scope. However, if you systematically and ALWAYS use scopes at all variables and initialize ALL variables before using them, the danger that a hacker manages to abuse them is much lower.

As for database scope prefixes - it is also much better to use the full names including the database alias, then just simply 'd.field'.

Ivo
http://mivo.truxoft.com

top

top

Miva and some other terms used on this page are registerd trademarks of the Miva Corporation
copyright  truXoft  © 1997-2010