Информационная безопасность и

web-приложения

У нас опять есть план! 1. Что такое инфобез и с чем его едят• Аутентификация, авторизация и

аккаунтинг• Основные типы атак на web и как с

ними бороться

Информационная безопасность

Цель

Абсолютно защитить информацию от несанкционированного доступа -

сказок не бывает.

Защитить информацию так, чтобы получение доступа к ней стоило на порядки больше той ценности, которую

эта информация имеет.

Парадокс Черной* королевы

* - но мы-то знаем, что королева на самом деле

красная

Если вас еще не взломали - это не ваша заслуга, а чья-то недоработка

Паранойя - не профессиональная болезнь, а естественное состояние организма

Проблема чаще всего расположена между компьютером и стулом

НИКОМУ НЕЛЬЗЯ ВЕРИТЬ!Даже себе. Мне - можно.

Методы работы инфобезовцев

1. создание формального описания системы; 2. построение модели угроз;3. классификация и оценка рисков;4. выбор и установка средств технической защиты;5. разработка регламентов и административных правил по

защите;6. контроль выполнения регламентов, корректировки

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

Защищают не отдельные приложения или аспекты, а информационные системы в целом.

Аутентификация, авторизация и аккаунтинг

AAA

Пароли - плохо, очень плохо

Байка

Данные с потолка

• 95% пользователей имеет два, максимум - три пароля на все;

• генерация паролей на каждый ресурс - удел истинных параноиков;

• пароли чаще всего содержат номера телефонов и даты рождения;

• показатель защищенности пароля - бесполезный и раздражающий элемент;

• хранить пароли в едином хранилище (пусть даже защищенном) - все равно, что класть все ключи от разных мест в одну банку;

• хешированные пароли - иллюзия защищенности.

И если все-таки пароли

• не давайте пользователю вводить пароль, генерируйте его принудительно, максимум - смена;

• сброс пароля - двушаговый (сначала ссылка-подтверждение, затем генерация нового пароля);

• запоминать - ни в коем случае не сам пароль или хэш от него, лучше отдельный токен (и периодически менять) или пароль + "соль";

• учет входов и последующий анализ - если пользователь зашел с иного (необычного для него) сегмента сети или из другой страны (параноики из i2p и tor будут недовольны);

• дополнительные средства защиты offline - например, через мобильный телефон.

Альтернативы

OpenID, OAuth, PKI

OAuth

 

Public Key Infrastructure

Не реклама

Задача на 1М$ Крипторалгоритмы:• RSA - факторизация• DSA - логарифмы на

конечных полях• ECDSA - DSA на группе

точек эллиптической кривой 

Хеши:(однозначное необратимое преобразование)• MD5 (самый популярный из MD*)• SHA-1 и SHA-2• ГОСТ Р 34.11-94

Шифрование

Подпись

Применение

• Аутентификация и авторизацияo HTTPSo SSHo VPN (IPSec)

• Проверка целостности и надежностиo данных (юридически значимых документов)o программного кода (Java Applets, .NET,

мобильные приложения Android и iOS)

Получение сертификата

Как сделать авторизацию по HTTPS через nginx

Создадим пару ключей и сертификат CAopenssl genrsa -des3 -out ca.key 4096openssl req -new -x509 -days 365 -key ca.key -out ca.crt

Далее создадим сертификат сервераopenssl genrsa -out server.key 1024openssl req -new -key server.key -out server.csropenssl x509 -req -days 365 -in server.csr -CA ca.crt \    -CAkey ca.key -set_serial 01 -out server.crt

.. и клиентаopenssl genrsa -out с.key 1024openssl req -new -key с.key -out с.csropenssl x509 -req -days 365 -in с.csr -CA ca.crt \ -CAkey ca.key -set_serial 02 -out с.crtopenssl pkcs12 -export -out с.pfx -inkey с.key \-in с.crt -certfile ca.crt

Сконфигурируем сервер

server { listen 443; ssl on; server_name example.com;

ssl_certificate /etc/nginx/certs/server.crt; ssl_certificate_key /etc/nginx/certs/server.key; ssl_client_certificate /etc/nginx/certs/ca.crt; ssl_verify_client on;}

...и попробуем авторизоваться, предварительно добавив сертификат в браузер

Сертификат можно хранить не только в хранилище браузера (в некоторых системах - централизованно), но и на специальных устройствах:

Применимость различных методов аутентификации

небольшие web-системы, CMS

публичные массовые web-приложения

финансовые системы

системы, содержащие коммерческую или государственную тайну

Пароли

PKI

OAuthOpenID

Основные типы атак на web

Да-да, те самые страшные аббревиатуры

Классификация

По назначению:• получение доступа к

системе;• повышение уровня

привилегий;• приведение в

неработоспособное состояние;

• разрушение системы или отдельных элементов;

• похищение информации и персональных данных;

• использование системы для совершения атак или анонимизации.

По механизму:• переполнение буфера;• подмена указателя;• SQL-инъекции;• инъекции кода;• перехват трафика;• просмотр директорий• крос-сайтовое исполнение

сценариев• инъекции HTTP-заголовков;• заделение HTTP-ответа• организации гонок;• подделка межсайтовых

запросов• подстановка невидимых

элементов других сайтов;• фишинг.

SQL инъекции

Пример

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

куда легко можно подкинуть:

' or '1'='1' or '1'='1' -- '' or '1'='1' ({ '' or '1'='1' /* 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Способы защиты

• экранирование входных данных;• проверка входных данных регулярными

выражениями;• параметризованный запрос:

java.sql.PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ?");stmt.setString(1, username);stmt.setString(2, password);stmt.executeQuery();

• ORM;• использование средств защиты (mod_security); • ограничение прав доступа к БД;• использование NoSQL. :)

Крос-сайтовое исполнение сценариев (XSS)

и немного про C/XSRF

Clickjacking

Cross-site request forgery<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=Fred">

Внедрение JS:• компрометация пользователя

(перехват cookies и сессии);• повышение привилегий с

последующим выполнением неавторизованных действий.

Способы защиты

• экранирование, экранирование и экранирование - желательно перед тем, как положить в базу;

• фильтрация HTML-тегов (если ввод их предполагает);

• токены на CRUD-операции; • понадеяться на средства технической

защиты в браузерах (NoScript, Mozilla's Content Security Policy).

Отказ в обслуживании DoS и DDoS

Методки

• флуд;• генерация большого

числа запросов(например, через ботнет);

• "тяжелые" запросы;• эксплуатация ошибок в

ПО.

Способы защиты

• закрыться от атаки сетью VDS с фильтрами (например, по geoip), особыми настройками TCP/IP  и traffic shaping;

• воспользоваться antiDDoS-сервисом (например, QRator);

• изначально проектировать в расчете на нагрузку, на два порядка превышающую предполагаемую;

• оптимизировать тяжелые запросы;• не впадать в излишества (где достаточно

статического HTML - там должен быть статический HTML);

• использовать ресурсы тех, кто постоянно под DDoS; • кеширование, кеширование, кеширование (и не

забудьте запихнуть в сервера максимум RAM); • позвонить провайдеру. :)

Общие рекомендации по безопасности web систем

1. нельзя никому верить;2. пользователям - в первую очередь;3. разработчикам и тестерам - вообще нельзя;4. администраторам - совсем;5. подписка на списки рассылки по уязвимостям и security

бюллетени для используемой ОС;6. постоянные обновления (используйте LTS);7. использование средств обнаружения и защиты от атак

(IDS); 8. постоянный анализ событий и действий пользователей; 9. периодический аудит инфраструктуры приглашенными

специалистами;10.защиты никогда не бывает мало (если есть

возможность сделать DMZ - не стесняйтесь); 11.если вы что-то не понимаете - это скорее всего

небезопасно и приведет к компрометации систем.

???Это не кодировка побилась, а

предложение задать докладчику вопросы :)