Anyway. Molly stands as a key case example for how you should NOT write PHP. It makes heavy use of BAD-THINGS ®, does not use any sort of legitimate string munging to prevent SQL injection, and has almost no concept of session security.
As for bad things, I mean things like polluting the global namespace, using .html files with PHP in them, the eval() statement, old functions like eregi_*(), and heavy use of $_REQUEST as opposed to $_GET and $_POST. The PHP manual itself states that $_REQUEST cannot be trusted, as you do not know which of Environment, Cookies, Get, Post, Server sources provided the variable you're looking at in $_REQUEST or if one has over-written what you actually want.
The most glaring exploit I've found, however, is related to the rendering engine the the database module (Called forms). Molly controlled pages will often have some string in their URL which tells the Molly engine how to render said page, example: people.maml?id=77&renderAs=output Or renderAs=edit
Yup. I can just see all the tech minded people thinking "What if I change output to input?".
When RIT used Molly, exactly what your worst fears were, is what happened. Each element on the page became HTML Input.
After that point it became trivial to use the Firebug plugin for Firefox to modify the contents of the page on the fly to make Molly bend over for you. To update any record you wanted, it was a simple matter of navigating to that page, changing the URL, using firebug to change the form action from "insert.html" to "replace.html" and adding a value to a hidden input element named something along the lines of "form[0][id]".
Since Molly doesn't understand security, the files which parse the form input and create the SQL queries are wide open for all to access, as long as you can post the right information.
One way these can be protected is through the use of an .htaccess file using the
YOUR CODE IS BAD AND YOU SHOULD FEEL BAD TOO!
--PXA
