Comments 44
Ну… Компания Apple не виновата.
Нет, ну, а почему бы не сделать обработку tel как у всех? Есть еще и сторонние браезеры, кроме safari. Что-то мне сомнительно отсутствие вины Apple в данном случае…
Здесь, скорее, оплошность разработчиков приложений, которые не обрабатывают tel ссылки.
Имхо это называется перекладывать с больной головы на здоровую. Если нужно было какому-то приложению разрешить делать звонок без подтверждения нужно было сделать флажок в Info.plist — т.о. разработчик выставив такой флажок явно бы указал, что он в курсе, что теперь схема tel будет обрабатываться без подтверждения (нестандартно).
Формально Apple, конечно же, подстраховалась, видимо в надежде, что её любимые пользователи будут клясть фейсбуки и гмэйлы.
Но зная Apple, вот такая отмазка совершенно не укладывается в их «заботу о пользователях».
Что мешало добавить метод делегата, например, -(BOOL)showDefaultTelAlert:, возвращающий по дефолту Yes, который любой разработчик при желании сможет переопределить и реализовать собственное поведение, а для ленивых будет вылетать стандартный алерт?
Вообще верно сказано. По дефолту запилить алерты на все tel ссылки и все счастливы.
Лучше при первом вызове показывать алёрт: «Приложение блабла желает иметь доступ к телефону. Запретить? Разрешить один раз? Разрешать всегда?», как это сделано с доступом к гео-данным, контактам, камере и т.п.
И все будут счастливы.
В принципе не исключено что злоумышленнику в своем зловредном приложении можно перехватить UIAlertView и сделать выбор за пользователя.
Одной ночью я просто читал документацию о ссылках tel

Только на хабре можно встретить такой подход к отдыху.

P.S. Вот за что я люблю IT сообщество!
Не заметил перевод. Ну и хорошо, что не только!
Движемся в нужном направлении. =)
Ага, только не очень внимательно читал. По указанной ссылке на tools.ietf.org/html/rfc3966 мы видим пример:
<a href="tel:+1-212-555-0101">+1-212-555-0101</a>
Найдите разницу, что называется.

На платных номерах перед соединением идёт начитка об услуге и тарификации. Случайный дозвон со снятием средств вряд-ли возможен.
Я не знаком с iOS, но разве эта уязвимость не будет работать с USSD? Там возможно моментально списание средств.
Нет,
To prevent users from maliciously redirecting phone calls or changing the behavior of a phone or account, the Phone app supports most, but not all, of the special characters in the tel scheme. Specifically, if a URL contains the * or # characters, the Phone app does not attempt to dial the corresponding phone number.
Боюсь спросить про
<a href="sms:+3581234567">Send SMS to us </a>


Если такая же дыра, то прошу шоколадку от смс-агрегаторов.
Хотя нет, можно использовать ссылку вида
<a href="sms:+380930000000;body=Привет, как дела?">Кликни</a>
в iPhone (IOS 7) не подставляет body, если нет истории переписки. Ну а по ссылке, которую Вы предоставили, написано что не должно содержать текст или другую информации (или я предложение не правильно понимаю :)).
The sms scheme is used to launch the Messages app. The format for URLs of this type is “sms:”, where is an optional parameter that specifies the target phone number of the SMS message. This parameter can contain the digits 0 through 9 and the plus (+), hyphen (-), and period (.) characters. The URL string must not include any message text or other information.
Не должно, но текст подставляется, как Вы сказали ранее, если есть история переписки.
То есть вы предполагаете, что любой разработчик, который хочет использовать webView, должен сам догадаться прочитать документацию на какие-то трижды ненужные ему ссылки, которые описаны в совершенно другой части документации? Или просто штудировать developer.apple.com/*?

UPD Только заметил, что перевод. Все претензии к автору оригинала.

P.S. И почему ярлычок перевод не сделать на всю ширину страницы, чтобы заметно было?
Все-таки отчасти — это вина Apple. Именно компания, предоставляющая среду для разработки приложений должна следить за всеми возможными вариантами выйти за рамки безопасности.
tel:// это далеко не самая «advanced» фича. Разработчики о ней знают.
Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.
IOS 7.1.2
Fb Messanger.
автоклик не срабатывает. ручной — таки звонит без предупреждения

<script> document.location='tel://000'; </script>
говорит «страница пытается открыть сторoнний апп. разрешить?»

header('Location: tel://000') — звонит без вопросов…

Автор, у вас классный перевод, раз в комментариях многие даже не заметили, что это не собственное исследование. Да и сам я тоже только дочитав до комментариев увидел, что статья переводная.
А по делу. Не подскажете, USSD отправляется таким образом? Я к сожалению без устройства, сам поглядеть не могу, но интересно.
Спасибо!

Что касается USSD — еще в далеком 2012 году была уязвимость. Сейчас, к сожалению, все залатали.
К чьему сожалению? ;) Может к счастью )))). И без USSD, подобным можно создать кучу проблем.
Кстати, а что на других платформах, кто-нибудь проверял?
Извините, «по Фрейду» ошибочка вышла. :)

Что касается других платформ — на андроиде не работает, симбиан тоже. Остальные еще предстоит тестировать.
На android что-то похожее было. Вроде можно было вайпнуть телефон такой ссылкой. Кстати, надо попробовать сервис-коды, хотя бы тот же *#06#.
Была уязвимость в фирменной оболочке Samsung еще на 2.x версиях, лечилось установкой альтернативного лаунчера.
На минуточку, это не только у iOS такое поведение, но и у всея OSX — только что попоробовал: например VK Messager (при включенной настройке «открывать внешние ссылки в программе») при клике очень даже пытается позвонить через любой устанновленный VoIP (например Skype, Zoipper). Правда скайп звонить отказывается — но это лишь потому, что разработчики плевать хотели на пользователей — как обработчик tel:// скайп зарегистрировался, а вот обрабатывать не хочет
Возможно я что-то не понимаю, а зеродей то в чем состоит?
Телефон превращается в кирпич? Он рутуется? На него ставится троян? Пользователь не может прервать звонок?
Скажите, а у вас какое-то свое определение 0day уязвимостей?

Вот вам кусочек википедии:
0day (англ. zero day) — термин, обозначающий вредоносные программы, против которых еще не разработаны защитные механизмы или уязвимости, которые не устранены.
Яж написал «возможно я что-то не понимаю»…

хотя на википедии, чуть дальше в этой статье написано:
«После обнаружения уязвимости в программном обеспечении начинается процесс разработки вредоносного кода, использующего обнаруженную уязвимость для заражения отдельных компьютеров или компьютерных сетей.»

А в той цитате, что привели Вы, указан термин «вредоносные программы». Гуглплюс, гмэйл, фейсбукмесенджер трудно считать вредоносными программами. Ситуация повторяет попап окна десятилетней давности. А ведь никто тогда это не считал зеродеем, хотя инет тогда зачастую был небезлимитным

Понимаете-ли, тут трактовать по разному можно.
Заражением можно считать возможность выполнения сторонним софтом (давайте считать html страницу — софтом) каких-либо операций (вызова необходимого номера телефона) на устройстве.
То есть, в общем случае, посещение произвольной html страницы, с возможностью её не посещать, является заражением?
Если использовать вызов из нативного кода, то звонить будет без предупреждения и диалога:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:
@"tel:1-555-555-5555"]];

А если, как в вашем примере из html:
<a href=”tel:1-555-555-5555″>1-555-555-5555</a>

То будет диалог:


Дело тут в том, что установленные приложения проходят ревью и подозрительные вызовы из нативного кода отслеживаются на этапе проверки приложения перед публикацией в applestore.
А вот пройти ревью с такими вызовами в коде это, скорее всего не просто.
Так что, я думаю это просто так задумано (WAD — work as designed)

В перечисленных вами приложениях в нативные вызовы подставляется внешний url, что, на мой взгляд, является недоработкой разработчиков приложений.

Другие примеры вызовов приложений (sms, maps, youtube) можно посмотреть, например, тут
Для набора телефона с предварительным диалоговым окном, есть адрес telprompt://
Для набора без диалогового окна tel://
Как спроектировано так и работает, никаких уязвимостей.
если что-то работает как спроектировано, то уязвимость еще может быть следствием плохого проектирования ;)
Only those users with full accounts are able to leave comments. Log in, please.