There are a number of components in this system where security needs to be taken into consideration. Each component uses it own security model and must be configured independently. This chapter, in most part, will discuss what should be considered to secure your system, rather than describing how to do it. Please refer to documentation for each of the components if necessary. For specific instructions on how to secure your bug tracking system please refer to "Software Installation and Configuration" chapter.
This system is designed to operate on Windows Server 2000 (or later) platform. Windows OS provides all the tools and features necessary to secure your server from unauthorized access ether locally or through the network. You should take all necessary steps to secure your server and file system in the same manner as you would do for any other computer system on you network. There are no special requirements related to this system.
The IIS web server comes as a part of your Windows OS. The server employs additional security features in order to provide access in a controlled manner to the resources it is serving. These resources are commonly known as static HTML pages, CGI scripts (asp, php, cgi, perl, etc.), client side scripts such as JavaScript, and just plain files and documents that can be downloaded by users.
In general, to improve your web server security you can:
File Attachments
In regards to this bug tracking system you should consider one issue. The file attachments uploaded to your server are located in a directory and not in the database, therefore any user can download these files without having to login to the bug tracking system by figuring-out and specifying a URL that links directly to these files. The browser itself helps to archive this because it remembers all the URLs that were used for about 20 days.
Now, you have to decide whether this issue posses a security concern to your organization. It depends on what kind of information will be in those files (public or confidential), what kind of users will have access to your bug tracking system and other factors. If you are, also, going to share the same kind of information in an unsecured public knowledge base, there is, probably, no need to worry about this issue right now. You should also remember that any bug tracking system is a tool to share information, not to bury in the system. Maybe confidential files should not be put in it in the first place.
In any case, there are two ways to prevent unauthorized access to file attachments. First, you can create a directory outside of 'wwwroot' and second, to apply 'Directory Security' to the folder where file attachments are stored. This folder is usually called 'Attachments' and located inside of your 'wwwroot\<instance>' where 'instance' is a subdirectory containing bug tracking system files. Directory Security can be applied through you IIS configuration tool called 'Internet Services Manager'. Each solution has its own benefits and disadvantages. First option completely prevents access by any means other than trough bug tracking system and is recommended. Second option allows mixed access to these files, but requires system administrator to maintain security to this resource on OS level. You should also consider that the second option could require additional Windows user accounts, therefore more Windows licenses.
Another problem with file attachments is that someone can create and upload a malicious script file and then execute this file on the server unless 'Execute' permissions on this directory are turned off. For example, if someone uploads an ASP script and knows the location where this script is located, he can then specify a URL to his own script and request it back, but the web server will execute the script and do everything the code says because you forgot to disable script execution permissions. This applies not only to ASP scripts, *.exe, *.js, *.php, *.pl and other files can be uploaded an executed in most cases. Of course, it is not an easy task to write such script, but the hackers do have plenty of time.
Fortunately, for owners of our bug tracking system, this threat is eliminated. Our Enhanced File Upload/Download mechanism disregards the type of file being downloaded and always returns it as data. The maximum a hacker would get back is his own script. Please remember that you still have to protect the 'Attachments' directory as described in previous paragraph, otherwise, this feature will be useless.
Your database is another component of this bug tracking system and database security should be applied to it. When you install IIS web server, the setup program creates a Windows user account called IUSR_<host>. This account must be added either by executing a script (see "Software Installation and Configuration") or manually to a) the list of SQL Server "Logins" and b) the database "Users". Once added, make sure it has access to the bug database and make sure 'public' role is applied. Within your bug tracker database, this user must have SELECT, INSERT, UPDATE, DELETE permissions to all non-system tables, SELECT permissions to all non-system views, and EXECUTE permissions to two stored procedures called 'sp_cache_stages' and 'sp_server_stats'. See example here. Please refer to you SQL server documentation regarding managing user accounts. In addition to the script provided with the software, the bug tracker database includes a stored procedure called "sp_IUSR_Setup" which performs identical function - adds or fixes the IUSR account. This procedure is intended only for administrators.
In addition to the security provided by all of the components mentioned above, this software also incorporates a built-in security model that allows the administrator to control access to both function (Add, Delete, Edit, etc) and data records. By using these features the administrator can create different groups of users with different privileges. For example, a group could be defined that can only access records created by other members of the same group.
User and Group Privileges
Security model is based on the concept of individual users and user groups. Each individual user must log into the system, and each user is a member of one or more user groups. User groups are a convenient way to group similar users together, and define security for those users.
For example, rather than defining specific access privileges for all 50 users in a company, the administrator can create user groups (Engineering, QA, Customers, etc), define security for each group, and then assign the users to these groups.
However, when an individual user requires additional permissions (more than defined for the group he/she is in) Administrator can grant these permissions specifically to this user. Removing individual user permission does not revoke user's privileges if user is a member of a group that has these privileges. In this situation Administrator must reassign this user to a different group that does not have these privileges. When user is a member of two or more groups, total user privileges are the sum of each group privileges plus his own additional privileges granted by Administrator (if any).
Special-Purpose Accounts
There are four (4) special-purpose system-defined groups:
- Everyone - All INTERNAL users should be members of this group in addition to the user-defined group such as 'Engineers', 'QA', 'Contractors', etc.
- Administrators - All administrators of this system. Could also be members of another user-defined group.
- Managers - All group managers and project managers must be included in this group. This is how the system identifies who is the manager of a particular group.
- Internet - All EXTERNAL users (customers, visitors, etc.) .
There are also three (3) special-purpose user accounts:
- Admin - Permanent system administrator account. Should not be used for other purposes.
- Guest - Read-only, shared account for internal users. Useful for occasional access to the system.
- Nobody - Account that does not belong to any user. When system cannot determine a better candidate it will use this account for assignment unless user selects someone else.
Restricting Access To Functions
Each user group can be assign privileges, and each user that is a member of the group inherits that privilege. All of the basic functions like Add, Edit, etc. are defined to be a privilege that can be assigned to a user group.
For example, to allow a user to Edit and View records, you would create a user group that has both Edit and View privileges, and then assign the user to that group.
Two special cases are the 'Admin' user and 'Administrators' group. These two always have Administrative privileges. Other user groups can also be defined to have this privilege, however it cannot be removed from the Admin group.
Privileges are covered in detailed in the following help topic:
Restricting Access To Data
The software supports an optional record-level security model called Record Security. This feature allows users to control access to each data record by other groups. By default, when new record is created, it is accessible to all groups that the user creating it is a member of, including 'Everyone'. Users with the privilege to modify Record Security can explicitly specify what groups should have access to a record. This feature can be globally enabled or disabled via the setting under General Preferences. Privileges to modify Record Security are defined individually for each user and group.
Default Passwords and Password Encryption
The software uses a non-reversible 16-byte (128-bit) MD5 hashing algorithm for password encryption. It is impossible (theoretically) to take both the hash and the algorithm and mathematically reverse the process to determine the original password. In other words, the password serves as a "private key". Only someone who has the key can generate a particular hash. The hashes, but not the original passwords, are stored in the bug tracking database. Please note that this separation of hash and passwords does NOT make the database less of a target for hackers, because with some effort a hash can be used as a password.
Additional protection is achieved by using Timed Challenge/Response key negotiation mechanism during user login and account lockout feature. By using this scheme software does not send either the user password or MD5 hash generated from this password across the network, because both can be intercepted and deciphered. The Challenge/Response mechanism receives a randomly generated (by the server) "public key" and a hash generated from user's password. With simple mathematical calculations these two produce a 16-bit non-reversible checksum, which is sent to the server. The server executes identical calculations and compares the checksums. Furthermore, a user must login within 1 minute from the time the "Login" page is displayed. After that time, server expires the key it sent to the client and denies access even if the password was entered correctly. User must refresh the page and repeat login. After 5 (default) unsuccessful logins account becomes "locked" for 15-20 minutes or even more time if user is still trying to get in.
The password encryption feature can be globally enabled or disabled via the "EncryptPassword" setting under General Preferences. Please note that switching between these two modes requires Administrator manually reset passwords for ALL users and notify these users of the new password. Whether this feature will be enabled or disabled should be decided on initial stages of using the system when impact would be minimal. By default, this feature is enabled.
The software comes with three (3) special-purpose system user accounts and one sample account for the Internet user. These accounts and the default passwords are listed in the table below.
User ID Default Password
(case sensitive)Corresponding MD5 key Comments Admin Admin e3afed0047b08059d0fada10f400c1e5 Guest Guest adb831a7fdd83dd1e2a309ce7591dff8 Nobody <NULL> <NULL> This account cannot login. Inet Inet 4dfdcc945ee2f545cd9b7727b56d0211 A value in the password field is required when Administrator creates a new user account. In this case, word "welcome" (MD5 key is 40be4e59b9a2a2b5dffb918c0e86b3d7) may be used. The user should change this temporary password once logged-in.
Even though human-readable passwords should always be entered, the Administrator's interface allows entering a password value as an MD5 hash. If hash is entered, it will not be encrypted the second time when the form is submitted and is saved in the database as entered. This allows Administrator, in special circumstances, to manipulate passwords without knowing the real password. On the "Login" pages any value entered into the "Password" field is encrypted. If an MD5 key is entered, it will be encrypted the second time. If a key is stolen from you database or acquired from the network it cannot be used as the password to access the system.
Conclusion:
The combination of MD5 password encryption and Timed Challenge/Response mechanism protect your bug tracking system and its users about 90%. This is somewhat more secured than running your computer without antivirus software. However, the 10% chance exists. If additional security is a requirement, please enable the Secure Socket Layer (SSL) on your web server and access this system via https:// .
You may ask a question. Why all of this is needed when IIS already provides Authorization mechanism? There are a number of reasons. First, IIS Authentication requires a centralized user database usually located on the domain controller. All bug tracker users would have to be defined one way or another as your domain users. This is, in most part, not the case for small organizations that do not have a domain. Then, this may increase the number of Windows user licenses (means more $$). Then, the issue comes to what to do with contractors, temporary employees who need "Internal" access to the bug tracking system, but not actually allowed access to the entire domain. Then, what if your organization has subdomains (affiliates) or remote offices.
Second, IIS does not always know (internally) the user it just authenticated. This may require users to login twice once into IIS and then the bug tracking system. So, the "Login" page would still have to exist which brings us back to the password protection issue.
And the third, enabling IIS Authentication does not solve the password protection issue for the "External" login module since you cannot add these Internet user to your domain.
The following table displays the various privileges that may be assigned to a user or user group.