Hacker News Reader

Comment by chrisjc | Hacker News Reader

Is putting scripts in a phone number field (or any input field) a well known way to hijack requests? I mean when someone is trying to compromise a site, is this one of the first things they try?

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?

View on HN

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

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.

While what you're saying is true and what I said is not what is actually happening, I don't think you understood what I was trying to describe. And even though that's the case, I may still be wrong.

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.

> might it actually be wide-spread across the entire iOS and mac OS code-base?

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.

Framework libraries or languages that have types for separating taintable data from executable code.

It isn't really so much about data being "taintable", but rather about the fact that not all strings are really the same "type". In this case, the field was probably meant to be "plain text", but it was inserted into HTML without any conversion. Even data that doesn't come from a user (ie: that is not "tainted") needs to be converted to the correct type.

There’s certainly not any inbuilt browser sanitation that prevents you entering XSS or other injection attacks into input fields. Thank goodness. If there was, how could you discuss examples in web forums like this? Or use a webpage to edit code?

XSS and other injections are not problems with data input, they are problems of data output.

Well we are discussing it now with no issue, so clearly the browser could (or could have, probably too late now) picked a sensible default

Imagine Stack Overflow, but without code snippets. Sounds more like an idea for an art project.

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.

That's another way of saying "all code input must be escaped" :-)

Adding a flag to allow people to write stackoverlow is perfectly reasonable, the default should not allow non-expert programmers to waltz into issues like this.

This isn't "expert" level knowledge. This is a basic principle of any client / server system.

In fact, including default client side protections would not have fixed this issue (since this issue involved bypassing client side protection.)

The sensible default is to allow arbitrary text input and pass it on correctly encoded to the next system.

Which is what browsers do.

Browsers aren't doing anything differently because the people who write browsers happen to understand the threat model.

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.

Trying to sanitize on the input side reminds me of Cisco’s fix for a vulnerability in their routers that involved disallowing requests with a user agent containing “cURL”.

I'm not suggesting that it prevent you from being able to enter specific strings of characters. I think I made that clear by comparing this to a SQL injection issue. After all, how would SQL sites and forums discuss SQL without being able to store and display SQL excerpts?

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.

That's not at all what's happening here. It doesn't even have anything to do with input fields, except that the field in the HTTP request that stores the information on Apple's servers was supposed to be filled from one.

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.

Ah! I was actually struggling to understand how inputs had anything to do with it. I thought the input was being rendered with some pre-populated/injected value that in this case was the script.

    <input><script.../></input>

Then again, if they were able to inject something into the input, chances are they could inject it anywhere, so as you said it has nothing to do with input fields.

Thanks for the clarification.

The input field isn’t the problem here. In fact the article even mentions that you need to hijack the request and alter the phone number. So I guess the Apple engineer that created this feature fell for the same misunderstanding that you did: user input can never be trusted, even when validated client side. You always have to do service side validation!

Just to be clear, i wasn't suggesting that client-side validation was the issue.

See my response above.

https://news.ycombinator.com/item?id=28697485

The problem here is not input, it’s output. Apple’s web backend is spitting out strings without escaping them to HTML, which is a real novice error at this point in the web’s evolution. Sanitising inputs in browsers would be a nightmare of never ending complication.

Actually you can't "sanitize" inputs as you can't know upfront in which context this data will end up.

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!

> Is putting scripts in a phone number field (or any input field) a well known way to hijack requests?

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.

Is putting scripts in a phone number field (or any input field) a well known way to hijack requests?

It’s on the front page of Hacker News with clickbait headline, so yeah.

Reply on news.ycombinator.com