Entries tagged as userdir
apache certificates cryptography datenschutz datensparsamkeit encryption grsecurity https itsecurity javascript karlsruhe letsencrypt linux mod_rewrite nginx ocsp ocspstapling openssl php revocation security serendipity sni ssl symlink tls vortrag web web20 webhosting webmontag websecurity bigbluebutton cookie fileexfiltration jodconverter libreoffice openid openidconnect sso xss ajax azure browser bypass clickjacking cve domain escapa firefox ftp games gobi google helma html kde khtml konqueror lemmings microsoft modulobias mozilla mpaa newspaper password passwordalert random salinecourier subdomain vulnerability webcore xsa 0days 27c3 addresssanitizer adguard adobe aead aes afra aiglx algorithm altushost android antivir antivirus aok apt asan auskunftsanspruch axfr badkeys barcamp bash berlin berserk bias bleichenbacher blog bodensee botnetz braunschweig bsi bsideshn bufferoverflow bugbounty bundesdatenschutzgesetz bundestrojaner bundesverfassungsgericht busby c ca cacert cbc ccc cccamp11 cellular certificate cfb chcounter chrome chromium clamav clang cloudflare cmi cms code compiz conflictofinterest crash crypto csrf darmstadt deb debian dell deolalikar diffiehellman dingens diploma diplomarbeit distributions dns drupal easterhegg edellroot eff email english eplus facebook fedora firewall fortigate fortinet forwardsecrecy freak freesoftware freewvs frequency fsfe fuzzing gajim gallery gcc gentoo ghost gimp git glibc gnupg gnutls gpg gsm gsoc gstreamer hackerone hacking hannover hash heartbleed http infoleak informationdisclosure internetscan ircbot jabber joomla kaspersky key keyexchange komodia leak lessig luckythirteen malware maninthemiddle mantis math md5 memorysafety mephisto milleniumproblems mitm mobilephones moodle mplayer mrmcd mrmcd100b mrmcd101b multimedia mysql napster nessus netfiltersdk nist nss ntp ntpd observatory onlinedurchsuchung openbsc openbts openleaks openpgp openvas osmocombb otr owncloud packagemanagement padding panda papierlos passwort passwörter pdo pgp phishing pnp poodle privacy privatekey privdog protocolfilters provablesecurity pss python rand rc2 redhat rhein rpm rsa rsapss rss s9y schlüssel science server session sha1 sha2 sha256 sha512 shellbot shellshock sicherheit signatures slides smime snallygaster sniffing spam sqlinjection squirrelmail staatsanwaltschaft stacktrace study stuttgart sunras superfish support talk taz thesis tlsdate toendacms transvalid überwachung ubuntu unicef unicode update updates useafterfree utf-8 verschlüsselung virus vlc vulnerabilities webapps wiesbaden windows windowsxp wiretapping wordpress x509 xgl xine xmpp zerodays zugangsdaten zzuf acid3 base64 breach cookies crime css heist midori samesite script time webdesign webkit webstandards content-security-policy core coredump csp segfault webroot webserver
Monday, April 6. 2020
Userdir URLs like https://example.org/~username/ are dangerous
I would like to point out a security problem with a classic variant of web space hosting. While this issue should be obvious to anyone knowing basic web security, I have never seen it being discussed publicly.
Some server operators allow every user on the system to have a personal web space where they can place files in a directory (often ~/public_html) and they will appear on the host under a URL with a tilde and their username (e.g. https://example.org/~username/). The Apache web server provides such a function in the mod_userdir module. While this concept is rather old, it is still used by some and is often used by universities and Linux distributions.
From a web security perspective there is a very obvious problem with such setups that stems from the same origin policy, which is a core principle of Javascript security. While there are many subtleties about it, the key principle is that a piece of Javascript running on one web host is isolated from other web hosts.
To put this into a practical example: If you read your emails on a web interface on example.com then a script running on example.org should not be able to read your mails, change your password or mess in any other way with the application running on a different host. However if an attacker can place a script on example.com, which is called a Cross Site Scripting or XSS vulnerability, the attacker may be able to do all that.
The problem with userdir URLs should now become obvious: All userdir URLs on one server run on the same host and thus are in the same origin. It has XSS by design.
What does that mean in practice? Let‘s assume we have Bob, who has the username „bob“ on exampe.org, runs a blog on https://example.org/~bob/. User Mallory, who has the username „mallory“ on the same host, wants to attack Bob. If Bob is currently logged into his blog and Mallory manages to convince Bob to open her webpage – hosted at https://example.org/~mallory/ - at the same time she can place an attack script there that will attack Bob. The attack could be a variety of things from adding another user to the blog, changing Bob‘s password or reading unpublished content.
This is only an issue if the users on example.org do not trust each other, so the operator of the host may decide this is no problem if there is only a small number of trusted users. However there is another issue: An XSS vulnerability on any of the userdir web pages on the same host may be used to attack any other web page on the same host.
So if for example Alice runs an outdated web application with a known XSS vulnerability on https://example.org/~alice/ and Bob runs his blog on https://example.org/~bob/ then Mallory can use the vulnerability in Alice‘s web application to attack Bob.
All of this is primarily an issue if people run non-trivial web applications that have accounts and logins. If the web pages are only used to host static content the issues become much less problematic, though it is still with some limitations possible that one user could show the webpage of another user in a manipulated way.
So what does that mean? You probably should not use userdir URLs for anything except hosting of simple, static content - and probably not even there if you can avoid it. Even in situations where all users are considered trusted there is an increased risk, as vulnerabilities can cross application boundaries. As for Apache‘s mod_userdir I have contacted the Apache developers and they agreed to add a warning to the documentation.
If you want to provide something similar to your users you might want to give every user a subdomain, for example https://alice.example.org/, https://bob.example.org/ etc. There is however still a caveat with this: Unfortunately the same origin policy does not apply to all web technologies and particularly it does not apply to Cookies. However cross-hostname Cookie attacks are much less straightforward and there is often no practical attack scenario, thus using subdomains is still the more secure choice.
To avoid these Cookie issues for domains where user content is hosted regularly – a well-known example is github.io – there is the Public Suffix List for such domains. If you run a service with user subdomains you might want to consider adding your domain there, which can be done with a pull request.
Some server operators allow every user on the system to have a personal web space where they can place files in a directory (often ~/public_html) and they will appear on the host under a URL with a tilde and their username (e.g. https://example.org/~username/). The Apache web server provides such a function in the mod_userdir module. While this concept is rather old, it is still used by some and is often used by universities and Linux distributions.
From a web security perspective there is a very obvious problem with such setups that stems from the same origin policy, which is a core principle of Javascript security. While there are many subtleties about it, the key principle is that a piece of Javascript running on one web host is isolated from other web hosts.
To put this into a practical example: If you read your emails on a web interface on example.com then a script running on example.org should not be able to read your mails, change your password or mess in any other way with the application running on a different host. However if an attacker can place a script on example.com, which is called a Cross Site Scripting or XSS vulnerability, the attacker may be able to do all that.
The problem with userdir URLs should now become obvious: All userdir URLs on one server run on the same host and thus are in the same origin. It has XSS by design.
What does that mean in practice? Let‘s assume we have Bob, who has the username „bob“ on exampe.org, runs a blog on https://example.org/~bob/. User Mallory, who has the username „mallory“ on the same host, wants to attack Bob. If Bob is currently logged into his blog and Mallory manages to convince Bob to open her webpage – hosted at https://example.org/~mallory/ - at the same time she can place an attack script there that will attack Bob. The attack could be a variety of things from adding another user to the blog, changing Bob‘s password or reading unpublished content.
This is only an issue if the users on example.org do not trust each other, so the operator of the host may decide this is no problem if there is only a small number of trusted users. However there is another issue: An XSS vulnerability on any of the userdir web pages on the same host may be used to attack any other web page on the same host.
So if for example Alice runs an outdated web application with a known XSS vulnerability on https://example.org/~alice/ and Bob runs his blog on https://example.org/~bob/ then Mallory can use the vulnerability in Alice‘s web application to attack Bob.
All of this is primarily an issue if people run non-trivial web applications that have accounts and logins. If the web pages are only used to host static content the issues become much less problematic, though it is still with some limitations possible that one user could show the webpage of another user in a manipulated way.
So what does that mean? You probably should not use userdir URLs for anything except hosting of simple, static content - and probably not even there if you can avoid it. Even in situations where all users are considered trusted there is an increased risk, as vulnerabilities can cross application boundaries. As for Apache‘s mod_userdir I have contacted the Apache developers and they agreed to add a warning to the documentation.
If you want to provide something similar to your users you might want to give every user a subdomain, for example https://alice.example.org/, https://bob.example.org/ etc. There is however still a caveat with this: Unfortunately the same origin policy does not apply to all web technologies and particularly it does not apply to Cookies. However cross-hostname Cookie attacks are much less straightforward and there is often no practical attack scenario, thus using subdomains is still the more secure choice.
To avoid these Cookie issues for domains where user content is hosted regularly – a well-known example is github.io – there is the Public Suffix List for such domains. If you run a service with user subdomains you might want to consider adding your domain there, which can be done with a pull request.