ГлавнаяНовостиСтатьиКаталогВендорыСтандартыОбучениеКонтакты  +7 (495) 231-4831    © 


[ Список статей ] ...


С-Терра СиЭсПи. Защита удаленного доступа. Доверенный сеанс связи

CNews. Fortinet включает защиту уровней доступа в систему обеспечения ИБ

CNews. ИТ-подразделениям всё труднее контролировать корпоративные данные в «облаке»

Jammer.ru. Apple следит за своими поль-зователями через Yosemite

Lenta.ru. Разоблачение «Корпорации добра»

Securelist. Доставка от спамеров: опасность гарантирована

Lenta.ru. Интернет-Мерфи

3DNews. Сноуден как повод

Компьютерра. Plug&Pray: скрытая атака через USB

SecurityLab. Как я взломал роутер

Securelist. Дыры в защите корпоративной сети: облачные сервисы

Андрей Козенко, Султан Сулейманов. «Не понимают, как работает интернет»

Евгений Золотов. Windows 8.1: ставка на PC (а PC харкает кровью)

Евгений Царев. Впечатление от PHDays 2013 или кто заказчик кибербезопасности в России?

Олег Парамонов. Десять страхов: крах интернета, Big Data, утрата знаний и другие вещи, которые пугают учёных и футурологов

Brian Donohue. Альтернативные браузеры с улучшенной защитой

Андрей Васильков. Десять лучших пакетов офисных программ

Securelist. Спам в марте 2013

Бёрд Киви. Специалисты предупреждают...

Андрей Шуклин. Big Data: новый рынок, новые перспективы

Luis Corrons. Twitter, Facebook, Apple, Microsoft… кто следующий?

Елена Гореткина. Роль ИТ в повышении конкурентоспособности российских университетов

Сергей Бобровский. Кому сегодня выгодна борьба с пиратством и кто в нём виноват?

Алексей Лукацкий. 1 сентября в отрасли ИБ может наступить коллапс...

Олег Парамонов. Десять перспективных технологий, о которых через несколько лет узнают все

Михаил Емельянников. СМС-оповещения о движении средств по счету: всегда ли это безопасно

Евгений Золотов. Мрачные итоги Pwn2Own: почему браузеры так легко взломать и почему линуксоидам можно волноваться меньше?

xakep.ru. Криминалистический подход к анализу временных атрибутов файлов в операционной системе семейства Microsoft Windows и файловой системе NTFS

Securelist. Спам в январе 2013

Pandalabs. По данным Pandalabs, в 2012 году была инфицирована треть мирового числа компьютеров

Евгений Золотов. Цифровые теракты: страшная сказка становится былью

Leyre. Безопасный Интернет-серфинг

Лаборатория Касперского. Операция 'Red October' — обширная сеть кибершпионажа против дипломатических и государственных структур

Юрий Михайлов. Пять древних поисковиков, которые не перевернули мир (не считая Lycos)

Алексей Лукацкий. ИБ в год Змеи. Прогнозы и перспективы

Panda Security. Уязвимости будут основной целью киберпреступников в 2013

Лаборатория Касперского. Дед Мороз:Мошенник или волшебник?

Vision 2030. Информационная безопасность в 2030 году: прежними останутся только люди

Андрей Колесов. 2012-й — юбилейный год отечественного ИТ-рынка

PC-Week. Обновление до Windows 8: ответы на наиболее часто задаваемые вопросы

Лаборатория Касперского. Факты года: TOP 5 ужасов Рунета

CRN. 10 важнейших событий 2012 года в сфере безопасности

Емельянников M.. Панегирик выставочному бизнесу [в области информационной безопасности]

Черевко С.А.. Аспекты и перспективы развития информационной безопасности мобильных устройств

Uncr0wneD. Крэкинг: практика взлома и теория защиты

3dnews. Вы не любите одноразовые пароли? Тогда мы идём к вам!

Luis Corrons. Правда ли, что там опубликованы мои откровенные фотки?..

Популярная механика. Как убить интернет

Vasilis Pappas, Michalis Polychronakis, Angelos D. Keromytis. Устранение гаджетов: противодействие возвратно-ориентированному программированию путем рандомизации кода на месте

Специалист «Лаборатории Касперского». miniFlame, он же SPE: «Элвис и его друзья»

Steve Durbin. Большие возможности — большие риски

Л.Бесцветный. Три дня InfoSecurity Russia глазами обычного человека

Мария Наместникова. Спам в августе 2012 года

Исследовательский центр "Лаборатории Касперского" (GReAT). Полный анализ командных серверов Flame

AV-Comparatives. AV-Comparatives Июль 2012: Тестирование проактивной защиты антивирусов

Ana Etxebarria. Интернет-груминг: орудие педофилов

Лукацкий Алексей. Какой была безопасность в 90-х годах?

Юрий Наместников. География киберпреступлений. Западная Европа и Северная Америка

Роб Шапланд. Методы защиты от brute-force login attack

Евгений Касперский. Что в виндовсе тебе моём?

SecurityLab. Эксперты: Малые и средние компании под угрозой хакерских атак

Доктор Веб. Обзор вирусной активности в августе 2012 года: растущие ботнеты, уязвимость Java и новые угрозы для Android

Panda Security. Подростковый секстинг: бегущие по лезвию

Дарья Гудкова и Мария Наместникова. Спам во втором квартале 2012

Евгений Касперский. Сейф для денег

PandaLabs. Ежеквартальный отчет PandaLabs

Юрий Наместников. Развитие информационных угроз во втором квартале 2012 года

Наталья Анищук. Защита от DDoS-атак: поле для творчества и фантазии

Ной Шахтман. Парадокс Евгения Касперского

WhatsBetter.ru. Что лучше: Windows 7, Vista или XP?

WhatsBetter.ru. Какой антивирус лучше?

Илья Шабанов. Названы самые комфортные в работе антивирусы

Мария «Mifrill» Нефедова. Облава: о том, как спецслужбы ловят дропов, и не только

Алексей Кадиев. Ботнет Bredolab. Конец истории?

Юрий Ильин. «Добровольные» DDoS-атаки: комментарии экспертов

Александр Панасенко. Угрозы в сфере информационной безопасности: итоги 2010 и прогнозы на будущее

Берд Киви. За кулисами кибервойны

Берд Киви. Шифровальщик устал...

Chad Perrin. Эффективное уничтожение данных на жестких дисках и других накопителях

Н.Н. Федотов. Риски системного администратора: семь и еще один способ подвести сисадмина под монастырь

Берд Киви. Ближе к железу

Microsoft TechNet. Десять непреложных законов безопасности

Анатолий Темкин. Как карта ляжет

Андрей Сидельников. Правообладатели не придумали, как делить болваночный сбор

Антон Носик. Лохотрон в зоне .рф

Максим Букин. Лжевирусы атакуют

habr.ru. Взгляд на современные системы защиты от спама веб-форм

Кристиан Функ. Мошенничество в онлайн-играх: развитие нелегальной игровой экономики

Роман Гольд. Stuxnet: война 2.0

Вячеслав Закоржевский. Лазутчики киберкриминала

Cio.com (перевод — Елена Фирсова). Самые опасные работы в области технологий

Берд Киви. Боевой червь Stuxnet

Юрий Машевский. Антивирусный прогноз погоды: облачно

xakep.ru. Как найти украденный ноутбук?

Евгений Асеев. Небезопасный интернет

Курт Баумгартнер. Фальшивые антивирусы: актуальные тенденции

Chad Perrin. Новый взгляд на безопасность Windows: побудит ли решение Google отказаться от продуктов Microsoft и другие компании?

Максим Букин. Безопасность виртуальных платежей

Наталья Касперская. Intel купил McAfee

Виталий Краснов. Хакеры атакуют: как уберечь DNS-сервер

Вадим Стеркин. Так ли страшен контроль учетных записей

Берд Киви. В постели со шпионами

Юрий Ильин. Zeus: вирус, который грабит банки

Виталий Краснов. Гонка вооружений антиспама нарастает

Валерий Марчук. Еще один 0-day в Microsoft Windows или Stuxnet атакует

Владислав Пономарев. Троянская война

Алехандро Мартинез-Кабрера. Стереть себя из Интернета невозможно

Ника Парамонова. Эпоха Windows XP закончилась

Владимир Жилинский. Аппаратные кейлоггеры

Берд Киви. Конфликт криптографии и бюрократии

Берд Киви. Человек против обмана

Мартин Пранкевич. На коротком поводке: ограничиваем пользователей, выслеживаем нарушителей и наводим порядок в локальной сети

Мэтью Саррел. Главные на данный момент угрозы безопасности

Татьяна Никитина. ТОР10 киберпреступлений, в которых Запад отыскал «российский след»

Берд Киви. Безмолвный очевидец

Наталья Касперская. Нужен ли пользователю интернет-паспорт?

Михаил Емельянников. Как защищать персональные данные в интернете

lifehacker.com. Как отличить одно вредоносное ПО от другого

Максим Букин. Как защититься от мобильных мошенников

habr.ru. Взлом сайта: простые советы по безопасности

Виталий Краснов. Бизнес под ударом: веб-приложения остаются «дырявыми»

Дарья Гудкова. Спам и закон

Николай Двас. Запад обвинил Россию в развязывании кибервойн

habr.ru. Узнаем пароли пользователей 1С

Анна Володина. Спам-реклама: дешево и эффективно?

arstechnica.com. Офисный копир — еще одна брешь в безопасности?

mail.ru. 10 самых опасных вирусов в истории Интернета

habr.ru. Ваш автомобиль в недалеком будущем может быть запросто взломан хакерами

Валерий Васильев. Текущее состояние ландшафта кибер-преступности

Артур Лоянич. Как украсть чужой пароль

habr.ru. Банкоматных вирусов пост

Андрей Сидельников. Цензура интернет-трафика становится обычной практикой

Берд Киви. Шпион в кармане

Юрий Машевский. CrimeWare: новый виток противостояния

THG.ru. Symantec: кризис киберпреступности не помеха

Георг Вишерски. Опасности на пути пользователей социальных сетей

Дмитрий Тараканов. За кем охотится ZeuS

Ольга Зайцева. Dr.Web 6.0: ищем изменения

Славик Маркович. Пять главных тенденций в области защиты данных в 2010 году

Дэвид Эмм. Как залатать человеческие уязвимости?

Максим Букин. «Левые» контракты и ошибочные счета

Валерий Васильев. Весна 2010: кибер-преступность и кибер-защита

Олег Зайцев. Интернет магазины — как не стать жертвой мошенников

marcofolio.net. Профилактика SQL-инъекций

Michael Kassner. Свободные адреса IPv4 почти закончились

Владимир Гайкович. Рынок ИБ — это взрослое существо в детской одежде

InfoWatch. Глобальное исследование утечек за 2009 год

habr.ru. Если пришла проверка

Леонид Черняк. Безопасность: облако или болото?

Мария Сысойкина. Internet Explorer 8: Безопасный или неуязвимый?

Александра Бершадская. Биометрическая идентификация: о надежности технологии

Валерий Васильев, Дмитрий Сергеев. Человек — самое слабое звено в ИБ

Иван Шадрин. Корпорации стали уязвимее для хакерских атак

Michael Kassner. Информационная безопасность: что год 2010-й нам готовит?

xakep.ru. 2009: cамые громкие дела ушедшего года

Tom's Hardware Guide. Резервирование и восстановление данных: обзор трёх решений для Windows 7

Игорь Бахарев, Андрей Ковалевский. Торрент потерял только имя

Павел Борисов. Пойман автор порноролика в Москве

Иван Шадрин. Фальшивые антивирусы научились запугивать пользователей

Андрей Крупин. Социальный бэкап

Иван Шадрин. Бизнес уходит в «облака»

Алексей Лукацкий. Информационная безопасность 2010

Андрей Крупин. Ещё раз о защите WiFi-сетей

Raymond.СС. Тестирование антивирусов на быстродействие (Raymond.CC, февраль 2010)

habr.ru. Распространенные заблуждения про банковские карточки

Максим Букин. Монетизация «зловредов»

Андрей Крупин. Киберугрозы: сценарий будущего по версии «Лаборатории Касперского»

Иван Шадрин. От программ-вымогателей можно избавиться вручную

George Kurtz. Операция «Aurora». Удар по Google и прочим

Алексей Алексеев. Как украсть мегабайт

Татьяна Фомичева. Вирус, ложь и видео

winblog.ru. Изучаем скрытые возможности Windows 7

VirusInfo. Кошелек или жизнь: деактивация троянов-вымогателей

Берд Киви. Сюжет из «Плейбоя»

Майор Мышкин. За что могут посадить компьютерщика?

Иван Шадрин. Скорая компьютерная помощь: мошенники по вызову

Андрей Колесов. Антивирусная атака Microsoft

Сергей Яремчук. Новый оборонительный рубеж: обзор популярных систем отражения локальных угроз

Борис Лихтман, Андрей Сидельников. Правительства берут интернет под контроль

Виталий Камлюк. Экосистема ботнетов

Мачей Жарек. %^ef$g73$5r(@&#!! — несколько слов о шифровании и алгоритмах

Андрей Крупин. Безопасность в Windows 7 во всех ракурсах

Дмитрий Копытин. Безопасность при межпроектном взаимодействии

habr.ru. Вы несете деньги в Банк, Банки несут деньги в Bitrix

Андрей Анненков, Ольга Федина. Чужая ОС — потемки, или Где купить XP

Валентин Маков. Сайтокрушение

Mark Russinovich. Миф о дублировании SID компьютера

itsec.ru. SSL-защита ваших данных

Андрей Крупин. Обзор Returnil Virtual System 2010

Лариса Погонина. Скандальное потепление

Андрей Родин. Наилучшая защита беcпроводных сетей

Рик Фэрроу. Переполнение буфера

Берд Киви. Атака c воздуха

Игорь Осколков. Google Chrome OS — это просто, быстро и безопасно!

Вячеслав Закоржевский. Лжеспасатели

katkovonline.com. Ботнет: «был твой — стал мой» или как ботнеты работают

Валерий Васильев. Защита персональных данных накануне 01.01.10

Michael Kassner. Десять способов обнаружения вредоносного ПО

Вадим Стеркин. Управление UAC в Windows 7 и Windows Server 2008 R2

Хайрук Сергей. Проверка на зрелость: сертификация средств антивирусной защиты

Brien Posey. Десять наиболее распространенных проблем, которые можно решить редактированием реестра

Наталья Касперская. Защита от утечек в малом бизнесе — неосвоенный кусок пирога!

SecurityLab.ru. Статистика уязвимостей web-приложений за 2008 год

habr.ru. Способы сокрытия IP-адреса в сети Internet

Дон Рейзингер. 10 аргументов, чтобы остаться на XP до выхода Windows 7 SP1

Николас Колаковски. Windows 7 завершит эпоху Windows XP

Марина Мякишева. Infosecurity 2009: под страхом ФЗ о персональных данных

Алексей Лукацкий. Психология и информационная безопасность

Евгений Зобнин. Устоять любой ценой: методы борьбы с DoS/DDoS-атаками

Дмитрий Чеканов. Режим Windows XP Mode и VirtualBox: когда без XP не обойтись

Кристиан Функ. Ловушки интернета

Игорь Крейн. Бесплатный антивирус Microsoft разгонит платных конкурентов?

Рашид Нургалиев. Электронный патруль

Дмитрий Дурасов. Forefront TMG Beta3: отчет о 3-х месячном тестировании

Джеймс Тернер. Особенности контроля учетных записей Vista

Кеннет Касс. Обратная сторона DLP

Валерий Коржов. Кризис, виртуализация и персональные данные

CNews. Виртуализация: Microsoft готовится к реваншу

Andy Smith. Результаты тестирования: Windows 7 RTM против Vista и XP

Андрей Крупин. Microsoft Security Essentials: антивирус не для всех

Владимир Безмалый. Технологии социальной инженерии

Алексей Стародымов. Возврат денег за ОС: первые результаты

habr.ru. Шнайер о проблеме деидентификации

Влад Чучко. Интервью с Натальей Касперской

Андрей Крупин. Новый подход к защите ПК от Symantec

Степан Ильин. 10 зло-вирусов. Самая нашумевшая малварь за последние 10 лет

Владимир Безмалый. Безопасность мобильных носителей информации

Максим Букин. «Зловреды» для мобильных пользователей

Валерий Васильев. Закон о персональных данных: «градус» обсуждения растет

Ольга Зайцева. Антивирусная защита: нужен второй эшелон

Владимир Безмалый. Автозагрузка в Windows 7

webplanet.ru. МГУ vs DDoS: «Мы даем защиту. Бесплатно.»

Дамир Диздаревич. Механизм хранения имен пользователей и паролей

Владимир Безмалый. BitLocker в Windows 7

Андрей Крупин. Kaspersky Internet Security 2010: территория безопасности

Игорь Крейн, Владислав Михеев. «ВКонтакте» с фишерами и без

Ryan Singel. Google против Microsoft

Дмитрий Евтеев. Анализ проблем парольной защиты в российских компаниях

Андрей Крупин. Первый взгляд на Microsoft Security Essentials

Ольга Зайцева. Нужны ли антивирусы пользователям Mac OS?

Алексей Стародымов, Марина Пелепец. Спам в ICQ: механизмы и способы защиты

Дарья Гудкова. Спамеры Рунета

Андрей Крупин. Microsoft Office 2010: первые впечатления

Вениамин Левцов, Илья Новиков. Защита персональных данных: откладывать больше нельзя

Debra Littlejohn Shinder. Десять причин, по которым Vista-ненавистникам может понравиться Windows 7

Джон Грин. Защита на последнем рубеже (сравнение корпоративных антивирусов)

Артем Рябинков. Усиливаем аутентификацию или зачем нужны одноразовые пароли

Кирилл Алехин. 15 вопросов про спам

xakep.ru. Hyper-V: технология виртуализации для Windows Server 2008

Андрей Колесов. О Cloud Computing замолвите слово

Алексей Стародымов, Марина Пелепец. Вирусы в банкоматах: заключение

Андрей Колесов. О порядке смены ОС

Андрей Крупин. Тонкая настройка Internet Explorer 8

InfoSecurity.ru. Боевые заслуги червя Conficker

Группа информационной безопасности Group-IB. Краткий аналитический вопросник по бот-сетям в РФ 2009 год

Аналитический центр InfoWatch. Глобальное исследование утечек 2008

Владимир Безмалый. Новые технологии, старые проблемы

Евгений Шахов. Круговая защита вашего ПК (сравнение продуктов Internet Security 2009)

John Markoff. Нам нужен новый Интернет?

Питер Брайт, arstechnica.com (перевод – xakep.ru). Windows 7: бета-экскурсия

Данил Анисимов. Утечки данных: текущий год уже обогнал прошедший?

Ольга Федина. Пароль «123456» знаешь? Проходи!

Вадим Ференец. Новый альянс на рынке ИБ делает первые шаги

Андрей Крупин. Секреты Windows 7 Beta

SecurityLab. Тенденции ИБ в условиях кризиса

Владимир Ульянов. Итоги 2008: самые необычные утечки

Марина Мякишева. Кибервойна: вирусные аналитики подводят итоги года

Сергей Гордейчик. Оценка рисков использования Web-приложений

Владимир Ульянов. Персональные данные на практике остаются беззащитными (на основании исследования «Персональные данные в России 2008»)

Денис Зенкин. Уничтожение данных: скрытая угроза растет

Chad Perrin. Десять самых распространенных ошибок в сфере компьютерной безопасности, которые ни в коем случае нельзя совершать

SecurityLab. Международная статистика уязвимостей WEB

Владимир Ульянов. Инсайд 2008: Самые громкие и самые глупые утечки

Прокофьев Никита. Обзор Kaspersky Internet Security 2009

SecurityLab. Сравнение программных пакетов Internet Security – 2008

Интервью с Владимиром Мамыкиным. Информационная безопасность Microsoft

Tom's Hardware Guide. Сравнение программ резервного копирования для рабочих станций

Владимир Безмалый. Контроль использования USB-накопителей в Windows Server 2008

Жан де Клерк. Изоляция угроз из Internet в Windows Server 2008 и Vista

Михаил Карпов. Windows 7: первые сведения о новой системе

Иван Стогов. Сравнительный анализ антивирусного ПО

Дмитрий Антиномов. Защитное ПО в России: секретно ли секретное?

Законодательство. Федеральный закон Российской Федерации № 152-ФЗ «О персональных данных»

Законодательство. Постановление Правительства РФ от 17 ноября 2007 г. N 781 «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных»

Winblog. Защита файлов паролем

Сабадаш Даниил. Обзор Nero 8

Дмитрий Соколов. Подпись для электронного документа

Денис Михайлов. Взлом и защита учетной записи Windows XP

Андрей Письменный. Тестирование антивирусов

Елена Панасенко. Сменные носители – главное орудие инсайдеров

Михаил Ратнер. Побеждаем вирусы в Vista без использования антивирусных программ

Николай Гребенников. Методы защиты конфиденциальных данных в современных решениях класса Security Suite

Николай Полевой. Шпионит ли Microsoft за обладателями Vista?

Григорий Рудницкий. Kaspersky Internet Security 7.0: первый взгляд

Исследование компании InfoWatch и портала Zoom.CNews. Безопасность мобильных устройств 2007

Николай Гребенников. Клавиатурные шпионы. Часть II. Варианты реализации кейлоггеров в ОС Windows

Николай Гребенников. Клавиатурные шпионы. Принципы работы и методы обнаружения

Виталий Денисов. Опасность безопасных соединений

Андрей Шипилов. «Битрикс» сливается с «1С»

Александр Астахов. Борьба с инсайдерами: подбираем амуницию

InfoWatch. Утечки 2006 - глобальное исследование от InfoWatch

Наталья Касперская. Безопасность от Microsoft: шаг к обновленному миру?

Александр Астахов. Как построить систему управления информационной безопасностью

Константин Черезов. Проблема внутри? Решение там же!

Михаил Пышкин. Международный опыт управления информационной безопасностью для российских компаний

Юрий Машевский. Кража собственности в компьютерных сетях

Интервью с Сергеем Груздевым. Сегмент AAA в России является самым быстрорастущим в ИБ

Алексей Сабанов. Обзор технологий идентификации и аутентификации

Алексей Сабанов, Антон Крячков, Константин Демченко, Сергей Белов. Как управлять закрытыми ключами

Александр Астахов. История стандарта BS 7799

Марат Давлетханов. Secret Disk для защиты корпоративных данных

Ника Комарова. Как защитить компанию от кражи баз данных

Марат Давлетханов. Концепция одноразовых паролей в системе аутентификации

Алексей Доля. Защита конфиденциальных данных на ноутбуках и КПК

Rainbow Technologies. UTM-устройства на страже компьютерной сети

Rainbow Technologies. Атаки на сеть через переполнение буфера – технологии и способы борьбы

Алексей Лукацкий. Предотвращение сетевых атак: технологии и решения

Rainbow Technologies. Технология Precise BioMatch™ - объединяя лучшее в биометрической аутентификации

Опрос. Хакеры и сетевые вандалы: разница в мотивации

Обзор. Безопасность популярных операционных систем в 2006 г.

Полезные советы. Кардинг или безналичный обман

Исследование. Социокультурный аспект внедрения некоторых категорий средств защиты в организациях с преимущественно женским контингентом

Обзор. Развитие вредоносных программ: уязвимости в MacOS X, 2005 — 2006 год

Евгений Касперский. Прогнозы изменений в антивирусной индустрии

Олег Гудилин. Проактивность как средство борьбы с вирусами

Виктор Дронов. Портрет заказчика спамерских услуг в России

Пол Даклин. Простые советы по более разумному выбору и использованию паролей

Круглый стол. Источник со стороны

СофтПоинт. Проблемы безопасности данных в системе 1С Предприятие 7.7 и MSSQL 2000

Алексей Лукацкий. Размышления о Web-студиях и защищенном сайте

Аналитика. Почему ВУЗ не способен подготовить специалиста по безопасности

Законодательство. Правительство РФ утвердило "Положение о лицензировании деятельности по технической защите конфиденциальной информации"

 Дмитрий Копытин 

Безопасность при межпроектном взаимодействии


  Сегодня множество интернет-сервисов взаимодействуют друг с другом через интернет. Особый класс взаимодействий — те, в которых осуществляется передача конфиденциальной информации (личные данные, секретные сообщения) или команд, выполнение которых должно быть кем-то однозначно подтверждено (например, перевод денег или публикация сообщения от чьего-то имени). Очевидно, что подобные сервисы должны быть надёжно защищены от злоумышленников.

Введение

Сегодня множество интернет-сервисов взаимодействуют друг с другом через интернет. Особый класс взаимодействий — те, в которых осуществляется передача конфиденциальной информации (личные данные, секретные сообщения) или команд, выполнение которых должно быть кем-то однозначно подтверждено (например, перевод денег или публикация сообщения от чьего-то имени). Очевидно, что подобные сервисы должны быть надёжно защищены от злоумышленников.

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

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

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

Безопасное взаимодействие

Итак, давайте определимся, что мы подразумеваем под словами «безопасное взаимодействие».

1. Аутентификация. Пусть сервер А хочет передать сообщение серверу Б. Б должен иметь возможность проверить, что сообщение отправлено именно от А. Данная проверка называется аутентификацией сервера А на сервере Б.

2. Целостность данных. Мы хотим быть уверены, что сообщение при передаче не было изменено (например, было оплачено 50$, а подтверждение получено на 500$).

3. Конфиденциальность взаимодействия. Данный пункт подразумевает, что сообщение получают только те стороны, которые имеют на это право. Как правило, данный пункт подразумевает шифрование информации при передаче.

В некоторых случаях можно рассматривать ещё два пункта: проверку прав доступа и невозможность отказа от авторства (non-repudiation), но сейчас мы оставим это в стороне.

Криптографические примитивы

Здесь необходимо сделать некоторое отступление в теорию. Я не буду подробно расписывать основы криптографии (иначе объём статьи выйдет за рамки разумного), но кратко упомяну основные «криптографические примитивы», чтобы обозначить знания, необходимые для понимания дальнейшей части статьи. Желающие могут пройти по ссылкам на Википедию и узнать подробности.
  • Существуют различные системы симметричного шифрования. Основа этих систем — один ключ К, который известен обеим сторонам. Данный ключ используется как для шифрования, так и для расшифровки сообщения. Примеры стандартов: RC2, RC4, RC5, DES, 3-DES, AES, Blowfish, ГОСТ 28147-89 и т. д.
  • Существуют асимметричные системы шифрования. Здесь каждая сторона имеет секретный ключ и открытый ключ. Открытый известен всем (в том числе, криптоаналитикам, желающим взломать систему), секретный — только одной стороне. Любой человек может использовать открытый ключ стороны А, чтобы зашифровать сообщение ДЛЯ стороны А. Расшифровать же это сообщение может ТОЛЬКО владелец секретного ключа, то есть А. Пример стандарта: RSA.
  • Как правило, открытый ключ распространяется в виде т. н. сертификатов. Вообще говоря, открытый ключ — только часть сертификата, но в дальнейшем я буду использовать эти термины как синонимы.
  • Эта же пара, секретный и открытый ключ, как правило, может использоваться для формирования цифровой подписи (ЦП). В этом случае, подобно тому, как в бумажном документе присутствует подпись человека, в тело электронного сообщения включается цифровая подпись, сгенерированная на основе сообщения и секретного ключа. Подпись невозможно сгенерировать без использования секретного ключа, но проверить её могут все, используя соответствующий открытый ключ. Таким образом мы можем убедиться в том, что сообщение отправлено именно нужным нам сервером или человеком, а не было «фальшивкой». Протоколы: RSA, DSA, ECDSA, ГОСТ Р 34.10-2001.
  • Существуют протоколы, которые позволяют двум сторонам сгенерировать общий ключ К, не передавая его по каналу. Примеры протоколов — Diffie-Hellman Key Exchange Protocol (далее для краткости просто Diffie-Hellman), SRP. Первый, к примеру, используется в популярной сегодня системе OpenID.
  • Существуют хеш-функции, сопоставляющие тексту набор бит фиксированной длины. Считается, что задача нахождения двух текстов, имеющих один и тот же хеш, «очень сложная». Примеры: MD5 (который уже «сломали»), SHA-1, SHA-256, ГОСТ Р 34.11-94.
  • Существуют коды Hash Message Authentication Code (HMAC). Это функция от сообщения и некоторого ключа, также дающая на выходе хеш-строку фиксированной длины. Если обе стороны обладают секретным ключом K, то можно использовать HMAC-функцию как способ формирования цифровой подписи в симметричной криптосистеме, так как сформировать и проверить подпись сообщения смогут только 2 стороны, имеющих ключ.

SSL/TLS и HTTPS

Говоря о «безопасности взаимодействия», можно задать резонный (в чём-то) вопрос: всё это: аутентификация, поддержка целостности, шифрование, есть в SSL/TLS (HTTPS). Зачем нужно что-то ещё?

Поэтому вторым экскурсом в теорию будет краткое напоминание того, что такое SSL/TLS и HTTPS.

Протокол SSL (Secure Socket Layer) и его «потомок» TLS (Transport Layer Security) был разработан в ответ на потребность в безопасном клиент-серверном взаимодействии. Протокол работает на транспортном уровне модели OSI. При грамотном использовании он позволяет установить шифрованное соединение между клиентом и сервером. Протокол защищён от модификации и чтения сообщений, отправляемых в обе стороны. Также протокол позволяет клиенту (повторюсь: при грамотном использовании) убедиться в том, что он установил соединение именно с нужным сервером, а не с сервером мошенника (другими словами, клиент может аутентифицировать сервер). Существуют модификации, которые позволяют пройти аутентификацию клиенту, т. е. обеспечить двустороннюю аутентификацию.

HTTPS (HTTP Secure) — это тот же HTTP, но отправляемый по каналу, защищённому протоколом SSL/TLS.

Очень важно понимать, что наличие SSL/TLS-канала в неполной реализации означает только то, что соединение между вашей точкой и удалённым сервером проходит по протоколу, хорошо защищённому с точки зрения прослушивания и подмены информации. Но это ничего не значит, пока вы не убедились, что удаленная сторона — именно та, с которой вы хотели связаться. Убедиться же в этом можно, только если сертификат удалённой стороны известен вам заранее, и вы ему доверяете, либо если тот же сертификат вы получаете по незащищённому каналу, но подписанный «третьей стороной», т. н. сертификационным центром (Certification Authority или CA). При этом открытый ключ CA, используемый для проверки подписи, опять же должен быть известен вам заранее, чтобы не пришлось его передавать по незащищённому каналу. К примеру, как обеспечивается эта безопасность в браузерах? Сертификаты основных CA (наиболее известные — COMODO, VeriSign, Go Daddy, Thawte и т. д., всего их несколько десятков), встраиваются в ваш браузер заранее.

А как осуществить проверку сертификата в коде своего сервиса? Если у вас есть сертификат заранее, сделать это довольно просто (например, PHP-программистам можно смотреть в сторону curl_setopt(), опции CURLOPT_CAINFO и CURLOPT_CAPATH). Именно подобным образом обеспечивается безопасность соединения в коде взаимодействия с сервером WebMoney. Если же вам заранее неизвестен CA-сервер, сделать подобную проверку на практике несколько сложнее, потому что вам придётся самим подбирать и поддерживать коллекцию сертификатов различных CA.

На практике проверку сертификата в коде часто не выполняют, что может привести к одной из двух атак: подмене сервера или атаке «Человек посередине» (Man in the Middle, MITM). Последнее означает, что между вами (А) и конечным сервером (Б) находится ещё один сервер (М). Вы (А) устанавливаете абсолютно защищённое соединение с М, думая, что установили соединение с Б. После этого М устанавливает безопасное соединение с Б и начинает передавать ему ваши запросы, а вам — его ответы. Таким образом, М может прослушивать взаимодействие А — Б и даже модифицировать передаваемые сообщения.

Логичен вопрос, насколько атаки подмены сервера и «Человек посередине» осуществимы на практике.

Скорее всего, если оба взаимодействующих сервера стоят в серьёзных дата-центрах (и если сами сервера, разумеется, не взломали), то осуществление такой атаки очень сложно. Если же сервер находится в вашей корпоративной, вузовской или домашней сети (спроектированной при этом не лучшим образом), то, скажем, ARP-атака вполне позволит злоумышленнику направить через себя весь трафик, входящий и выходящий из сети, и тогда все эти атаки становятся очень просто осуществимыми.

Итак, почему нас не всегда устраивает SSL/TLS.
  • Cложность проверки подлинности произвольного сервера в коде приложения. Как следствие — частичное использование протокола, без защиты от атаки «Человек посередине».
  • Односторонняя аутентификация (да, есть модификации протокола для двусторонней, но это используется реже, и не для всех языков программирования легко найти готовое решение).
  • Кроме того, архитектура SSL/TLS не позволяет сохранить сообщение с цифровой подписью отправителя с тем, чтобы позже использовать это для доказательства того, что сообщение действительно было отправлено автором (т. е. не работает защита от отказа от авторства).

Реализация безопасности на практике

Итак, давайте теперь вернёмся ненадолго к «безопасному взаимодействию» и посмотрим, как реализуются на практике обозначенные нами пункты.

1. Для аутентификации используют обычно либо пару «логин — пароль», либо цифровую подпись, сгенерированную тем или иным методом.

2. Для проверки целостности данных используют SSL/TLS и формируемые приложением цифровые подписи.

3. Для шифрования данных, то есть обеспечения конфиденциальности большинство систем используют SSL/TLS (есть примеры самостоятельного шифрования ключей, однако данные шифруют «своими» методами сравнительно редко).

Говоря о веб-сервисах, чаще всего SSL/TLS используют в виде HTTPS.

Типы защищаемых приложений

Перед тем как, наконец, перейти к атакам на протоколы, необходимо сказать об ограничениях, в которых работает проектируемая система. Я хотел бы упомянуть три основных типа приложений, для которых можно рассматривать вопросы безопасного взаимодействия.

1. Две взаимодействующих стороны имеют возможность заранее обменяться по гарантированно защищённому каналу необходимой информацией: общим ключом, сертификатами, паролями и проч. Таким каналом может быть очная передача необходимой информации между людьми (лучше всего), альтернативный канал связи (сотовая связь, телефон) или даже интернет — если обе стороны уверены в отсутствии «Человека посередине» или другого способа перехвата или модификации сообщения.

2. Централизованная архитектура. Каждые 2 стороны не имеют возможности договориться друг с другом заранее, но любой участник сети доверяет некоторой третьей стороне, которая подписывает сертификаты взаимодействующих сторон и гарантирует их валидность. В качестве примера можно назвать инфраструктуру открытых ключей (Public Key Infrastructure, PKI) или, с некоторыми оговорками, тот же интернет, в котором браузеры доверяют конечному числу сертификационных центров (CA), и на основе этого могут убедиться, что они взаимодействуют с нужным сайтом.

3. Децентрализованная архитектура. В подобных приложениях нет единой третьей стороны. Важно понимать, что в подобных архитектурах основная задача — убедиться в том, что во второй раз к вам пришёл тот же самый человек, что приходил ранее. То есть, в первый раз вы позволяете пройти аутентификацию кому угодно (например, на сайтах, поддерживающих OpenID, любой может пройти аутентификацию). Пусть далее вы сделали какой-то вклад в систему: например, написали сообщение. Когда вы придёте сюда в следующий раз, сайт должен будет предоставить вам (и только вам) доступ к редактированию этого сообщения. Примеры притоколов: OpenID, OAuth, протоколы Peer-to-Peer.

Атаки и способы защиты

Ну и, наконец, давайте рассмотрим основные типы атак, осуществляемых на протоколы — и как от них защищаются.

1. Отсутствие проверки авторства или подлинности сообщения

Позволю себе вспомнить старую шутку. В программировании существует два типа ошибок: отсутствие проверки входных данных — и все остальные ошибки.

Если вам пришло сообщение М от стороны А, то надо убедиться, что: а) сообщение действительно пришло от А; б) что А отсылал именно сообщение М, и оно не было изменено по пути.

Примером неграмотно спроектированного протокола является протокол взаимодействия платёжной системы Assist с интернет-магазином. После оплаты покупки на сервере Ассиста, пользователь возвращается по некоторому адресу URL_RETURN_OK, который передаётся в открытом виде и может быть модифицирован самим пользователем-покупателем. То есть, пользователь возвращается после оплаты покупки в наш интернет-магазин, ему говорят: «Спасибо, вы только что оплатили платёж на сумму 1000$», — но у магазина нет абсолютно никакой возможности убедиться в том, что это действительно так. Только позже, руками менеджера или автоматизировано (но не чаще 1 раза в 10 минут!) можно проверить, что платёж действительно прошел. Протокол Ассиста, к слову, не модифицировался уже более 4 лет. А всего-то надо — добавить цифровую подпись.

Итак, каким образом осуществляют проверку авторства и целостности сообщения.
  • Используют цифровые подписи на базе пары из секретного и открытого ключа. Вероятно, это самый надёжный и универсальный (т. е. работающий в любых условиях) способ. Открытый ключ может передаваться принимающей стороне заранее (подобный способ используют сегодня WebMoney, Cyberplat, OAuth и многие другие). Также открытый ключ может быть получен позже по незащищённому соединению и проверен при помощи сертификата сертификационного центра (Certification Authority, CA). Этот способ лежит в основе функционирования инфраструктуры открытых ключей (Public Key Infrastructure, PKI), используемой в крупных компаниях.
  • Формируют общий ключ К — например, на основе протокола Diffie-Hellman или аналогичного и используют его для подписывания сообщений (например, с использованием HMAC-SHA1). Используется в OpenID.
  • Если нам не важна целостность сообщения, а важно только подтверждение авторства, иногда используют пару «логин — пароль» или секретную строку для доступа к защищённому ресурсу. Например, Flickr отдаёт фотографии по протоколу XML-RPC в ответ на запрос, содержащий логин и пароль. Система reCAPTCHA позволяет проверить CAPTCHA-код, введённый пользователем, аутентифицируя проверяющего по секретной строке. Надо понимать, что этот способ, хотя и прост, крайне плох тем, что перехват сообщения раскрывает ваш пароль, и в дальнейшем злоумышленник может свободно отправлять запросы от вашего имени. В случае использования цифровой подписи перехват сообщения ничего не позволит сделать злоумышленнику.
  • Есть более простой (хотя и незащищённый от атак подмены сервера и «Человек посередине») способ проверки подлинности сообщения. Например, PayPal в своём протоколе Instant Payment Notification (IPN) обязывает сервер, принимающий подтверждение о проведённой оплате, отправлять копию сообщения обратно на сервер с вопросом «действительно ли ты мне это посылал»? Аналогичный способ используется в протоколе OpenID (правда, при работе в нерекомендованном режиме), только обратно отсылается не просто сообщение, а сообщение с цифровой подписью, и запрос выглядит уже как «проверь, ты ли ставил эту цифровую подпись». Похожая схема работает и в OpenAuth. Преимуществом подхода можно считать отсутствие необходимости реализовывать криптографические алгоритмы с одной или с двух сторон.
  • Робокасса придумала свой оригинальный способ формирования цифровой подписи: цифровая подпись формируется как хеш-функция MD5 от сообщения и секретного пароля. К данному способу надо относиться с осторожностью хотя бы потому, что пароль должен быть достаточно надёжен. Если пароль короткий, и, тем более, если он выбирается человеком, расшифровка вашего пароля может оказаться несложной задачей для хакера.

2. Надежда на надёжность HTTPS.

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

Ни один из протоколов децентрализованной аутентификации — будь то OpenID, OpenAuth, OAuth, не защищён от атаки подмены сервера или «Человек посередине». В некоторых случаях платёжные системы (PayPal, Assist) можно атаковать подобным способом. В итоге, вы можете убедить приложение интернет-магазина в том, что произошла оплата, хотя на самом деле её не было.

Подчеркну ещё раз, что от этой атаки можно защититься, если устанавливающий HTTPS-соединение сервер обладает достаточным количеством сертификатов основных CA Интернета (VeriSign, COMODO и т. д.), но на практике это иногда сложно реализуемо.

И подчеркну, что для децентрализованных систем это принципиально неразрешимая проблема. В то время как для коммерческих платёжных систем, относящихся по нашей классификации (см. выше) к системам, стороны которой могут «заранее договориться», данная атака предупреждается грамотным проектированием протокола. Пример подобной реализации показывает WebMoney, предоставляющий сертификат для проверки подлинности HTTPS-соединения. (Кажется, Chronopay тоже так делает — поправьте меня).

3. Атака «Человек посередине» (Man in the Middle, MITM).

Мы рассмотрели атаку MITM для протокола HTTPS. Однако, другие протоколы также могут быть уязвимы для такого типа атак.

Пример тому — Diffie-Hellman, использующийся в OpenID. Как указывалось выше, его суть в генерации общего ключа К двумя сторонами: А и Б. Но если у нас есть кто-то «посередине» (М), кто может изменять трафик, то может оказаться так, что А сгенерировал общий с М ключ К1, а Б — общий с М ключ К2. В итоге «Человек посередине» М может подписывать и читать любые данные, идущие в любом направлении.

Разумеется, подобная атака не пройдёт в OpenID, если клиент и сервер (OpenID Provider и Relying Party) взаимодействуют по HTTPS с полноценной проверкой сертификата.

4. Передача секретного ключа по открытому каналу.

Многие разработчики не понимают сути секретного ключа. Вся безопасность в инфраструктуре с использованием открытого ключа построена на том, что взаимодействующие стороны кому-то могут безоговорочно доверять. Второму серверу, третьей стороне — не важно. Как правило, вопрос «доверия» упирается в проверку цифровой подписи с использованием открытого ключа подписчика сообщения. Вся безопасность может рухнуть, если этот открытый ключ (сертификат) передаётся по незащищённому каналу и может быть по пути модифицирован.

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

Если вы создаёте протокол для платёжной системы, идеальным является передача открытого ключа вашего сервера лично в руки владельцу интернет-магазина (на дискете или флешке) при подписании договора в офисе. Да, по тем или иным причинам это не всегда реально осуществить. Поэтому сертификат часто распространяют через интернет. Но в этом случае надо предпринять все возможные меры по предотвращению подмены ключа. Нельзя присылать ключ по электронной почте. Нельзя давать его скачивать по HTTP — только HTTPS. На сайте должна быть размещена информация по проверке скаченной информации (например, хеш от ключа для проверки его подлинности).

5. Повторная отправка запроса.

Данный вид атаки мы рассмотрим на двух примерах.

Пример 1: платёжная система. Пусть я, добропорядочный сервер, хочу отправить 10$ через платёжную систему. При этом для соединения с сервером платёжной системы я использую HTTP или «плохой» HTTPS (без проверки сертификата). Я честно формирую запрос и подписываю его своим сертификатом. Другая сторона получает запрос, и мои 10$ уходят адресату. Но поскольку я использовал открытый протокол, злоумышленник смог прочитать мой запрос к серверу. Если этот злоумышленник хочет меня разорить, он берёт и отправляет тот же самый запрос серверу платёжной системы ещё раз. Сервер проверяет подпись (она верная, так как сформирована «правильным» сервером), и другие 10$ списываются с моего счёта.

Пример 2: протокол OpenID. В протоколе OpenID Authentication 1.1 была следующая уязвимость. Если злоумышленник прослушивал взаимодействие OpenID-клиента (Relying Party) и конечного пользователя, он мог через какое-то время инициировать повторную аутентификацию этого пользователя на Relying Party с использованием его OpenID. В этом случае в логах Relying Party появилась бы запись, что человек заходил на сайт. В особо бездумных случаях реализации злоумышленник мог даже пройти аутентификацию под именем этого пользователя. Да, против этого есть способы защиты, но они не были заявлены как обязательные в протоколе.

Данную уязвимость устранили в версии OpenID Authentication 2.0, введя изменения в поведение как сервера (OpenID Provider), так и клиента (Relying Party). Читателям, знакомым с протоколом OpenID Authentication, предлагаю задачку на понимание: как реализовать подобную защиту в клиенте OpenID версии 1.1, если сервер модифицировать нет возможности?

Для защиты от такого типа атак существует несколько способов.
  • Cyberplat, например, обязует своих клиентов в каждый запрос вставлять уникальный номер сессии. Такой уникальный номер называют также словом nonce (Number used ONCE). Два запроса с одинаковым номером сессии платёжная система просто откажется обрабатывать. А изменить номер сессии злоумышленник не сможет, так как он не имеет возможности сформировать правильную цифровую подпись для изменённого сообщения.
  • Можно также использовать защиту по времени, вставляя в запрос метку с текущим временем. «Старые» запросы отсекаются.
  • OpenID 2.0 использует оба эти метода для защиты от подобного типа атак: nonce включает текущее время и (необязательно) случайную строку.

6. Для полноты описания (а также поскольку это иногда забывают) стоит упомянуть также банальности. Если система построена на секретности пароля или ключа, то эти данные должны быть надёжно защищены. Выставление UNIX-привилегий 07ХХ на доступ ко всем файлам на Shared-хостинге может закончиться тем, что файл сертификата или пароль к БД, где хранятся «секреты», прочитает «сосед по серверу». Не стоит забывать выставлять пароли, привилегии, разграничивать доступ. Впрочем, не буду долго распространяться, так как все это знают (хотя, не все делают).

7. Ещё один вид уязвимостей — те, что создаются программистами при реализации протокола. Приведу один простой пример (к счастью, не являющийся сколько-то серьёзной уязвимостью): 2 года назад в двух из пяти наиболее популярных реализациях OpenID-сервера разработчики перепутали понятия life_time (время жизни ключа в секундах) и expires_time (время истечения ключа в секундах от 1 января 1970). Особо критичные участки кода желательно подвергать просмотру другими участниками проекта (ОК, это тоже банальность? — тогда перейдём к заключению).

Выводы

Основная мысль, которую я хотел донести в статье — не стоит полагаться на разработчиков того или иного протокола, пусть даже авторами являются компании с громким именем. Думайте сами, решайте сами.

Немножко про практику, а также что вышло за пределы статьи.
  • Инфраструктура открытых ключей (Public Key Infrastructure, PKI) — решение, поражающее своей масштабностью (и, в частности, числом протоколов). Вероятно, это не то, что стоит изучать для написания сервиса автоматического кросспостинга заголовков блога в Твиттер. Также вам, скорее всего, не сюда, если речь идёт про децентрализованные системы. Но даже в этом случае ознакомиться в общих чертах — полезно. Начать можно с Internet X.509 Public Key Infrastructure: Roadmap.
  • Также сегодня разработано большое количество стандартов для обеспечения безопасности веб-сервисов (в первую очередь, построенных на SOAP). Этому посвящена масса статей. (Например, в заметке Securing Web Services собрано некоторое количество ссылок по тематике.) Поэтому перед разработкой своего решения, может быть, стоит познакомиться с уже существующими разработками.
Источник: habr.ru  




Рейтинг @Mail.ru

Rambler's Top100
Rambler's Top100