On Tue, Feb 25, 2003 at 03:03:55PM +0100, Garvin Hicking wrote:
Looking at the
HTML for that page, I see you are passing filenames for
the field_transformation variable. Take out the .inc.php3 part and go
and double check that code for security holes, as it may be susceptible
to data injection.
I got a grip of that problem on the other side. I don't do
any input validation, but
rely on the dropdown-input. Because when evaluation the columns in browse mode,
there's a check to only allow a transformation, if it fits certain rules
(<mimetype>_<subtype>__<transformation>.inc.php3), and only in the
libraries/transformations directory. Because data is passed via a select field I
surely think we could trust user data there.
This is where a malicous input can be
made, and it's not as difficult as
a custom POST/GET even, just copying the HTML page, and changing a few
URLS.
Warning shouldn't be an issue, because you can
only trick false data
in by using your own POST/GET-requests, so in this case the user
already knows, he is hacking into our application and may get false
results. But even if he gets an invalid transform into the table, it
simply isn't used in the output.
In this case, evil user is a malicuos user
that has access to a database
or table already, and wants to root the system.
evil user adds a tranform that reads a piece of data from the server as
a root user, somewhere else on the file system, say /tmp (using the
docSQL bug). the fix can conform to your naming requirements or not.
Now evil user makes his own table, and puts in a value of '/etc/shadow'
or any file he wants. he then gets the exact transform he wants to run
on the '/etc/shadow' string. He's now got your entire /etc/shadow file,
with your passwords or worse.
Any objections to this approach, which is already
coded this way and thereby takes
no coding-time to keep it that way (*broad hint* ;-))
The fix shouldn't be
hard. Just remove the .inc.php3 part off the data
that is passed to the browser, and add it back in when the data comes
back, along with making sure all the input data is properly escaped to
prevent the user getting out of the specific directory.
Here is an
idea for the quickbox, give it three mini-tabs:
Maybe it is a bit complicated to
make a three-part query window, so I'll see what
can be done there. Worst thing would be to have input-buttons as TAB-icons instead
of text links, or to rely on javascript for that, again.
Just seperate the code for
the different parts of the tab window into
different files maybe? or is the bug JS related?
behaviour:
on login and logout or a large number of rows existing, run a query on
How to you
get to know, if a user "logs in" or "logs out", without session
management? You mean, everytime a user makes a call to main.php3?
logout - the
logout link in the left frame
login - on load of the frameset
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page :
http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85