Hacker News Reader

Hacker News

Comment by nickip | Hacker News Reader

Full thread

nickip

What would the fix for this be? Enabling CORS only for `https://garage.vn.teslamotors.com`?

View on HN

CORS won't do it, because it protects the response target, not the response source.

CSP would do the trick, though.

The other fix is properly escaping things before sticking them in your markup.

> The other fix is properly escaping things before sticking them in your markup.

Or simply not displaying user data using a markup language with built-in remote code execution.

Well, yes, there are various levels of "thinking outside the box" here that could be applied.

In addition to properly escaping inputs, Content Security Policy Headers to restrict the hosts that the browser executes JavaScript from (e.g., script-src). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

Sanitization of the text input (e.g. < becomes <, > becomes >, etc). This is automatic/implicit on a lot of modern web frameworks (since text and Html are distinct types and output to a page are treated differently, with text sanitization being implied unless you opt out).

You shouldn't ever be running untrusted JavaScript. Content Security Policy and similar are just extra layers of protection if you mess up.

Not the input, the output. There are some good comments on this thread about the distinction.

Case in point: the owner altered the vehicle's name using the vehicle's own UI (which is probably not browser based). That input gets stored in the database. Then another system, web-based, wants to display it. If you don't encode the output, you'll be exposed.

Never trust that the input is properly encoded. HTML encode it before display, always.

This pedantism only makes sense if you stop reading five words in, ignore the rest of that same sentence, and ignore the context.

I'm not going to address it because it wasn't made in good faith and adds no value to the actual (rather than imagined) discussion.

> pedantism

Sorry, I can't help myself: pedantry

That would be a good first step, but more importantly making sure any content is rendered in a safe way. In this instance safe means making sure HTML entities are properly encoded and escaped.

There is no reason why an internal interface needs to be in a browser, or a browser with access to the internet.

There's no reason why it shouldn't be either.

The page being discussed is accessed by Tesla garages all over the country (and potentially internationally), creating a web app on an intranet site makes a lot of sense (for single point of update, single point of support, and the ability to run across diverse user devices). Particularly as the raw data always need to come from Tesla's HQ either way.

As to if the same garage machine should also have access to the internet, I cannot speak to that, it depends what else it is being used for (e.g. showing customers Tesla's public facing website for example, accessing third party vendor's inventory systems, research, etc).

No platform is immune from insecure usage. Not desktop software. Not terminal emulators. Not even mobile apps. That's particularly true when the context you're stealing information from is the same as the context you're attempting to run evil code.

I’m saying a network namespace or equivalent should isolate the browser from being able to access external IPs or non-whitelisted IPs, if the browser can also access internal systems.

A separate browser instance should be used for accessing external links, preferably with JIT disabled, with a file system namespace or equivalent disabling access to much of the file system.

But okay, nothing is secure according to you.

sanitize the output of the car name field so that any html tags are escaped.

Reply on news.ycombinator.com