I've had a number of people contact me recently concerning dotProject and potential security vulnerabilities. Most of these people were familiar with the v1.0.2 permissions systems and had found serious flaws in one way or another. Without giving a complete roadmap to compromising these legacy installs, I'd like to address them here.
First, the cookie/session system was completely flawed. Instead of setting a cookie on a per-install basis, dotProject v1.0.2 set it on a per-server basis. This seems to work out fine until you have two installs on the same server. During our development, it was a common scenario to log into the development system – where all developers are admins – and then have the same permissions in the primary system. Obviously this was horribly bad and made Professional dotProject Hosting impossible, so it was fantastic when this was fixed. Now sessions are managed on a per-install basis. Therefore, if you are logged into the dotProject demo on CaseySoftware, those permissions exist there and no where else.
Next, the permission system received major rework. Instead of building the granular permission system needed, it was implemented via phpgacl. This allows a completely granular permissions systems were groups of permissions can be created (Roles) and individual permissions assigned. For example, in CaseySoftware, we have a “Project Worker” role which has a Deny All for Companies, Deny All for Admin, and then an Allow View/Access for CaseySoftware. This allows for proposed projects and old projects to be stored under individual clients. Eventually, we will grant clients access to certain parts of the system, but this isn't necessary as of yet.
Next, all passwords are stored in MD5 hashes in the database. Although there are getting to be collisions in the hashspace for MD5, this is still sufficient for now. Eventually the system will have to be converted to SH-1 or something a bit more robust. Although, if a malicious user already has access to the database, a secure password is not going to protect much.
Finally, the classic idea of Cross Site Scripting (XSS) attacks is pretty minimal for three reasons: only authorized users have access to any of the text boxes within the system; all slashes and brackets are stripped from user input; and this information is not presented to external users. This makes formatting the text boxes on fields such as project description or task description more difficult, but I believe this is a small price to pay.
In summary, the permissions are much more robust, the session problems have been fixed, the passwords are reasonably secure, and all user input is non-public and properly escaped. Any questions?