Comments 44
Ну… Компания Apple не виновата.Нет, ну, а почему бы не сделать обработку tel как у всех? Есть еще и сторонние браезеры, кроме safari. Что-то мне сомнительно отсутствие вины Apple в данном случае…
Здесь, скорее, оплошность разработчиков приложений, которые не обрабатывают tel ссылки.
Имхо это называется перекладывать с больной головы на здоровую. Если нужно было какому-то приложению разрешить делать звонок без подтверждения нужно было сделать флажок в Info.plist — т.о. разработчик выставив такой флажок явно бы указал, что он в курсе, что теперь схема tel будет обрабатываться без подтверждения (нестандартно).
Формально Apple, конечно же, подстраховалась, видимо в надежде, что её любимые пользователи будут клясть фейсбуки и гмэйлы.
Но зная Apple, вот такая отмазка совершенно не укладывается в их «заботу о пользователях».
Что мешало добавить метод делегата, например, -(BOOL)showDefaultTelAlert:, возвращающий по дефолту Yes, который любой разработчик при желании сможет переопределить и реализовать собственное поведение, а для ленивых будет вылетать стандартный алерт?
Но зная 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>
Если такая же дыра, то прошу шоколадку от смс-агрегаторов.
Максимум, что может сделать ссылка sms: — открыть приложение, отвечающее за отправку смс с номером телефона.
Даже сообщение указать нельзя.
Здесь больше информации
Даже сообщение указать нельзя.
Здесь больше информации
Хотя нет, можно использовать ссылку вида
<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.
twitter.com/i_bo0om/status/491783079912951809
Просто оставлю это здесь.
Просто оставлю это здесь.
То есть вы предполагаете, что любой разработчик, который хочет использовать webView, должен сам догадаться прочитать документацию на какие-то трижды ненужные ему ссылки, которые описаны в совершенно другой части документации? Или просто штудировать developer.apple.com/*?
UPD Только заметил, что перевод. Все претензии к автору оригинала.
P.S. И почему ярлычок перевод не сделать на всю ширину страницы, чтобы заметно было?
UPD Только заметил, что перевод. Все претензии к автору оригинала.
P.S. И почему ярлычок перевод не сделать на всю ширину страницы, чтобы заметно было?
Все-таки отчасти — это вина Apple. Именно компания, предоставляющая среду для разработки приложений должна следить за всеми возможными вариантами выйти за рамки безопасности.
tel:// это далеко не самая «advanced» фича. Разработчики о ней знают.
Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.
Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.
UFO just landed and posted this here
Автор, у вас классный перевод, раз в комментариях многие даже не заметили, что это не собственное исследование. Да и сам я тоже только дочитав до комментариев увидел, что статья переводная.
А по делу. Не подскажете, USSD отправляется таким образом? Я к сожалению без устройства, сам поглядеть не могу, но интересно.
А по делу. Не подскажете, USSD отправляется таким образом? Я к сожалению без устройства, сам поглядеть не могу, но интересно.
На android что-то похожее было. Вроде можно было вайпнуть телефон такой ссылкой. Кстати, надо попробовать сервис-коды, хотя бы тот же *#06#.
Была уязвимость в фирменной оболочке Samsung еще на 2.x версиях, лечилось установкой альтернативного лаунчера.
Вот этот пост вы, видимо, имели ввиду.
На минуточку, это не только у iOS такое поведение, но и у всея OSX — только что попоробовал: например VK Messager (при включенной настройке «открывать внешние ссылки в программе») при клике очень даже пытается позвонить через любой устанновленный VoIP (например Skype, Zoipper). Правда скайп звонить отказывается — но это лишь потому, что разработчики плевать хотели на пользователей — как обработчик tel:// скайп зарегистрировался, а вот обрабатывать не хочет
Возможно я что-то не понимаю, а зеродей то в чем состоит?
Телефон превращается в кирпич? Он рутуется? На него ставится троян? Пользователь не может прервать звонок?
Телефон превращается в кирпич? Он рутуется? На него ставится троян? Пользователь не может прервать звонок?
Скажите, а у вас какое-то свое определение 0day уязвимостей?
Вот вам кусочек википедии:
Вот вам кусочек википедии:
0day (англ. zero day) — термин, обозначающий вредоносные программы, против которых еще не разработаны защитные механизмы или уязвимости, которые не устранены.
Яж написал «возможно я что-то не понимаю»…
хотя на википедии, чуть дальше в этой статье написано:
«После обнаружения уязвимости в программном обеспечении начинается процесс разработки вредоносного кода, использующего обнаруженную уязвимость для заражения отдельных компьютеров или компьютерных сетей.»
А в той цитате, что привели Вы, указан термин «вредоносные программы». Гуглплюс, гмэйл, фейсбукмесенджер трудно считать вредоносными программами. Ситуация повторяет попап окна десятилетней давности. А ведь никто тогда это не считал зеродеем, хотя инет тогда зачастую был небезлимитным
хотя на википедии, чуть дальше в этой статье написано:
«После обнаружения уязвимости в программном обеспечении начинается процесс разработки вредоносного кода, использующего обнаруженную уязвимость для заражения отдельных компьютеров или компьютерных сетей.»
А в той цитате, что привели Вы, указан термин «вредоносные программы». Гуглплюс, гмэйл, фейсбукмесенджер трудно считать вредоносными программами. Ситуация повторяет попап окна десятилетней давности. А ведь никто тогда это не считал зеродеем, хотя инет тогда зачастую был небезлимитным
Если использовать вызов из нативного кода, то звонить будет без предупреждения и диалога:
А если, как в вашем примере из html:
То будет диалог:
Дело тут в том, что установленные приложения проходят ревью и подозрительные вызовы из нативного кода отслеживаются на этапе проверки приложения перед публикацией в applestore.
А вот пройти ревью с такими вызовами в коде это, скорее всего не просто.
Так что, я думаю это просто так задумано (WAD — work as designed)
В перечисленных вами приложениях в нативные вызовы подставляется внешний url, что, на мой взгляд, является недоработкой разработчиков приложений.
Другие примеры вызовов приложений (sms, maps, youtube) можно посмотреть, например, тут
[[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://
Как спроектировано так и работает, никаких уязвимостей.
Для набора без диалогового окна tel://
Как спроектировано так и работает, никаких уязвимостей.
Sign up to leave a comment.
0day уязвимость в приложениях для iOS: Gmail, Google+ и FB Messenger