Документ описывает ключевые аспекты информационной безопасности вэб-приложений, включая методы аутентификации, авторизации и типы атак. Он подчеркивает важность защиты информации от несанкционированного доступа, а также предлагает рекомендации по улучшению безопасности, такие как регулярные обновления и использование средств защиты. Также документ обсуждает различные методы защиты от атак, включая SQL-инъекции и кросс-сайтовые сценарии.

1. Информационная
безопасность и
web-приложения

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

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

4. Цель
Абсолютно защитить информацию от несанкционированного
доступа -
сказок не бывает.
Защитить информацию так, чтобы получение доступа к
ней стоило на порядки больше той ценности, которую
эта информация имеет.

5. Парадокс Черной* королевы
* - но мы-то знаем, что королева на самом деле
красная

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

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

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

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

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

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

12. Байка

13. Данные с потолка
• 95% пользователей имеет два, максимум - три пароля
на все;
• генерация паролей на каждый ресурс - удел истинных
параноиков;
• пароли чаще всего содержат номера телефонов и даты
рождения;
• показатель защищенности пароля - бесполезный и
раздражающий элемент;
• хранить пароли в едином хранилище (пусть даже
защищенном) - все равно, что класть все ключи от
разных мест в одну банку;
• хешированные пароли - иллюзия защищенности.

14. И если все-таки пароли
• не давайте пользователю вводить пароль, генерируйте
его принудительно, максимум - смена;
• сброс пароля - двушаговый (сначала ссылка-
подтверждение, затем генерация нового пароля);
• запоминать - ни в коем случае не сам пароль или хэш от
него, лучше отдельный токен (и периодически менять)
или пароль + "соль";
• учет входов и последующий анализ - если пользователь
зашел с иного (необычного для него) сегмента сети или
из другой страны (параноики из i2p и tor будут
недовольны);
• дополнительные средства защиты offline - например,
через мобильный телефон.

15. Альтернативы
OpenID, OAuth, PKI

18. OAuth

21. Public Key Infrastructure

22. Не реклама

23. Задача на 1М$ Крипторалгоритмы:
• RSA - факторизация
• DSA - логарифмы на
конечных полях
• ECDSA - DSA на группе
точек эллиптической
кривой
Хеши:
(однозначное необратимое преобразование)
• MD5 (самый популярный из MD*)
• SHA-1 и SHA-2
• ГОСТ Р 34.11-94

24. Шифрование

25. Подпись

26. Применение
• Аутентификация и авторизация
o HTTPS
o SSH
o VPN (IPSec)
• Проверка целостности и надежности
o данных (юридически значимых документов)
o программного кода (Java Applets, .NET,
мобильные приложения Android и iOS)

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

28. Как сделать авторизацию по HTTPS
через nginx
Создадим пару ключей и сертификат CA
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Далее создадим сертификат сервера
openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -CA ca.crt
-CAkey ca.key -set_serial 01 -out server.crt

29. .. и клиента
openssl genrsa -out с.key 1024
openssl req -new -key с.key -out с.csr
openssl x509 -req -days 365 -in с.csr -CA ca.crt
-CAkey ca.key -set_serial 02 -out с.crt
openssl 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;
}

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

31. Применимость различных методов
аутентификации
небольшие web-системы,
CMS
Пароли
публичные массовые web- OAuth
приложения OpenID
финансовые системы
системы, содержащие PKI
коммерческую или
государственную тайну

32. Основные типы атак на web
Да-да, те самые страшные
аббревиатуры

33. Классификация
По назначению: По механизму:
• переполнение буфера;
• получение доступа к
• подмена указателя;
системе; • SQL-инъекции;
• повышение уровня • инъекции кода;
привилегий; • перехват трафика;
• приведение в • просмотр директорий
неработоспособное • крос-сайтовое исполнение
состояние; сценариев
• инъекции HTTP-заголовков;
• разрушение системы или
• заделение HTTP-ответа
отдельных элементов; • организации гонок;
• похищение информации и • подделка межсайтовых
персональных данных; запросов
• использование системы • подстановка невидимых
для совершения атак или элементов других сайтов;
анонимизации. • фишинг.

34. SQL инъекции

35. Пример
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

36. Способы защиты
• экранирование входных данных;
• проверка входных данных регулярными
выражениями;
• параметризованный запрос:
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. :)

37. Крос-сайтовое исполнение
сценариев (XSS)
и немного про C/XSRF

38. Внедрение JS: Cross-site request forgery
• компрометация пользователя <img
(перехват cookies и сессии); src="http://bank.example.com
• повышение привилегий с /withdraw?
последующим выполнением account=bob&amount=1000000&f
неавторизованных действий. or=Fred">
Clickjacking

39. Способы защиты
• экранирование, экранирование и
экранирование - желательно перед тем,
как положить в базу;
• фильтрация HTML-тегов (если ввод их
предполагает);
• токены на CRUD-операции;
• понадеяться на средства технической
защиты в браузерах (NoScript, Mozilla's
Content Security Policy).

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

41. Методки
• флуд;
• генерация большого
числа запросов
(например, через
ботнет);
• "тяжелые" запросы;
• эксплуатация ошибок в
ПО.

42. Способы защиты
• закрыться от атаки сетью VDS с фильтрами
(например, по geoip), особыми настройками TCP/IP
и traffic shaping;
• воспользоваться antiDDoS-сервисом (например,
QRator);
• изначально проектировать в расчете на нагрузку, на
два порядка превышающую предполагаемую;
• оптимизировать тяжелые запросы;
• не впадать в излишества (где достаточно
статического HTML - там должен быть статический
HTML);
• использовать ресурсы тех, кто постоянно под DDoS;
• кеширование, кеширование, кеширование (и не
забудьте запихнуть в сервера максимум RAM);
• позвонить провайдеру. :)

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

44. – нельзя никому верить;
2. пользователям - в первую очередь;
3. разработчикам и тестерам - вообще нельзя;
4. администраторам - совсем;
5. подписка на списки рассылки по уязвимостям и security
бюллетени для используемой ОС;
6. постоянные обновления (используйте LTS);
7. использование средств обнаружения и защиты от атак
(IDS);
8. постоянный анализ событий и действий пользователей;
9. периодический аудит инфраструктуры приглашенными
специалистами;
10.защиты никогда не бывает мало (если есть
возможность сделать DMZ - не стесняйтесь);
11.если вы что-то не понимаете - это скорее всего
небезопасно и приведет к компрометации систем.

45. ???
Это не кодировка побилась, а
предложение задать докладчику
вопросы :)