A vulnerability allowing XSS in Foreman 1.7.0 and higher was reported from upstream. It is allowed to store the key/value parameters globally or assigned to various objects and using a tickbox in the UI the values can be hidden to mask them from casual viewing. The tickbox that hides/shows the value fails to handle HTML properly and so is vulnerable to an XSS issue where HTML can be stored in a parameter, and executed by another user if they later tick the hide/show box.

Upstream bug:

http://projects.theforeman.org/issues/11859

Dominic Cleal of Red Hat reports:

The "requiressl" setting (in /etc/foreman/settings.yml) should enforce that web requests sent to Foreman over HTTP are redirected to HTTPS, but this was found not to happen with API requests (e.g. from Hammer CLI). Foreman will process API requests over HTTP, but should have redirected.

Redirection won't help with credentials having already been sent, but should give some notification that the user/app is using the wrong URL.

Affects all versions of Foreman since 1.1.

The issue has already been fixed since Foreman 1.9.0-RC1 via a refactor in #10471.

To mitigate this with Apache, add a stanza to the HTTP VirtualHost (e.g. in /etc/httpd/conf.d/05-foreman.d/apiredirect.conf) similar to:

RewriteEngine On RewriteRule ^/api/(.) https://%{SERVERNAME}/api/$1 [R,L]

External reference:

http://projects.theforeman.org/issues/11119

Foreman before 1.8.1 does not set the secure flag for the sessionid cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http session.