11 ms·

are dangerous

155 points by hannob 7y ago

mholt 7y ago
-
- mchristen 7y ago
  Nitpick, but all of those you mentioned are shared with other tenants, just pick your layer of abstraction.
- bsagdiyev 7y 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.
vortico 7y 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 7y 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 7y 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.
- indymike 7y 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 7y 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_hn 7y ago
  For Bob to trust Alice not to do something dumb like installing something and never updating it is another matter though.
  - kccqzy 7y 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.
    - tinus_hn 7y ago
      > won’t affect other people Except what the article is about; because all sites are on the same domain and origin all sites security affects all other sites security. A page on one site has the right to manipulate all pages on another site. > Even the web server is centrally managed and the user only provides static HTML In other news php has suddenly ceased to exist and javascript is no longer a thing. Sorry, handwaving the problem away does not work.
- Polylactic_acid 7y 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
  - 7y ago
RandomGuyDTB 7y 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.
- jlgaddis 7y 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 https://wordpress.org [1]: https://web.archive.org/web/20160129215921/http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/ https://web.archive.org/web/20160129215921/http://www.forbes... [2]: https://wordpress.org/about/ https://wordpress.org/about/
  - RandomGuyDTB 7y 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 7y ago
The tildeverse has some words for you
- Polylactic_acid 7y ago
  Those sites have no backend code so there isn't really much risk of cookies being shared.
renewiltord 7y 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 7y ago
  Ah, a sensible take on security. Refreshing.
  - deleted 7y ago
    [deleted]
- herpderperator 7y 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 7y 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.
  - arkanciscan 7y ago
    You obviously never saw my Pokemon fansite from 1998
- strenholme 7y 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.
redstripe 7y 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.
- strenholme 7y ago
  https://www.bambora.com/en/us/ 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.
  - deleted 7y ago
    [deleted]
rlpb 7y 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.
- vortico 7y 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 7y 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...
    - kick 7y 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. X was the solution to the problem MIT had, and as such, the problem X was trying to solve. It worked very, very well for what it was trying to solve. How we ended up with billions of people able to interact with an app that we can all build at home seems insane... Java. Java did this. On billions of devices! Everywhere from your smart card to the mainframe. Before Java, Dis! Before Dis, Forth! Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook.
      - 7y ago
johnklos 7y 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.
- indymike 7y 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 7y ago
you could fix this pretty effectively with the Content-Security-Policy: sandbox header, which would just deny all same origin policy access
deleted 7y ago
[deleted]
epx 7y ago
It made me nostalgic, my (static) webpage was like/~that in 1995 or so.
Groxx 7y 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 https://en.wikipedia.org/wiki/XMLHttpRequest (sub)domains are a fundamental requirement for web security, they essentially always have been.
mrslave 7y 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/ https://username.host/ structures.
jefftk 7y ago
Summary: host user pages as username.example.org instead so browsers will consider them to be separate origins
deleted 7y ago
[deleted]
chc4 7y 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-github-io/ https://github.blog/2013-04-05-new-github-pages-domain-githu... and https://github.blog/2013-04-09-yummy-cookies-across-domains/ https://github.blog/2013-04-09-yummy-cookies-across-domains/ are relevant
- hannob 7y ago
  Have you read the post? It specifically mentions that and even names github.io as an example.
zelon88 7y 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 7y ago
So maybe 90% of academic websites are built in this way
torstenvl 7y 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.
6510 7y ago
When roboform was still popular a lot of its users had it fill out username and password automatically.
mcintyre1994 7y ago
I didn’t know about the public suffix list, that’s a cool idea to maintain as a community resource. Nice!
dvfjsdhgfv 7y 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 7y ago
No danger if ~username/ can only contain static pages. No tokens to be stolen etc. in XSS scenarios.
kalonis 7y ago
(I am so glad the title is not "Userdir URLs considered harmful".)
frobozz 7y ago
Most Userdir URLs like that just go to 404 pages anyway. That is the bigger problem.
singularity2001 7y ago
what about https://example.org/+rm+-rf+/ https://example.org/+rm+-rf+/ ?
BiteCode_dev 7y 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.
masswerk 7y 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 7y 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 7y 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 7y 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 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.

155 points by hannob 7y ago

mchristen 7y ago
Nitpick, but all of those you mentioned are shared with other tenants, just pick your layer of abstraction.
bsagdiyev 7y 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.

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 7y 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 7y 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.
indymike 7y 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 7y 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_hn 7y ago
For Bob to trust Alice not to do something dumb like installing something and never updating it is another matter though.
- kccqzy 7y 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.
  - tinus_hn 7y ago
    > won’t affect other people Except what the article is about; because all sites are on the same domain and origin all sites security affects all other sites security. A page on one site has the right to manipulate all pages on another site. > Even the web server is centrally managed and the user only provides static HTML In other news php has suddenly ceased to exist and javascript is no longer a thing. Sorry, handwaving the problem away does not work.
Polylactic_acid 7y 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
- 7y ago

RandomGuyDTB 7y 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.

jlgaddis 7y 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 https://wordpress.org [1]: https://web.archive.org/web/20160129215921/http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/ https://web.archive.org/web/20160129215921/http://www.forbes... [2]: https://wordpress.org/about/ https://wordpress.org/about/
- RandomGuyDTB 7y 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 7y ago

The tildeverse has some words for you

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

renewiltord 7y 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 7y ago
Ah, a sensible take on security. Refreshing.
- deleted 7y ago
  [deleted]
herpderperator 7y 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 7y 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.
- arkanciscan 7y ago
  You obviously never saw my Pokemon fansite from 1998
strenholme 7y 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.

redstripe 7y 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.

strenholme 7y ago
https://www.bambora.com/en/us/ 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.
- deleted 7y ago
  [deleted]

rlpb 7y 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.

vortico 7y 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 7y 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...
  - kick 7y 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. X was the solution to the problem MIT had, and as such, the problem X was trying to solve. It worked very, very well for what it was trying to solve. How we ended up with billions of people able to interact with an app that we can all build at home seems insane... Java. Java did this. On billions of devices! Everywhere from your smart card to the mainframe. Before Java, Dis! Before Dis, Forth! Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook.
    - 7y ago

johnklos 7y 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.

indymike 7y 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 7y ago

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

deleted 7y ago

[deleted]

epx 7y ago

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

Groxx 7y 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 https://en.wikipedia.org/wiki/XMLHttpRequest (sub)domains are a fundamental requirement for web security, they essentially always have been.

mrslave 7y 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/ https://username.host/ structures.

jefftk 7y ago

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

deleted 7y ago

[deleted]

chc4 7y 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-github-io/ https://github.blog/2013-04-05-new-github-pages-domain-githu... and https://github.blog/2013-04-09-yummy-cookies-across-domains/ https://github.blog/2013-04-09-yummy-cookies-across-domains/ are relevant

hannob 7y ago
Have you read the post? It specifically mentions that and even names github.io as an example.

zelon88 7y 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 7y ago

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

torstenvl 7y 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.

6510 7y ago

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

mcintyre1994 7y ago

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

dvfjsdhgfv 7y 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 7y ago

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

kalonis 7y ago

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

frobozz 7y ago

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

singularity2001 7y ago

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

BiteCode_dev 7y 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.

masswerk 7y 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 7y 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 7y 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 7y 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 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.