Mercurial > kallithea
view README.rst @ 6532:33b71a130b16
templates: properly escape inline JavaScript values
TLDR: Kallithea has issues with escaping values for use in inline JS.
Despite judicious poking of the code, no actual security vulnerabilities
have been found, just lots of corner-case bugs. This patch fixes those,
and hardens the code against actual security issues.
The long version:
To embed a Python value (typically a 'unicode' plain-text value) in a
larger file, it must be escaped in a context specific manner. Example:
>>> s = u'<script>alert("It\'s a trap!");</script>'
1) Escaped for insertion into HTML element context
>>> print cgi.escape(s)
<script>alert("It's a trap!");</script>
2) Escaped for insertion into HTML element or attribute context
>>> print h.escape(s)
<script>alert("It's a trap!");</script>
This is the default Mako escaping, as usually used by Kallithea.
3) Encoded as JSON
>>> print json.dumps(s)
"<script>alert(\"It's a trap!\");</script>"
4) Escaped for insertion into a JavaScript file
>>> print '(' + json.dumps(s) + ')'
("<script>alert(\"It's a trap!\");</script>")
The parentheses are not actually required for strings, but may be needed
to avoid syntax errors if the value is a number or dict (object).
5) Escaped for insertion into a HTML inline <script> element
>>> print h.js(s)
("\x3cscript\x3ealert(\"It's a trap!\");\x3c/script\x3e")
Here, we need to combine JS and HTML escaping, further complicated by
the fact that "<script>" tag contents can either be parsed in XHTML mode
(in which case '<', '>' and '&' must additionally be XML escaped) or
HTML mode (in which case '</script>' must be escaped, but not using HTML
escaping, which is not available in HTML "<script>" tags). Therefore,
the XML special characters (which can only occur in string literals) are
escaped using JavaScript string literal escape sequences.
(This, incidentally, is why modern web security best practices ban all
use of inline JavaScript...)
Unsurprisingly, Kallithea does not do (5) correctly. In most cases,
Kallithea might slap a pair of single quotes around the HTML escaped
Python value. A typical benign example:
$('#child_link').html('${_('No revisions')}');
This works in English, but if a localized version of the string contains
an apostrophe, the result will be broken JavaScript. In the more severe
cases, where the text is user controllable, it leaves the door open to
injections. In this example, the script inserts the string as HTML, so
Mako's implicit HTML escaping makes sense; but in many other cases, HTML
escaping is actually an error, because the value is not used by the
script in an HTML context.
The good news is that the HTML escaping thwarts attempts at XSS, since
it's impossible to inject syntactically valid JavaScript of any useful
complexity. It does allow JavaScript errors and gibberish to appear on
the page, though.
In these cases, the escaping has been fixed to use either the new 'h.js'
helper, which does JavaScript escaping (but not HTML escaping), OR the
new 'h.jshtml' helper (which does both), in those cases where it was
unclear if the value might be used (by the script) in an HTML context.
Some of these can probably be "relaxed" from h.jshtml to h.js later, but
for now, using h.jshtml fixes escaping and doesn't introduce new errors.
In a few places, Kallithea JSON encodes values in the controller, then
inserts the JSON (without any further escaping) into <script> tags. This
is also wrong, and carries actual risk of XSS vulnerabilities. However,
in all cases, security vulnerabilities were narrowly avoided due to other
filtering in Kallithea. (E.g. many special characters are banned from
appearing in usernames.) In these cases, the escaping has been fixed
and moved to the template, making it immediately visible that proper
escaping has been performed.
Mini-FAQ (frequently anticipated questions):
Q: Why do everything in one big, hard to review patch?
Q: Why add escaping in specific case FOO, it doesn't seem needed?
Because the goal here is to have "escape everywhere" as the default
policy, rather than identifying individual bugs and fixing them one
by one by adding escaping where needed. As such, this patch surely
introduces a lot of needless escaping. This is no different from
how Mako/Pylons HTML escape everything by default, even when not
needed: it's errs on the side of needless work, to prevent erring
on the side of skipping required (and security critical) work.
As for reviewability, the most important thing to notice is not where
escaping has been introduced, but any places where it might have been
missed (or where h.jshtml is needed, but h.js is used).
Q: The added escaping is kinda verbose/ugly.
That is not a question, but yes, I agree. Hopefully it'll encourage us
to move away from inline JavaScript altogether. That's a significantly
larger job, though; with luck this patch will keep us safe and secure
until such a time as we can implement the real fix.
Q: Why not use Mako filter syntax ("${val|h.js}")?
Because of long-standing Mako bug #140, preventing use of 'h' in
filters.
Q: Why not work around bug #140, or even use straight "${val|js}"?
Because Mako still applies the default h.escape filter before the
explicitly specified filters.
Q: Where do we go from here?
Longer term, we should stop doing variable expansions in script blocks,
and instead pass data to JS via e.g. data attributes, or asynchronously
using AJAX calls. Once we've done that, we can remove inline JavaScript
altogether in favor of separate script files, and set a strict Content
Security Policy explicitly blocking inline scripting, and thus also the
most common kind of cross-site scripting attack.
| author | Søren Løvborg <sorenl@unity3d.com> |
|---|---|
| date | Tue, 28 Feb 2017 17:19:00 +0100 |
| parents | 0b6d2ca7175f |
| children | d5eaa70e0f2a |
line wrap: on
line source
================ Kallithea README ================ About ----- **Kallithea** is a fast and powerful management tool for Mercurial_ and Git_ with a built-in push/pull server, full text search and code-review. It works on http/https and has a built in permission/authentication system with the ability to authenticate via LDAP or ActiveDirectory. Kallithea also provides simple API so it's easy to integrate with existing external systems. Kallithea is similar in some respects to GitHub_ or Bitbucket_, however Kallithea can be run as standalone hosted application on your own server. It is open-source donationware and focuses more on providing a customised, self-administered interface for Mercurial_ and Git_ repositories. Kallithea works on Unix-like systems and Windows, and is powered by the vcs_ library created by Łukasz Balcerzak and Marcin Kuźmiński to uniformly handle multiple version control systems. Kallithea was forked from RhodeCode in July 2014 and has been heavily modified. Installation ------------ Kallithea requires Python_ 2.x and it is recommended to install it in a virtualenv_. Official releases of Kallithea can be installed with:: pip install kallithea The development repository is kept very stable and used in production by the developers -- you can do the same. Please visit https://docs.kallithea-scm.org/en/latest/installation.html for more details. There is also an experimental `Puppet module`_ for installing and setting up Kallithea. Currently, only basic functionality is provided, but it is still enough to get up and running quickly, especially for people without Python background. See https://docs.kallithea-scm.org/en/latest/installation_puppet.html for further information. Source code ----------- The latest sources can be obtained from https://kallithea-scm.org/repos/kallithea. The issue tracker and a repository mirror can be found at Bitbucket_ on https://bitbucket.org/conservancy/kallithea. Kallithea features ------------------ - Has its own middleware to handle Mercurial_ and Git_ protocol requests. Each request is authenticated and logged together with IP address. - Built for speed and performance. You can make multiple pulls/pushes simultaneously. Proven to work with thousands of repositories and users. - Supports http/https, LDAP, AD, proxy-pass authentication. - Full permissions (private/read/write/admin) together with IP restrictions for each repository, additional explicit forking, repositories group and repository creation permissions. - User groups for easier permission management. - Repository groups let you group repos and manage them easier. They come with permission delegation features, so you can delegate groups management. - Users can fork other users repos, and compare them at any time. - Built-in versioned paste functionality (Gist) for sharing code snippets. - Integrates easily with other systems, with custom created mappers you can connect it to almost any issue tracker, and with a JSON-RPC API you can make much more. - Built-in commit API lets you add, edit and commit files right from Kallithea web interface using simple editor or upload binary files using simple form. - Powerful pull request driven review system with inline commenting, changeset statuses, and notification system. - Importing and syncing repositories from remote locations for Git_, Mercurial_ and Subversion. - Mako templates let you customize the look and feel of the application. - Beautiful diffs, annotations and source code browsing all colored by pygments. Raw diffs are made in Git-diff format for both VCS systems, including Git_ binary-patches. - Mercurial_ and Git_ DAG graphs and Flot-powered graphs with zooming and statistics to track activity for repositories. - Admin interface with user/permission management. Admin activity journal, logs pulls, pushes, forks, registrations and other actions made by all users. - Server side forks. It is possible to fork a project and modify it freely without breaking the main repository. - reST and Markdown README support for repositories. - Full text search powered by Whoosh on the source files, commit messages, and file names. Built-in indexing daemons, with optional incremental index build (no external search servers required all in one application). - Setup project descriptions/tags and info inside built in DB for easy, non-filesystem operations. - Intelligent cache with invalidation after push or project change, provides high performance and always up to date data. - RSS/Atom feeds, Gravatar support, downloadable sources as zip/tar/gz. - Optional async tasks for speed and performance using Celery_. - Backup scripts can do backup of whole app and send it over scp to desired location. - Based on Pylons, SQLAlchemy, SQLite, Whoosh, vcs. License ------- **Kallithea** is released under the GPLv3 license. Kallithea is a `Software Freedom Conservancy`_ project and thus controlled by a non-profit organization. No commercial entity can take ownership of the project and change the direction. Kallithea started out as an effort to make sure the existing GPLv3 codebase would stay available under a legal license. Kallithea thus has to stay GPLv3 compatible ... but we are also happy it is GPLv3 and happy to keep it that way. A different license (such as AGPL) could perhaps help attract a different community with a different mix of Free Software people and companies but we are happy with the current focus. Community --------- **Kallithea** is maintained by its users who contribute the fixes they would like to see. Get in touch with the rest of the community: - Join the mailing list users and developers -- see http://lists.sfconservancy.org/mailman/listinfo/kallithea-general. - Use IRC and join #kallithea on FreeNode (irc.freenode.net) or use http://webchat.freenode.net/?channels=kallithea. - Follow Kallithea on Twitter, **@KallitheaSCM**. - Issues can be reported at `issue tracker <https://bitbucket.org/conservancy/kallithea/issues>`_. .. note:: Please try to read the documentation before posting any issues, especially the **troubleshooting section** Online documentation -------------------- Online documentation for the current version of Kallithea is available at https://pythonhosted.org/Kallithea/. Documentation for the current development version can be found on https://docs.kallithea-scm.org/. You can also build the documentation locally: go to ``docs/`` and run:: make html .. note:: You need to have Sphinx_ installed to build the documentation. If you don't have Sphinx_ installed you can install it via the command: ``pip install sphinx`` . Migrating from RhodeCode ------------------------ Kallithea 0.3.2 and earlier supports migrating from an existing RhodeCode installation. To migrate, install Kallithea 0.3.2 and follow the instructions in the 0.3.2 README to perform a one-time conversion of the database from RhodeCode to Kallithea, before upgrading to this version of Kallithea. .. _virtualenv: http://pypi.python.org/pypi/virtualenv .. _Python: http://www.python.org/ .. _Sphinx: http://sphinx.pocoo.org/ .. _Mercurial: http://mercurial.selenic.com/ .. _Bitbucket: http://bitbucket.org/ .. _GitHub: http://github.com/ .. _Subversion: http://subversion.tigris.org/ .. _Git: http://git-scm.com/ .. _Celery: http://celeryproject.org/ .. _vcs: http://pypi.python.org/pypi/vcs .. _Software Freedom Conservancy: http://sfconservancy.org/ .. _Puppet module: https://forge.puppetlabs.com/rauch/kallithea