Brian Theado <[email protected]> wrote: > On Thu, Dec 31, 2009 at 5:34 PM, Jeremy Cowgar <[email protected]> wrote: > > The cgi function can only be used by someone with report edit > permissions. So if no calls to the cgi function are added to any > reports, fossil is just as secure as without the cgi function > implementation. >
I was thinking about this. Two things, it can only be inserted by someone with report edit permissions but it can be used by anyone executing that report. Thus, everything would have to be escaped properly otherwise you just opened all your internals to the world via SQL injection: http://repo?rptview?m=5&cgi_param=';DELETE FROM users; Or, they could change the password of an existing user (admin user even). But... if these security precautions are handled properly, then it could be pretty powerful. I don't care for the typical "Tickets" page that lists reports in alphabetical order, so I changed my main theme to point "Tickets" to a specially crafted Wiki page that gives users instructions on finding existing bugs and also notes on how to write a good bug report, etc... If we had the ability to accept CGI parameters into the SQL, then I could also create a user driven search page. That's pushing the limits of what can be done (actually, I'm not sure form elements are valid HTML in the wiki, so it may not be able to be done) but, it begins to make a much more user friendly system. It would be nice to have permissioned wiki pages, i.e. admin. Then when an admin permission, fore go the security checks on HTML elements, also include the ability to use TH1 scripting. That would open the world. Jeremy _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
