9 ms·

> 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 wo

by 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.
    - owl57 7y ago
      Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook. Sufficiently young people probably suspect these were called netbooks as some joke. They run Emacs just fine and without constantly swapping, but a web browser?
      - hedora 7y ago
        They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. If not, they can’t even run JavaScript ads, because apparently ads like to refresh the screen with a static image at 60fps. Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) The web really sucks at everything other than network effects.
        otabdeveloper4 7y ago
        > They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. Hardware acceleration makes things slower, not faster. > Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) You're nuts. Software rasterizers keep up with DOS games just fine, even on an old 386. It's the fact that they're trying to use Javascript and other garbage-collected or object-oriented languages to code these rasterizers.
  - lazyier 7y ago
    If X-windows wasn't complete garbage at actually providing remote applications then it may have had a chance.
    - klodolph 7y ago
      Being complete garbage didn’t stop JavaScript either :/ At least JS had the excuse of being designed and implemented by a single developer in three weeks. X Windows was part of Project Athena, a $50 million project from MIT, DEC, and IBM with a five-year schedule.
      - kick 7y ago
        X worked great for what it was aiming to do. It's not even bad for really remote applications. It works really well, just don't use a dozen layers of poorly-designed abstraction. Write something with xcb or xlib, and you'll get instantaneous response from the other side of the planet. Here's a nice little article from 1989 telling just how great it was for the time: https://simson.net/clips/1989/1989.TechRev.Athena.pdf https://simson.net/clips/1989/1989.TechRev.Athena.pdf
        klodolph 7y ago
        Eh, that’s a nice fluff piece but doesn’t match my understanding or experiences working with X. Once X had more widespread adoption in the 1990s you started to see a lot more hate. The layers of abstraction are there because X is such a godawful piece of shit. Sure, your application will be fast if you only use XCB or Xlib (and XCB is just a modern replacement for Xlib, made because of how deeply flawed Xlib is, and it can’t even fully replace Xlib). But few people are willing to put in the blood, sweat, and code to write something that is pure X. So if X worked great for what it was aiming to do, it was aiming to do the wrong thing.
        kick 7y ago
        X was hated when it got widespread adoption because people began using it for things it wasn't intended for. X was aiming to do the right thing. Sure, if you're using it to connect to a box in Canada over a satellite connection in Johannesburg during 1995 with countless abstractions, you're going to have a horrible time. Use the right tool for the job.
- pwdisswordfish2 7y 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).
  - wutwutwutwut 7y ago
    Using DNS TXT to solve a XSS issue? That's clearly another card added to the house.
  - yoloClin 7y ago
    IMO, using DNS for anything other than hostname lookups is a complete hack. I'm looking at you, SPF.
    - pbhjpbhj 7y ago
      It's a reasonable hack though. Where else do you put "how to interact with this domain" data, you can't serve that data (eg via http) because clients need to already know how to interact with that domain before they interact with that domain? How would you do it?
      - yoloClin 7y ago
        Transport encryption with PKI.
- yoloClin 7y 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.
  - squiggleblaz 7y ago
    > 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) I have had a hard time convincing co-workers that if you have php generating sql generating (! yes!) html generating javascript, you need to escape the string for javascript since it's embedded in javascript. Then you need the string escaped for html since it's embedded in html. Then you need the string escaped for sql since it's embedded in sql. Only then can you chuck it into the middle of the string. It is better to not do such craziness; but once you've decided to do such craziness, you must do it properly. The similarities between js and mysql escaping are irrelevant; it must be escaped properly each time it is embedded in another language.
    - benibela 7y ago
      Escape characters are one of the most stupid things in the computing world. The formats could be so simple: first the length of the data, then raw data of that length
- 6510 7y 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 7y 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 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".
  - cryptonector 7y ago
    Yes, the server signing its scripts would do it, provided the server doesn't blindly sign attacker-submitted code. Some servers might...
  - yoloClin 7y ago
    Secrets stored in cookies really shouldn't be accessible, the Set-Cookie HttpOnly flag should stop all JS access to a cookie. The HttpOnly flag still submits a cookie when you do an ajax GET/POST, but you cannot access the cookie via document.cookie or similar. There's also external resource integrity checks which prevent modification of third party resources without breaking the local site. jQuery CDN code snippets do this by default: https://code.jquery.com/ https://code.jquery.com/ . You can't trust one script to access a cookie without trusting all scripts to access the same cookie though - while I can see some merit to the idea when it comes to hiding secrets from XSS/untrusted code, I'd say that in most (99.9%) situations effort would be better spent actually implementing CSP and good data sanitation rather than caring about implementing JavaScript level trust models.
- twic 7y 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 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.
  - dwb 7y ago
    This is not true; a URL with anything past the port is not a valid "origin" https://tools.ietf.org/html/rfc6454#section-7 https://tools.ietf.org/html/rfc6454#section-7
    - joosters 7y ago
      I think their point was that the concept could be expanded as per their suggestion, as a simple way to fix the security issues. Having the server send a 'this is my site base' header would be helpful even without having path support. At the moment, browsers need to magically know about all multi-level domains, like example.co.uk, so that they don't lump together all *.co.uk domains as the same site.
      - twic 7y ago
        Yes, this was my meaning - apologies if i wasn't clear.
  - couchand 7y ago
    This is brilliant and simple and backwards-compatible. Well done. If I knew anything about the standards process I would write an RFC for it today.
- hamilyon2 7y 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
  - ergothus 7y ago
    Isnt that contrary to the point of urls?
- jlgaddis 7y ago
  Pretty much all modern web servers support per-user virtual hosts using wildcards that allow for URLs like http://username.users.example.org/ http://username.users.example.org/ (instead of http://users.example.org/~username/ 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_ModEVhost#Samples https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Mod...
vbezhenar 7y 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.
- justinsteven 7y 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
  - vbezhenar 7y ago
    What about setting Cookie with Path and SameSite=LAX? I would expect it to prevent sending cookies in that request, although I did not test it.
    - justinsteven 7y ago
      I tested with SameSite being Lax and Strict. Neither block the attack in Chrome. My reading of the SameSite spec indicates that it doesn't take cookie path into account.
- k1t 7y 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.
  - budgi4 7y ago
    No, but you could redirect your root requests to example.com/home and serve from there with relevant cookies restricted to the /home path.
danShumway 7y 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-origin_policy https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...
crtlaltdel 7y 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?
- danShumway 7y 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.
- adt2bt 7y 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.
- temporallobe 7y 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.
- yoloClin 7y 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_99 7y 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 7y 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 7y 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/ https://9to5google.com/2020/04/03/chrome-rolls-back-cookie/
  - hn_throwaway_99 7y ago
    1. It's not really hard to get right, it just takes a lot of trial and error. I.e. you essentially start with the default-src as 'self', and then create exceptions to other resources as you need them. You use the report-uri/report-to endpoints to get reports if either (a) you've neglected to open up a resource you need, or (b) you DO have a vulnerability that someone is trying to take advantage of. While this may sound like a bit of a pain, e.g. if you have multiple teams working on a website that all need to access their set of 3rd party endpoints, this pain is required for good security: it forces you to be explicit about the 3rd party endpoints you allow, instead of the browser just allowing any endpoint for things like script tags, imgs, etc. which is the default now. 2. Note what Chrome is rolling back is the SameSite default change. SameSite has existed for quite some time now, in all browsers, it's just that the default is currently 'None' in Chrome but is changing to 'Lax'. So you can still take advantage of this now, it's just Chrome is delaying changing the default so that it doesn't break sites who aren't prepared for the default change. So my point is the tools currently available really tighten up the sandbox guarantees of the browser, and make it no more difficult than necessary to build a secure site.
LunaSea 7y 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 7y 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.

by rlpb 7y ago

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.
  - owl57 7y ago
    Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook. Sufficiently young people probably suspect these were called netbooks as some joke. They run Emacs just fine and without constantly swapping, but a web browser?
    - hedora 7y ago
      They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. If not, they can’t even run JavaScript ads, because apparently ads like to refresh the screen with a static image at 60fps. Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) The web really sucks at everything other than network effects.
      - otabdeveloper4 7y ago
        > They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. Hardware acceleration makes things slower, not faster. > Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) You're nuts. Software rasterizers keep up with DOS games just fine, even on an old 386. It's the fact that they're trying to use Javascript and other garbage-collected or object-oriented languages to code these rasterizers.
- lazyier 7y ago
  If X-windows wasn't complete garbage at actually providing remote applications then it may have had a chance.
  - klodolph 7y ago
    Being complete garbage didn’t stop JavaScript either :/ At least JS had the excuse of being designed and implemented by a single developer in three weeks. X Windows was part of Project Athena, a $50 million project from MIT, DEC, and IBM with a five-year schedule.
    - kick 7y ago
      X worked great for what it was aiming to do. It's not even bad for really remote applications. It works really well, just don't use a dozen layers of poorly-designed abstraction. Write something with xcb or xlib, and you'll get instantaneous response from the other side of the planet. Here's a nice little article from 1989 telling just how great it was for the time: https://simson.net/clips/1989/1989.TechRev.Athena.pdf https://simson.net/clips/1989/1989.TechRev.Athena.pdf
      - klodolph 7y ago
        Eh, that’s a nice fluff piece but doesn’t match my understanding or experiences working with X. Once X had more widespread adoption in the 1990s you started to see a lot more hate. The layers of abstraction are there because X is such a godawful piece of shit. Sure, your application will be fast if you only use XCB or Xlib (and XCB is just a modern replacement for Xlib, made because of how deeply flawed Xlib is, and it can’t even fully replace Xlib). But few people are willing to put in the blood, sweat, and code to write something that is pure X. So if X worked great for what it was aiming to do, it was aiming to do the wrong thing.
        kick 7y ago
        X was hated when it got widespread adoption because people began using it for things it wasn't intended for. X was aiming to do the right thing. Sure, if you're using it to connect to a box in Canada over a satellite connection in Johannesburg during 1995 with countless abstractions, you're going to have a horrible time. Use the right tool for the job.
pwdisswordfish2 7y 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).
- wutwutwutwut 7y ago
  Using DNS TXT to solve a XSS issue? That's clearly another card added to the house.
- yoloClin 7y ago
  IMO, using DNS for anything other than hostname lookups is a complete hack. I'm looking at you, SPF.
  - pbhjpbhj 7y ago
    It's a reasonable hack though. Where else do you put "how to interact with this domain" data, you can't serve that data (eg via http) because clients need to already know how to interact with that domain before they interact with that domain? How would you do it?
    - yoloClin 7y ago
      Transport encryption with PKI.
yoloClin 7y 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.
- squiggleblaz 7y ago
  > 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) I have had a hard time convincing co-workers that if you have php generating sql generating (! yes!) html generating javascript, you need to escape the string for javascript since it's embedded in javascript. Then you need the string escaped for html since it's embedded in html. Then you need the string escaped for sql since it's embedded in sql. Only then can you chuck it into the middle of the string. It is better to not do such craziness; but once you've decided to do such craziness, you must do it properly. The similarities between js and mysql escaping are irrelevant; it must be escaped properly each time it is embedded in another language.
  - benibela 7y ago
    Escape characters are one of the most stupid things in the computing world. The formats could be so simple: first the length of the data, then raw data of that length
6510 7y 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 7y 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 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".
- cryptonector 7y ago
  Yes, the server signing its scripts would do it, provided the server doesn't blindly sign attacker-submitted code. Some servers might...
- yoloClin 7y ago
  Secrets stored in cookies really shouldn't be accessible, the Set-Cookie HttpOnly flag should stop all JS access to a cookie. The HttpOnly flag still submits a cookie when you do an ajax GET/POST, but you cannot access the cookie via document.cookie or similar. There's also external resource integrity checks which prevent modification of third party resources without breaking the local site. jQuery CDN code snippets do this by default: https://code.jquery.com/ https://code.jquery.com/ . You can't trust one script to access a cookie without trusting all scripts to access the same cookie though - while I can see some merit to the idea when it comes to hiding secrets from XSS/untrusted code, I'd say that in most (99.9%) situations effort would be better spent actually implementing CSP and good data sanitation rather than caring about implementing JavaScript level trust models.
twic 7y 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 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.
- dwb 7y ago
  This is not true; a URL with anything past the port is not a valid "origin" https://tools.ietf.org/html/rfc6454#section-7 https://tools.ietf.org/html/rfc6454#section-7
  - joosters 7y ago
    I think their point was that the concept could be expanded as per their suggestion, as a simple way to fix the security issues. Having the server send a 'this is my site base' header would be helpful even without having path support. At the moment, browsers need to magically know about all multi-level domains, like example.co.uk, so that they don't lump together all *.co.uk domains as the same site.
    - twic 7y ago
      Yes, this was my meaning - apologies if i wasn't clear.
- couchand 7y ago
  This is brilliant and simple and backwards-compatible. Well done. If I knew anything about the standards process I would write an RFC for it today.
hamilyon2 7y 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
- ergothus 7y ago
  Isnt that contrary to the point of urls?
jlgaddis 7y ago
Pretty much all modern web servers support per-user virtual hosts using wildcards that allow for URLs like http://username.users.example.org/ http://username.users.example.org/ (instead of http://users.example.org/~username/ 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_ModEVhost#Samples https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Mod...

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

justinsteven 7y 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
- vbezhenar 7y ago
  What about setting Cookie with Path and SameSite=LAX? I would expect it to prevent sending cookies in that request, although I did not test it.
  - justinsteven 7y ago
    I tested with SameSite being Lax and Strict. Neither block the attack in Chrome. My reading of the SameSite spec indicates that it doesn't take cookie path into account.
k1t 7y 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.
- budgi4 7y ago
  No, but you could redirect your root requests to example.com/home and serve from there with relevant cookies restricted to the /home path.

danShumway 7y 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-origin_policy https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

crtlaltdel 7y 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?

danShumway 7y 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.
adt2bt 7y 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.
temporallobe 7y 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.
yoloClin 7y 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_99 7y 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 7y 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 7y 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/ https://9to5google.com/2020/04/03/chrome-rolls-back-cookie/
- hn_throwaway_99 7y ago
  1. It's not really hard to get right, it just takes a lot of trial and error. I.e. you essentially start with the default-src as 'self', and then create exceptions to other resources as you need them. You use the report-uri/report-to endpoints to get reports if either (a) you've neglected to open up a resource you need, or (b) you DO have a vulnerability that someone is trying to take advantage of. While this may sound like a bit of a pain, e.g. if you have multiple teams working on a website that all need to access their set of 3rd party endpoints, this pain is required for good security: it forces you to be explicit about the 3rd party endpoints you allow, instead of the browser just allowing any endpoint for things like script tags, imgs, etc. which is the default now. 2. Note what Chrome is rolling back is the SameSite default change. SameSite has existed for quite some time now, in all browsers, it's just that the default is currently 'None' in Chrome but is changing to 'Lax'. So you can still take advantage of this now, it's just Chrome is delaying changing the default so that it doesn't break sites who aren't prepared for the default change. So my point is the tools currently available really tighten up the sandbox guarantees of the browser, and make it no more difficult than necessary to build a secure site.

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