Userdir URLs like https://example.org/~username/ are dangerous

https://blog.hboeck.de/archives/899-Userdir-URLs-like-httpsexample.orgusername-are-dangerous.html

by hannob • 6 years ago

155 124 6 years ago

blog.hboeck.de

mholt• 6 years ago

mchristen• 6 years ago

Nitpick, but all of those you mentioned are shared with other tenants, just pick your layer of abstraction.

bsagdiyev• 6 years ago

Looks like he edited it to remove now but parent comment was basically saying he's been telling customers to avoid shared hosting by using shared hosting in the form of Heroku, etc instead.

vortico2• 6 years ago

I've never seen a userdir URL being used with anything but raw static HTML with no or little JS. Generally the type of people who use these hosts don't use cookies or local storage at all. They just want to post a few web pages, photos, or documents. Can someone find an example?

simonw• 6 years ago

Eighteen years ago my university let me host PHP scripts in a /~user directory, and I wrote my own simple blogging software and ran it there.

It was vulnerable to the attacks described here. Thankfully no-one on that domain ever exploited it in that way.

333c• 6 years ago

Today my college lets me do the same. I wonder if I could even possibly use `mod_wsgi` to run something like a Python server.

indymike2• 6 years ago

Most userdir hosting allows you to run CGI, PHP and whatever other scripting supported by Apache. Stuff that required a persistent connection to the server (I.e. WSGI) usually isn't supported... almost every cPanel host out there is set up in this manner... Unfortunately the path part of a URL is not used for same origin, so the security issue being floated is real for myhost.com/~someuser.

Wowfunhappy• 6 years ago

The only place I've seen these used are universities (eg each professor gets a webspace) and other small companies and organizations. I think it's relatively safe to assume Alice isn't going to attack Bob—if she did want to, she has better ways to do so.

Now, if someone knows of a host selling ~username spaces to members of the public, that's a different story.

tinus_hn2• 6 years ago

For Bob to trust Alice not to do something dumb like installing something and never updating it is another matter though.

kccqzy• 6 years ago

In most of the places where you get the ~username sites the users themselves have non-root UNIX accounts and they can't really install things on their own. (Well they can install it in their own home folder but that's it; won't affect other people.) Even the web server is centrally managed and the user only provides static HTML.

Polylactic_acid2• 6 years ago

When I see ~username I know I'm about to load a page with some cream tiled background. These days every user just gets their own subdomain like username.usersites.com

op00to• 6 years ago

Heh. I use two userdir websites for work.

ccmcarey• 6 years ago

NPM does this, noticed yesterday when creating an account. And wow, that website is absolutely terribly written.

lieuwex• 6 years ago

What? npm doesn't provide site hosting of any kind. Apart from just using the ~ convention this is not relevant at all.

RandomGuyDTB2• 6 years ago

I've only ever seen userdir URLs hosting static content - ideally, static HTML with lesson plans or a resume or something. Why would anyone host a web application on a userdir? This seems like a complete non-issue.

Also - why would a blog be threatened by XSS? A blog is a collection of static HTML files and I assume the creator would be using a composer or just a text editor + browser to add and edit pages. Why would anyone log into a blog? Nowadays anything like a comment section is generally handled by iframes to some other service (like Disqus) anyway.

jlgaddis2• 6 years ago

Also - why would a blog be threatened by XSS? A blog is a collection of static HTML files and I assume the creator would be using a composer or just a text editor + browser to add and edit pages. Why would anyone log into a blog?

Perhaps you've never heard of WordPress [0], the 17-year-old blogging software used by ~60 million web sites as of 2012 [1] and that is, today, "the platform of choice for over 35% of all sites across the web" [2]?

---

[0] https://wordpress.org

[1] https://web.archive.org/web/20160129215921/http://www.forbes...

[2] https://wordpress.org/about/

RandomGuyDTB2• 6 years ago

I have experience using Wordpress; in sixth grade I tried out the Wordpress editor and felt writing HTML was easier. I admit it's popular with less-savvy users and with companies with money to burn, but it seems unprofessional to use Wordpress for anything you can write by hand. I don't think anyone would be using blogging software if they didn't have their own domain.

kylek• 6 years ago

The tildeverse has some words for you

Polylactic_acid2• 6 years ago

Those sites have no backend code so there isn't really much risk of cookies being shared.

renewiltord• 6 years ago

This is a non-problem. There is no real threat model. It's like how you can cast to my TV if you're in my house. Sure, anyone could attack the party by posting porn on the TV but that's really not going to happen because I'm not going to invite you and put you in the wifi if you're the kind of person who does that.

tuckerpo• 6 years ago

Ah, a sensible take on security. Refreshing.

herpderperator• 6 years ago

Technically speaking, there could be a security vulnerability on a dynamic site that is being hosted with mod_userdir, even though the owner of it is "trusted". With that model, if the security vulnerability is exploited by a third party to attack a different mod_userdir user, then it's not really about who you trust to invite, since the entire Internet is technically invited.

mike_d• 6 years ago

Exactly correct. Even in the early 90s best practice was to house your user webspaces at users.isp.net/~user. Even now the most exciting thing you could do with this is use JavaScript to submit a contact form from another users webspace.

This is like complaining that Geocities users shared a security domain. Surprise, there was nothing of value hosted there to start with.

arkanciscan3• 6 years ago

You obviously never saw my Pokemon fansite from 1998

strenholme2• 6 years ago

Also, example.com/~username style URLs usually are 1990s-style static web sites where the only Javascript is something like a marquee. They are not the kinds of sites which have extensive Javascript or a web forum people can sign in to; at most a site like that would have a guestbook.

the_hoser• 6 years ago

Are you kidding? It's a standard feature of Apache, used by universities all over the place. Many shared hosting providers offered the feature for customers that weren't ready to update their DNS to the new host, until quite recently.

arkanciscan3• 6 years ago

Marquees were HTML

da_chicken• 6 years ago

People do turn malicious. One of the biggest sources of attacks in computer security is current and former users.

After all, if we didn't need to care about user level security, why don't we let everyone be root? Surely we only created accounts for people we can trust, right?

I'm not saying that your point isn't valid that the exposure here isn't very small. I'm just saying that your logic isn't really very sound.

yoloClin6• 6 years ago

It would have been much easier to say that if weaponised, an XSS vulnerability can access resources across the entire domain as if they were the victim, and should effectively be considered an account hijack of any exploited victims.

It really has nothing to do with homepaths, or even user-supplied data whatsoever.

Kwantuum• 6 years ago

Here's a threat model. My university used to give students /~s123456 folders. On the same domain as the main student platform, and as the main university site. I'm not sure if they still do this but it was less than 3 years ago. Considering the age of the infrastructure, there's even a good chance that session cookies were not marked HttpOnly. Even if they weren't, I can put a login form on my page, and even if the user doesn't get tricked into using it through phishing, if their browser autocompletes it I now have their username and password.

Now yes, our uni probably shouldn't be giving out userdirs to all students, much like wifi, you should only let in the people you trust. But that's exactly the point of the article.

redstripe• 6 years ago

You'd think this was just an archaic relic but Bambora payment processing (which hasn't updated their site since uppercase HTML tags and framesets were a thing) has a userdir feature that lets their customers upload static file to their "secure webspace" which is hosted on the same domain for all customers.

strenholme2• 6 years ago

https://www.bambora.com/en/us/ looks like a modern web site to me; if there was a URL we could look at, it would be interesting to see this.

rlpb• 6 years ago

All userdir URLs on one server run on the same host and thus are in the same origin. It has XSS by design.

The ship has now sailed, but I still think it's worth pointing out that it is Javascript's security model that is broken by design, that XSS vulnerabilities are the result, and the same origin policy is an incomplete workaround as illustrated by the article. This becomes clear when you consider that userdir URLs pre-date Javascript.

The public suffix list is yet another incomplete workaround for the security flaw in the same origin policy (that "same origin" isn't a concept that can be clearly defined).

The modern web stack is a security house of cards, as demonstrated.

vortico2• 6 years ago

Honestly I can't think of a much better system that can support a billion websites. What would you change/overhaul about the current system if you could ignore compatibility?

andy_ppp• 6 years ago

I still think it's a miracle that the browser was the solution to the client-server problem x-windows was trying to solve all along.

How we ended up with billions of people able to interact with an app that we can all build at home seems insane...

pwdisswordfish2• 6 years ago

If you honestly can’t think of one, that only demonstrates your lack of imagination.

I, for one, would imagine something based on a DNS TXT records that either directly contain or point to a URL describing some kind of security domain policy: whether and which subdomains and subdirectories should be considered separate, isolated security domains, with pattern matching, of course. Or maybe put it under /.well-known/ instead of DNS. At the very least, this would solve the unregistration problem of PSL (i.e. when an entry becomes stale, you will not immediately know it, and old versions of your product will still treat it as present).

yoloClin6• 6 years ago

Firstly, I'd fix the damn spelling of the referer header instead of everybody putting up with it for close to 30 years.

I don't think it's that JavaScript and HTML are a bad choice, but there are some things that would have made life a lot easier if they were strongly enforced sooner, including secure cookies by default, SameSite=lax, removal of referer header and CSP - doing them sooner would have stopped bad developer practices while also removing a fair chunk of application security complexities, but at least we're moving towards a better world regarding those now.

I don't know if it'd be technically possible to implement, but additional characters to mark unsafe strings would have a huge impact on webapp security. Reflection of untrusted data at the moment generally relies on one of: HTML encoding, URL encoding or JavaScript escaping and escaping a safe way is highly context-dependent (I've seen an unescaped "\n" cause injection within JavaScript contexts). A way of effectively storing the level of trust a chunk of data has across multiple transports when marking untrusted data including within HTML/JS, SQL statements and interpreted languages like BASH or PHP - this would eliminate a bunch of vulnerabilities and would probably have mitigated a bunch of notable historic vulnerabilities and/or hacks.

65102• 6 years ago

Make applications into a single file that can pull aditional xml and json data, images and video by appending the session key. If the application desires to do something other than display the data the user must give permission. No more checking if the json has a key but map it to a dom element and make that [and all its parents] unreadable.

(Keep all the legacy crap for when this is not enough)

chx• 6 years ago

What would you change/overhaul about the current system if you could ignore compatibility?

Say, you have some endpoints which can do a public key crypto signature verification. Part of the cookie data is such an endpoint URL. If a script loaded into a page wants to read a cookie, the endpoint defined by the cookie checks the signature of the script and the browser accordingly allows or not access to the cookie. As you'd sign the scripts during deployment, the private key is not even on the public servers.

For performance reasons probably wouldn't send the entire script just a hash of it so it's like GET https://example.com/check?hash=1234567890&signature=abcdef and there's a simple 200 or 403 response. You could make the API such that you can bundle multiple hashes and signatures together so the entire overhead over the network is a single request for every endpoint. If you want to be fancy, you can have a response body for the 403 response which tells the browser something like "this hash is of an outdated version, plz ignore cache and load a new one".

twic2• 6 years ago

For the same-origin problem, the web server could return an Origin header which defines the origin. So the server on example.org could serve https://example.org/~username for anything in that account. The defined origin would have to be under the scheme, domain, and port served by the server, of course.

hamilyon2• 6 years ago

If website is non-trivial, i. e. user have to login to it, I would encrypt all urls with client-specific key. So that it is non-sharable and unforgable

jlgaddis2• 6 years ago

Pretty much all modern web servers support per-user virtual hosts using wildcards that allow for URLs like http://username.users.example.org/ (instead of http://users.example.org/~username/ when using mod_userdir).

Unless I'm missing something, it seems that this would eliminate most of the issues raised in the article by using a separate subdomain for each user/site.

Using lighttpd, you can do this with this very simple configuration [0]:

  $HTTP["host"] =~ "users\.example\.org" {
      evhost.path-pattern = "/home/%4/public_html/" 
  }

Add a "wildcard" record for "*.users.example.org" pointing to the proper host to your DNS zone and you're all set.

---

[0] https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Mod...

vbezhenar2• 6 years ago

You can specify Path attribute for cookie and it will only be sent to URls with this prefix. I'm not completely sure, but I think that it should solve those security flaws.

k1t• 6 years ago

If you own example.com and want to have cookies accessible in the root (e.g. example.com/login.html) then you can't prevent example.com/users/~evildoer from accessing them.

justinsteven2• 6 years ago

It would not. It would stop the cookie from being sent to things outside of the path specified, but the Same Origin Policy is about, among other things, gaining read-access to the responses of fetch/XMLHttpRequest/AJAX requests.

If there is a cookie set for the path '/secret' and I can host content at '/attacker', then some of my JavaScript under /attacker could do a fetch request to /secret/something. This fetch request would carry the cookie for /secret, and the response would be readable by my JavaScript (due to Same Origin Policy). I could read the response, extract sensitive content, or even extract CSRF tokens to allow me to do state-changing CSRF-protected things under /secret

danShumway4• 6 years ago

The public suffix list is yet another incomplete workaround for the security flaw in the same origin policy (that "same origin" isn't a concept that can be clearly defined).

Origins are very clearly and rigorously defined[0].

It's just that people have a tendency to group multiple applications/users on the same origin. Now, would it be nice to optionally allow servers to be more restrictive? Sure. There are a few privacy implications there, but I could easily see someone making a case for that. I think I'd possibly support an HTML directive that allowed you to have a stricter same-origin policy (ie, restrict to current URL, or restrict to parent path).

At the same time, setting up subdomains that point to static directories is really stinking easy. And I am skeptical that any web host that refuses to use subdomains is going to care enough about security to opt-in to an even more aggressive scheme. A website that is hosting 3rd-party sites via userdirs is a website that will ignore or circumvent any security model you propose.

The public suffix list is yet another incomplete workaround for the security flaw in the same origin policy

No, the opposite. The public suffix list is a workaround for the flawed security model of cookies. In your focus on Javascript, you are missing the much bigger problem. See below:

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.

The same-origin policy is (overall) fine, the problem is that the old web security model didn't have it. So we are trying to retroactively build a modern security model based on strict, on-by-default isolation on top of a flawed security model that assumed every single domain would be owned by a single entity. Cookie "contexts" are a lot broader than modern definitions of "origins". They can be inherited from parent domains, they can be trivially shared across domains without user consent. And they also aren't by-default isolated across userdirs.

This has all turned out to be, broadly, a bad idea. While I don't think the same-origin policy is perfect, it's pretty obviously better than what we were using before. This is why you're seeing movement from the Chrome team to turn on SameSite isolation by default for cookies. Because we look back at the original web security model and realize that opt-in SameSite and randomized form-submit tokens for security were always a mistake.

All of this is dancing around that you mention that userdir URLs pre-date Javascript. To be clear, userdir URLs were inherently insecure from the moment they were conceived. You should not have been hosting websites this way, even before Javascript existed.

To the extent that people got away with this kind of thing before Javascript, it was only because userdir websites were so ridiculously limited that they often didn't have any serverside capabilities to respond to form submissions, or to run any kind of logic at all. To the extent that people weren't widely phished on userdir-hosted sites by fake forms with hidden fields that sent logic to parent origins or to other sites they were already logged into, it's only because the web was so young and so tiny that we were able to get away with bad security -- the same way that in a rural area I can get away with leaving my garage unlocked.

I'm not exactly happy with every decision modern browsers are making about the direction of web security, but I would challenge anyone to look at the history of CSRF mitigations and then say that the same-origin policy is not a universally better security model for Javascript to adopt.

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

Spivak2• 6 years ago

I think you’re ignoring the fact that the browser security model is based on a flawed definition of an origin that prohibits something that has very little reason not to work. Userdir sites weren’t/aren’t limited at all. If you dropped a php file into your directory it would run.

domain.suffix/full/path should have been the definition of an origin because people were literally using it as such. The default config of the most popular web server at the time was doing it. People hosted entirely different sites in subdirectories because it was really easy to just create a directory. TV ads directed people to www.blahblah/sitename.

The real definition of origins is clever since the path before the domain defines an origin path and everything after is owned by that origin. Neat and tidy for sure but broke userspace so to speak.

crtlaltdel• 6 years ago

noticing a lot of comments about how this is a “javascript” problem. i just want to clarify whether or not people are asserting this is a _language design_ issue, or an implementation of the runtime specifically within the context of web browsers and web servers?

is this a js problem?

adt2bt• 6 years ago

IMO, yes and no. The language design isn’t to blame. The libraries and runtime that are colloquially known as JS are. It’s hard to separate the two in discussion so the term js is a bit overloaded.

danShumway4• 6 years ago

No, it has very little if anything to do with Javascript. My charitable reading is that people are using JS as a colloquial term to refer to the Web as a platform in general.

To the extent that it's a browser problem at all, it's a problem with how browsers as a platform handle HTTP requests and site-isolation, which is a security system that predates Javascript.

temporallobe• 6 years ago

Thanks for pointing this out because I was just going to say the same thing. It’s most definitely not a Javascript problem, as Javascript is just a language, and nothing about the language design is inherently insecure. The problems are with the implementation of the browsers’ security mechanisms, some of which are indeed controlled via JS.

yoloClin6• 6 years ago

The issue is an injection attack. The ability to insert either unsanitised HTML data or data reflected inside the context of a JavaScript code block which results in JavaScript execution (by <script> tags, being able to specify data in DOM element events such as onClick or onError, or being able to specify code in onClick/onError events). I don't consider this a flaw in JavaScript itself, rather how JavaScript is harnessed from HTML.

Once JavaScript execution is obtained* it's possible to inject a JavaScript keylogger and/or rewrite the DOM to request authentication details from the victim (resulting in credential compromise). Alternatively, it's possible use AJAX to perform GET/POST requests to the same domain, routed through the victims browser which includes all cookies etc - effectively this is a time-boxed account compromise (CSRF controls do not apply when requests are executed from the local domain).

It's also possible to coerce a browser into triggering the exploit in a hidden iframe on a completely different page (eg you browse to evil.com, there's a hidden iframe which exploits an XSS vulnerability on facebook.com, compromising your facebook account if your currently logged into facebook on the exploited browser). I'm pretty sure samesite=strict only fix this if the XSS vector on facebook.com requires the user to be authenticated prior to exploitation, similarly, samesite=lax will not prevent attacks which require authenticated POST primitives.

*I'm a pentester, so that's sometimes my job, I don't break laws.

hn_throwaway_992• 6 years ago

The modern web stack is a security house of cards, as demonstrated.

Perhaps, but I feel like major recent changes are fixing most of these vulnerabilities:

1. Content Security Policy locks down most of the vulnerabilities that result from something on a page being able to contact something from a different origin. Of course, it's not set by default and these days requires a lot of trial and error to figure out the "right" way to set it, but it solves a lot of issues.

2. On the cookie front, the recent changes to the default SameSite behavior also pretty much end CSRF bugs.

pdimitar• 6 years ago

Would you provide links elaborating your both points? I haven't kept myself up to date with the web's security and I'm curious how those two problems were solved.

objectified• 6 years ago

1. Like you already hinted at, it is really difficult to get right, and I hardly experience any larger website (with multiple teams working on it) that implement it effectively. So while it's great in theory, I'm not sure if it's accessible enough (and therefore effective enough) for most of the world.

2. I'm assuming you're talking about Chrome's SameSite value; it's worth to note that this has been rolled back a short while ago because of compatibility issues in larger government organizations having to be accessible especially now with COVID-19. More info here: https://9to5google.com/2020/04/03/chrome-rolls-back-cookie/

LunaSea• 6 years ago

This is demonstrably false.

HTML is based on XML and even if you remove JavaScript, you could still create XML tags and attributes that lead to malicious behaviour and information leaks.

Want to guess which vulnerability jumped from not being in the OWASP top 10 to being in the 4th place? XML External Entities (XXE).

hhas01• 6 years ago

HTML is based on SGML. XML is a subset of SGML. XHTML is HTML converted to valid XML. IANAE, but I suspect most problems originate with SGML, which was designed for flexibility and extensibility rather than security. That’s compounded by the sprawling complexities of both HTML and XML that easily masks weaknesses and holes and makes implementation very hard to verify. Road to Hell, etc.

johnklos• 6 years ago

Ridiculous. The solution isn't to call public_html bad. The solution is to encourage people who are going to run things like webmail and other sites with Javascript like that to use a specific virtualhost for webmail.

indymike2• 6 years ago

Would be nice if we included a path in the spec for single origin. It's almost as if the spec was designed to kill off public_html style share hosting... either that or talk the control panel software people into using subdomains instead of paths for userdirs.

zemnmez• 6 years ago

you could fix this pretty effectively with the Content-Security-Policy: sandbox header, which would just deny all same origin policy access

epx• 6 years ago

It made me nostalgic, my (static) webpage was like/~that in 1995 or so.

Groxx• 6 years ago

Sure, if you're running entirely separate systems behind each username.

But in that case this has been true since XHR first came into existence 15-20 years ago: https://en.wikipedia.org/wiki/XMLHttpRequest (sub)domains are a fundamental requirement for web security, they essentially always have been.

mrslave• 6 years ago

Today we have affordable wildcard CA-signed SSL certificates (thanks Let's Encrypt!) so there's no excuse for not following https://username.host/ structures.

jefftk• 6 years ago

Summary: host user pages as username.example.org instead so browsers will consider them to be separate origins

chc4• 6 years ago

User-specific subdomains have their own set of problems too. This is why, for example, GitHub Pages switched their hosting from username.github.com to username.github.io - even with HTTPSOnly cookies, you can still set cookies for other subdomains.

https://github.blog/2013-04-05-new-github-pages-domain-githu... and https://github.blog/2013-04-09-yummy-cookies-across-domains/ are relevant

hannob• 6 years ago

Have you read the post?

It specifically mentions that and even names github.io as an example.

zelon88• 6 years ago

I would argue that the root issue you're describing which leads to XSS on the same host is allowing un-sanitized input leading to code injection.

It is entirely possible to design your own application which uses unique userdirs without using any of Apache's built in functionality that are completely immune to XSS because it is not possible for any of the users to place malicious scripts on the server.

Likewise it is also entirely possible to build a web app that doesn't use userdirs at all in any form for anything and still be vulnerable to XSS because of underlying input sanitization or code injection problems.

So whatever you're going to do, just do your homework and do it well.

mister_hn• 6 years ago

So maybe 90% of academic websites are built in this way

torstenvl• 6 years ago

What? No. mod_userdir is not dangerous. The resulting URLs are not dangerous.

Having multiple unrelated unvetted outside users with the ability to make your server serve arbitrary JavaScript is dangerous. The route you take to get there is kind of beside the point.

If anything, mod_userdir is helpful in that it's obvious when content is under the control of a different user. Perhaps browsers should treat x.com/~x/ as a different server from x.com/~y/ for XSS purposes.

65102• 6 years ago

When roboform was still popular a lot of its users had it fill out username and password automatically.

mcintyre1994• 6 years ago

I didn’t know about the public suffix list, that’s a cool idea to maintain as a community resource. Nice!

dvfjsdhgfv• 6 years ago

This is not a problem of userdir but of Javascript. Userdir is older, then JS arrived and introduced many kinds of vulnerabilities, then some of these have been addressed, with mixed results. With userdir you're perfectly fine if you don't use JS.

perlgeek• 6 years ago

No danger if ~username/ can only contain static pages. No tokens to be stolen etc. in XSS scenarios.

kalonis• 6 years ago

(I am so glad the title is not "Userdir URLs considered harmful".)

frobozz• 6 years ago

Most Userdir URLs like that just go to 404 pages anyway. That is the bigger problem.

singularity2001• 6 years ago

what about https://example.org/+rm+-rf+/ ?

BiteCode_dev• 6 years ago

The title makes it look like the problem comes with the "~username" URLS naming scheme, while it really comes from any features that let the user host static files they upload AND link somewhere else on your website.

The site take the example of apache mod_sites, but alone it's not enough. You need apache mod_sites, and the ability inject a link served by it somewhere else.

Well, yes. If you let user input anything and then inject it anywhere in your website, it's a security whole. Not a surprised.

So if you let your users host entire application on your website, and let other users of your website visit those applications. Well, I mean, sure it's a problem.

The best sandbox is the one you don't need to use.

masswerk2• 6 years ago

I actually do not understand, why this hasn't been addressed over all those years. As far as the evaluation of origin is concerned, we may easily implement something like:

If the path field of a URL contains a tilde directory, do the following: 1) split the path after the tilde directory, 2) add the first part to the host field, 3) use the second part as the new path field.

If there are any concerns regarding compatibility, make it opt-in via a HTTP header field.

tgv• 6 years ago

The tilde is just a convention. There are also sites that map it to /home/<user> or something. Perhaps extending the Accept-Origin headers could work.

But the basic message is: don't expect any protection from cross-directory script attacks, so use domain names for anything serious.

boomlinde• 6 years ago

Not really a problem if the host only serves static content. Author argues that there still is what I guess could be called a phishing vector:

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.

It is really without limitations possible that one user could show the webpage of another user in a manipulated way, but for a static site that is true whether it can be done dynamically because they share domain or because the phisher can simply read your site content, copy and manipulate it.

Alex3917• 6 years ago

While this issue should be obvious to anyone knowing basic web security, I have never seen it being discussed publicly.

It was discussed here: https://news.ycombinator.com/item?id=15141594

I'm still of the opinion that there should be an RFC around tilde urls, making it official that they're for hosting static content that isn't vouched for by the owner of the main domain. This has been an important part of our culture for decades, and it should be formally recognized and codified so that people can do it in a secure way.

Userdir URLs like https://example.org/~username/ are dangerous

Related Stories