14 ms·

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

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?

londons_explore 5y ago
> 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.
- gowld 5y ago
  Framework libraries or languages that have types for separating taintable data from executable code.
  - xenomachina 5y ago
    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.
jameshart 5y ago
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.
- deleted 5y ago
  [deleted]
- mhh__ 5y ago
  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
  - avian 5y ago
    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.
    - deleted 5y ago
      [deleted]
    - gowld 5y ago
      That's another way of saying "all code input must be escaped" :-)
      - deleted 5y ago
        [deleted]
    - mhh__ 5y ago
      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.
chmod775 5y ago
> 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.
- chrisjc 5y ago
  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.
ctdonath 5y ago
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.
afavour 5y ago
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.
- still_grokking 5y ago
  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_Evasion_Cheat_Sheet.html 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!
planb 5y ago
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!
- chrisjc 5y ago
  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 https://news.ycombinator.com/item?id=28697485
rjmunro 5y ago
> 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.

londons_explore 5y ago

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

gowld 5y ago
Framework libraries or languages that have types for separating taintable data from executable code.
- xenomachina 5y ago
  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.

jameshart 5y ago

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.

deleted 5y ago
[deleted]
mhh__ 5y ago
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
- avian 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - gowld 5y ago
    That's another way of saying "all code input must be escaped" :-)
    - deleted 5y ago
      [deleted]
  - mhh__ 5y ago
    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.

chmod775 5y ago

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

chrisjc 5y ago
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.

ctdonath 5y ago

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.

afavour 5y ago

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.

still_grokking 5y ago
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_Evasion_Cheat_Sheet.html 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!

planb 5y ago

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!

chrisjc 5y ago
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 https://news.ycombinator.com/item?id=28697485

rjmunro 5y ago

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