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