Вы используете устаревший браузер!

Страница может отображаться некорректно.

Кухня

Кухня

Другие выпуски этой рубрики (48)
  • добавить в избранное
    Добавить в закладки

Не только вредно, но и полезно

Прочитали: 5259 Комментариев: 56 Рейтинг: 163

25 апреля 2017

Из года в год не утихает противостояние исследователей, заявляющих о найденных багах, вызывающих как минимум конец света, и компаний-разработчиков, которые со своей стороны утверждают, что описанное исследователями находится в пределах нормы. «Это не баг, это фича!» — утверждают в таких случаях разработчики.

Справка

Фича (от англ. feature – особенность, свойство, признак) – некий функционал, не описанный, но имеющийся в приложении или устройстве. Особенность поведения или функционирования, не влияющая на работу основного (описанного в документации) функционала.

Как правило, фичи появляются в результате неполной проработки ситуаций, в которых будет работать программа, в том числе и в зависимости от поведения пользователя. Скажем, возможность копать снег смартфоном – вполне даже полезная иногда фича :-)

Баг, в свою очередь – это отклонение от описанного или предполагаемого функционала. Например, ситуация, когда или программа работает не так, как предполагалось, или с ее помощью выполняются действия, для которых она не предназначена.

Также баги возникают в результате ошибок при разработке и тестировании – в том числе из-за неполного охвата тестами всех возможных ситуаций, ошибок в библиотеках и т. д.

Баги (и уязвимости как их частный случай) существуют, наверное, во всех программах, кроме "Hello, word!", но значимость у них – самая разная. Дело в том, что далеко не всегда баг проявляется сам по себе. Скажем, для внедрения эксплойта может понадобиться полный доступ к компьютеру, да еще и с правами администратора. Но в этом случае (если уж злоумышленник получил такие права) зачем мучиться с эксплойтом, если вредоносное действие можно совершить «руками»?

И это – одна из причин, по которой некоторые баги могут не закрываться фирмами-производителями: их проявление в реальных условиях крайне маловероятно. Хотя, конечно, всякое случается…

Компания Microsoft отказалась выпускать патч для недавно обнаруженной уязвимости TCP/IP в Windows XP и Windows 2000. Один из ведущих менеджеров по безопасности программ Microsoft Эдриан Стоун заявил, что этот фрагмент исходников слишком стар, имеет возраст от 12 до 15 лет, и разобраться в коде на этом уровне «просто нереально» [backporting that level of code is essentially not feasible].

http://www.securitylab.ru/news/385475.php?pagen=6

Однако рассмотрим серьезный пример:

Google отказалась устранять баг на странице входа в учетную запись Google (https://accounts.google.com/ServiceLogin?service=mail), связанный с параметром continue. Более того, корпорация заявила, что не считает этот баг уязвимостью, сообщает исследователь по безопасности Айдан Вудс (Aidan Woods), который сообщил компании о найденной ошибке и получил ответ.

Добавление параметра continue в URL сервера Google.com позволяет при правильном введении пароля перенаправить пользователя в тот сервис Google, в который он намеревался войти.

Для того, чтобы избежать фишинговых ссылок, Google ограничила работу параметра continue серверами в домене google.com. Таким образом, редирект может выполниться, например, на drive.google.com или docs.google.com, но не может на example.com. Айдан Вудс нашел способ, как это ограничение обойти. Баг, по мнению Вудса, заключается в том, что сервер Google никак не проверяет безопасность ссылки, указанной после параметра amp, а также в том, что ссылка может быть любая, на любой сайт в мире (иначе смысл технологии нарушается).

Примечательно, что в блоге Google Webmasters представители компании еще в 2009 г. написали, что не считают открытый редирект с сайта Google.com уязвимостью.

http://www.cnews.ru/news/top/2016-08-31_google_otkazalas_ustranyat_uyazvimost_na_stranitse

Фича? Фича. Но баг ли? Вот это вопрос. Технология изначально предназначена для удобного перехода между ресурсами, Может она использоваться и для перехода между ресурсами партнеров. Внедрение механизма регуляции доступа потребует не просто доработки технологии (скорее всего, в этом случае она не так уж и сложна), но, возможно, породит новые баги. Например, в случае использования некоей внутренней базы ресурсов – возможность их подмены.

Действительно, вышеописанное – отличная возможность для фишеров, но по сути, чтобы противодействовать этой уязвимости, нужно просто не забывать старый добрый совет: не кликать по ссылкам в подозрительных письмах. А если кликать, то никакие усилия Google не спасут.

#терминология #технологии #эксплойт #уязвимость #настройки_Dr.Web #Родительский_контроль

Антивирусная правДА! рекомендует

Если кто-то заявляет о чудодейственном лекарстве, скором наступлении конца света и т. п.– не поленитесь выслушать аргументы противоположной стороны. Верить любым заявлениям точно не стоит, поскольку в случае с информационной безопасностью:

  • важен не баг, а наличие работающего эксплойта – т.е. технологии реализации бага;
  • возможно, цена исправления бага слишком высока и может исчисляться миллионами. Окупится ли исправление такого бага, если вероятность его использования злоумышленниками мала? И если нет — есть ли смысл тратить средства на его устранение?

Отличная новость для пользователей Dr.Web Security Space: для защиты от перехода на вредоносный ресурс есть Родительский контроль Dr.Web и его черные списки (все помнят, что недавно компания «Доктор Веб» смогла вдвое уменьшить объем базы черных списков без потери эффективности?)

Оцените выпуск

Сделайте репост

Необходимо войти на страницу выпуска через аккаунт на сайте «Доктор Веб» (или создать аккаунт). Аккаунт должен быть связан с вашим аккаунтом в социальной сети. Видео о связывании аккаунта.


Нам важно ваше мнение

Чтобы оставить комментарий, нужно зайти через свой аккаунт на сайте «Доктор Веб». Если аккаунта еще нет, его можно создать.

Комментарии пользователей

Комментарии к другим выпускам | Мои комментарии

 
На страницу: