The Web-site of design Company Chelyabenergoproekt in English   English
Проектные работы в проектной организации Челябэнергопроект Заказать проектные работы в письме к проектной организации Челябэнергопроект Карта сайта
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch




Création de site web société française Chelyabenergoproekt   Française

   Облако тегов на сайте проектной организации Челябэнергопроект
Проекты интеллектуального мастерства!
новости компании
30.12.2015 С Новым годом!
Администрация ...
21.12.2015 С Днём Энергетика!
Уважаемые друзья и коллеги! Поздравляю вас с нашим большим праздником – Днем Энергетика! ...



новости отрасли
объекты Ростехнадзора
  Облако тегов
проектирование монтаж ключ котел кран сертификат ГОСТ ремонт заказЧелябинск

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

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

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

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

Рассмотрим понятие безопасного взаимодействия.

Итак, давайте определимся, что мы подразумеваем под словами «безопасное взаимодействие»:
1. Аутентификация. Пусть сервер А хочет передать сообщение серверу Б. Б должен иметь возможность проверить, что сообщение отправлено именно от А. Данная проверка называется аутентификацией сервера А на сервере Б.
2. Целостность данных. Мы хотим быть уверены, что сообщение при передаче не было изменено (например, было оплачено 50$, а подтверждение получено на 500$).
3. Конфиденциальность взаимодействия. Данный пункт подразумевает, что сообщение получают только те стороны, которые имеют на это право. Как правило, данный пункт подразумевает шифрование информации при передаче. В некоторых случаях можно рассматривать ещё два пункта: проверку прав доступа и невозможность отказа от авторства (non-repudiation), но сейчас мы оставим это в стороне.

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

Рассмотрим недостатки SSL/TLS и HTTPS.

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

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

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

Рассмотрим типы защищаемых приложений.

Перед тем как, наконец, перейти к атакам на протоколы, необходимо сказать об ограничениях, в которых работает проектируемая система. Необходимо упомянуть три основных типа приложений, для которых можно рассматривать вопросы безопасного взаимодействия:
1. Две взаимодействующих стороны имеют возможность заранее обменяться по гарантированно защищённому каналу необходимой информацией: общим ключом, сертификатами, паролями и проч. Таким каналом может быть очная передача необходимой информации между людьми (лучше всего), альтернативный канал связи (сотовая связь, телефон) или даже интернет – если обе стороны уверены в отсутствии «Человека посередине» или другого способа перехвата или модификации сообщения.
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-соединения. 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). Особо критичные участки кода желательно подвергать просмотру другими участниками проекта (ОК, это тоже банальность? – тогда перейдём к заключению).

Рассмотрим десять самых распространенных ошибок в сфере компьютерной безопасности, которые ни в коем случае нельзя совершать:
1. Отправка конфиденциальных данных в незашифрованных электронных письмах. Не допускается слать пароли, личные идентификационные номера и данные учетных записей в незашифрованных электронных письмах.
2. Использование «контрольных» вопросов, ответ на которые легко угадать. Номер страховки, девичья фамилия матери, имя домашнего питомца, дата рождения – все это не является надежным средством идентификации личности. Использование таких «контрольных» вопросов для восстановления пароля конечного пользователя делает сам пароль практически бесполезным, потому что любой, у кого есть время и желание, может в таком случае с легкостью подобрать ключик к чужой учетной записи.
3. Использование чересчур строгих ограничений на выбор пароля. Нам приходится часто сталкиваться с системами управления финансами онлайн (типа интернет-банкинга), которые устанавливают такие строгие ограничения на выбор пароля, что защищенность интерфейса от этого только снижается. Пароли из шести цифр пользуются популярностью.
4. Слепое доверие в вопросах безопасности производителям программного обеспечения. Поставщиков ПО, которым можно безоговорочно доверять, просто не существует. В конечном счете, единственное, что интересует производителей – это их собственная прибыль и доля на рынке. Иногда это действительно побуждает их укреплять безопасность своих программных продуктов и услуг, но порой – совсем наоборот. Поэтому определение «надежной безопасности» от поставщика ПО всегда следует ставить под сомнение. Не разрешайте производителям решать за вас, что для вас важнее.
5. Непонимание того, насколько важен профессиональный опыт в сфере безопасности. Руководители корпораций (и технически подкованные ИТ-специалисты в том числе) часто не уделяют должного внимания проблеме профессионализма в области безопасности. Доходит до того, что в исследовательские группы по разработке стандартов безопасности входит немало талантливых программистов и ни одного специалиста по криптографии (как это было в случае с WEP) – притом что они пытаются создавать стандарты, опирающиеся непосредственно на шифровальные алгоритмы.
6. Непонимание того, насколько важна независимая проверка. Даже работу экспертов по специфическим видам безопасности должны проверять такие же опытные специалисты. В сфере безопасности взаимные проверки – нечто вроде священного Грааля абсолютной защиты, и никакая система не может считаться безопасной до тех пор, пока не будет тщательно и глубоко испытана специалистами, не причастными к ее разработке.
7. Излишняя забота о секретности. Многие разработчики программного обеспечения в сфере безопасности не только недооценивают важность независимой проверки, но и переоценивают значимость секретности. Они обосновывают свой отказ отправить работу на проверку независимым специалистам тем, что самое главное – это держать политику безопасности в секрете. Между тем, как гласит принцип Керкгоффса (одна из фундаментальных аксиом науки безопасности), если безопасность системы зависит исключительно от сохранения ее архитектуры в секрете, такая система не может считаться надежно защищенной.
8. Использование средств идентификации личности, которые легко подделать. Любые системы, предусматривающие пересылку по факсу подписей, фотокопий или сканов удостоверений/паспортов в качестве средства идентификации личности, являются, по сути, декоративными – ворох мишуры и отсутствие реального результата (то есть, в данном случае, безопасности). Подделать такие некачественные копии, сделанные с помощью технических средств прошлого (или даже позапрошлого) поколения, – легче легкого. На самом деле, копии подписей и паспортов могут служить надежным средством идентификации личности только тогда, когда на копии совсем не похожи. Другими словами, только качественная преднамеренная подделка оригинала может считаться хорошей копией, усложняющей злонамеренную подделку.
9. Бессмысленное изобретение велосипеда. Очень часто разработчики нового ПО в сфере безопасности пытаются заново создать то, что уже было создано до них, не имея на то веских оснований. Многие производители программного обеспечения страдают «синдромом оригинальности» и в итоге создают программы, не имеющие новых полезных функций. Само по себе это еще не страшно, но ведь новое программное обеспечение зачастую не проходит независимой проверки, изобилует ошибками, уже устраненными в других воплощениях подобных программ, и в общем, ужасно все портит. Прежде чем приступать к разработке нового ПО, подумайте, нет ли уже готовых качественных приложений такого рода, и если ваша будущая программа обладает действительно новыми и полезными функциями, не лучше ли добавить эти функции к чему-то уже существующему вместо того, чтобы создавать себе и людям кучу проблем, пытаясь это существующее заменить.
10. Подмена реальной безопасности ложным чувством защищенности. Ошибка настолько абсурдная, что даже трудно сформулировать ее суть. Тем не менее, она так распространена, что не включить ее в этот список просто нельзя. Люди вручают ключи от своей системы безопасности любому, кто представится экспертом, причем делают это охотно, с энтузиазмом и порой даже ни капли не задумываясь. «Центры сертификации» говорят, кому доверять, лишая пользователей возможности самостоятельно принимать решения о доверии; провайдеры услуг электронной почты предлагают серверное шифрование и дешифрование данных, лишая людей возможности самостоятельно шифровать письма и управлять собственными шифровальными ключами; операционные системы самовольно запускают службы и приложения, лишая пользователей возможности защититься от мобильного вредоносного ПО. Не доверяйте управление безопасности третьим лицам! Конечно, не все могут разработать надежную программу или политику в области безопасности исключительно самостоятельно, но это еще не значит, что такая программа или политика должна лишать вас возможности управлять ею самолично.

Таким образом, не стоит полагаться на разработчиков того или иного протокола, пусть даже авторами являются компании с громким именем.


Источники:
1. Копытин, Д. Безопасность при межпроектном взаимодействии [http://www.infosecurity.ru/cgi-bin/mart/arts.pl?a=091215]
2. Perrin Ch. Десять самых распространенных ошибок в сфере компьютерной безопасности, которые ни в коем случае нельзя совершать [http://www.winblog.ru/security/1147765822-15090802.html]

Автор: Челябэнергопроект
Дата: 23.03.2010

Комментарии специалистов Челябэнергопроект:
Нет
Статьи

смета проектных работ
©Челябэнергопроект – проектные работыinfo@chepr.ru, 2007-2013
DRA.RU - проектирование сайта под ключ; системный администратор ООО «Челябэнергопроект»
Главная|О компании|Стратегия|
Компетенция / услуги|Контакты
Сертификат качества