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

2. Представляюсь на всякий случай
• Странствующий рыцарь
• root@.....com, root@......ru, root@......kz, …
.
• Когда-то давно занимался битхаком
• Когда-то давно работал экспертом по
инфобезопасности
• Меня можно нанять для добрых дел

3. Аудитория доклада
• IT-бизнесмены
• Архитекторы приложений
• Инженеры-разработчики
• Инженеры-эксплуатационщики
• Системные администраторы
• Просто хорошие люди

4. Disclaimer
• Все, о чем я расскажу, может оказаться
ложью
• Ни один из приведенных примеров не
имел места в действительности
• Если после моего доклада от вас ушла
девушка, я не при чем
• Цель этой презентации не состоит в
возбуждении ненависти или вражды к
социальной группе «идиоты» либо иным

5. Предметная область
• Защита информации
• (Кстати, это очень скучно, кто не будет спать к
концу доклада – тот security expert)
• Какой еще информации?
• В веб мы обрабатываем
пользовательскую информацию, ее и
будем защищать
• Чтобы защищать инфраструктуру, нужно
ее сначала нарисовать

6. Театр начинается с вешалки,
• А защита информации – с построения модели
угроз (threat modeling)
• Кто-то сказал «Microsoft»?
• Нет, Microsoft это не угроза, а создатель
модели классификации угроз STRIDE
• И надстройки над Visio, которая позволяет не
только считать ее падения, но и нарисовать
модель угроз

7. STRIDE
• Spoofing – маскировка под другого субъекта
• Tampering – порча (подделка) данных
• Repudiation – отказ от авторства
• Information disclosure – раскрытие
(сенситивной) информации
• Denial of service – отказ в обслуживании
• Elevation of privilege – повышение уровня
привилегий

8. Информационная система (сайт)
• LAMP
• Хранилище пользовательских данных (M)
• Сервисы обработки и представления данных
(A,P)
• Системные и инфраструктурные сервисы,
платформа (L)
• С точки зрения информационной
безопасности можно выделить субъекты и
объекты безопасности
• Субъекты доступаются к объектам

9. Модели разграничения доступа
• DAC – discretionary access
control, классическая модель Unix r/w/x bits
• MAC – mandatory access control, что-то
военное
• RBAC – role-based access control, кто-то опять
сказал «Microsoft»?
• Да, реализацию RBAC можно наблюдать в
линейке MS Win NT (а старички скажут
«Netware»)
• RBAC – очень популярная модель

10. Люди любят котиков
• Хватит теории, жги давай!

11. Еще немного теории
• Люди любят сокращения, вот еще одно
• POLP – principle of least privilege
• Каждый субъект безопасности должен иметь
доступ только к тем объектам безопасности,
которые необходимы ему для легитимного
исполнения своих обязанностей

12. Хранилище данных (M) – S
• Spoofing?
• Внешние пользователи вообще не должны
иметь доступа к хранилищу данных
• Если кто-то проник в сеть, то ему придется
подделывать TCP-сессию, так как обмен
информацией с базой данных обычно
происходит неразрывно
• Можем считать, что это не проблема

13. Хранилище данных (M) – T,R
• Little Bobby Tables (http://xkcd.com/327)
• We will learn how to sanitize to sanitize our
database inputs a bit l8r 
• Но это все еще не проблема хранилища
данных
• С точки зрения хранилища данных все
изменения «подписаны»
пользователем, который их произвел
• Но это системный пользователь
• Да, это компромисс

14. Хранилище данных (M) – I
• Информацию можно разделить на
сенситивную и не очень
• Зачем разделять, давайте зашифруем всё?
• …WHERE name LIKE ‘%ash%’…
• Зашифруем раздел на диске (минус – теперь
для старта системы нужен человек)
• Зашифруем в базе то, что действительно
сенситивно:
• Пароли
• Номера кредитных карт?
• Вы храните в базе номера кредитных карт???

15. Шифруем пароли
• Где-то нужно держать ключ?
• Сделаем лучше необратимое хэширование
• md5($password)
• vasya: 698d51a19d8a121ce581499d7b701668
petya: 698d51a19d8a121ce581499d7b701668
• Чему равно md5(‘111’)?
• Rainbow tables
• md5($salt . $password)
• $salt – случайное число, сопоставляется
пользователю и хранится где-то (в той же
базе?)

16. Хэшируем пароли
• “MD5 GPU brute force speed exceed 200
millions MD5 hash/second (default charset [a-
z,0-9])”
• “As of 2011, commercial products are available
that claim the ability to test up to 2,800,000,000
passwords per second on a standard desktop
computer using a high-end graphics processor”
(NTLM hash)
• Используйте МЕДЛЕННЫЙ алгоритм (в
настоящее время – SHA-512, Whirlpool)
• Key stretching, PBKDF2

17. Хранилище данных (M) – D
• Наблюдается в веб сплошь и рядом
• Практически всегда, первое, что отказывает
при увеличении нагрузки на сайт – это
хранилище
• Занимайтесь оптимизацией
производительности
• Кэшируйте
• Кстати, про все это я читаю доклады

18. Хранилище данных (M) – E
• Если вы администрируете базу данных при
помощи PHPMyAdmin – убейте себя
• Если вы администрируете базу данных по
незащищенному удаленному соединению –
убейте себя (или сделайте VPN)
• Если вы не умеете работать в локальной
консоли сервера – убейте себя
• Не забывайте про POLP – системный
пользователь приложения должен иметь
доступ только к базе приложения

19. Хранилище данных (M) – E
• Создатели протокола MySQL уже немного
позаботились о вас – пароль невозможно
узнать, имея дапм протокола
• Пароль можно подсмотреть в
конфигурационном файле вашего
приложения
• Но это не проблема хранилища данных

20. Сервер приложений (A,P) – S
• Плохой пользователь может украсть cookie у
хорошего и подделать его сессию
• Используйте SSL для шифрования канала,
тогда плохой пользователь не сможет украсть
cookie путем прослушивания канала
• Все еще можно украсть cookie из браузера
• Трекайте пользовательскую активность,
чтобы по поведенческим шаблонам отличать
плохого пользователя от хорошего
(«обычные» и «необычные» IP-адреса)

21. Сервер приложений (A,P) – T
• Сервер приложений хранит пользовательские
данные – файлы, сессии, и ничего с этим мы
поделать не можем
• Сервер приложений использует один
системный аккаунт на все приложение
• Если приложений несколько – дайте им
разные системные аккаунты!
• А лучше – разные виртуальные окружения!
• Не забывайте про POLP
• Вы уже делаете бэкапы?
• А контрольные суммы важных файлов вы
считаете?

22. Сервер приложений (A,P) – R
• Сервер приложений – та часть
системы, которая непосредственно
взаимодействует с пользователем
• Перед тем, как изменить сенситивные
данные по запросу пользователя, еще раз
убедитесь, что он – это он (спросите пароль?)
• Хороший способ убедиться, что автор
изменений это действительно автор
изменений – выдать пользователю
сертификат
• Всегда ведите логи важных изменений

23. Сервер приложений (A,P) – I
• Отключите вывод отладочной информации
на продакшн системе (!!!)
• Хотите скрыть число реальных пользователей
на проекте и все еще подставляете
суррогатный ID пользователя в URL?
• Убрать версию софта из HTTP headers может
быть не такой плохой идеей
• Обязательно защищайтесь от SQL
injection, пока у вас не украли базу прямо
через ваше приложение

24. SQL injection
• Little Bobby Tables is back again!
• Как защититься?
• В PHP есть миллион функций, которые, вроде
бы, делают string escaping
• У OWASP есть библиотека, в которой есть
функция...
• Используйте prepared statements и вообще
забудьте про injection!
• Но не будьте наивны и не делайте prepared
statement из строки, которая уже содержит
переданные пользователем значения!
• Такая магия не работает!

25. Сервер приложений (A,P) – D
• На одном слайде рассказать обо всем
невозможно
• Учитесь отличать мусорные запросы от
настоящих
• Заведите систему автоматической
классификации трафика («нарисуйте сову»)
• Кстати, такая система есть у московской
компании Highload Lab
• Не используйте для блокирования мусорных
запросов стоковый iptables
• Используйте ipset или аналоги

26. Сервер приложений (A,P) – E
• Никогда не запускайте сервер приложений с
правами пользователя root
• Если в приложении существуют различные
уровни доступа, потратьте время на создание
внутреннего security framework и обязательно
покройте его unit тестами
• Интегрируйте в систему этот security
framework таким образом, чтобы его было
трудно обойти
• Перед выполнением какой-то операции
проверяйте роли и права пользователя

27. Сервер приложений (A,P) – E
• Защищайтесь от подбора пароля – CAPTCHA,
блокирование IP после нескольких неудачных
попыток
• Требуйте от пользователя соответствия
password policy
• Умейте выделять неожиданное поведение
пользователя – для этого трекайте его
ожидаемое поведение (IP адреса, UA)
• Введите двухфакторную аутентификацию
(например, через SMS)
• Но сделайте ее удобной

28. Платформа (L) – S
• Всю служебную коммуникацию с системой
(деплоймент, обслуживание) проводите по
шифрованным каналам
• Для установления шифрованного соединения
применяйте двухфакторную аутентификацию
(IP-адрес + ключ, IP-адрес + пароль)

29. Платформа (L) – T
• Используйте AIDE, Tripwire или аналоги для
отслеживания целостности компонентов
платформы (конфигурационных файлов, etc)
• Вы уже делаете бэкапы?
• Создайте централизованный лог-сервер и
ведите логи на него (syslog это позволяет)
• Lennart Poettering знает, как правильно вести
логи и скоро научит нас всех (лог-файлы будут
криптографически подписаны)

30. Платформа (L) – R
• Про логи на отдельный сервер я уже говорил?
• Раздайте пользователям ssh ключи с
паролями и пусть ходят по ключам – ключ
невозможно подобрать подбором
• Не давайте никому заходить удаленно под
пользователем root, пусть ходят под
именными логинами и делают su или sudo
• Регулярно проверяйте, что эти правила
выполняются

31. Платформа (L) – I
• Установите и настройте
Grsecurity, SELinux, RSBAC, AppArmor или
Tomoyo – будет не очень легко, но вы
справитесь, если захотите
• Используя POLP и permissive mode указанных
выше систем, раздайте системным
пользователям нужное количество прав
• Включите enforcing mode
• Можно использовать POSIX ACLs для более
точной раздачи прав

32. Платформа (L) – D
• Используйте систему сбора статистики и
оповещения (NAGIOS, Icinga, Zabbix, etc)
• Используйте возможности системы по
ограничению количества потребляемых
сервисами/системными пользователями
ресурсов
• Используйте виртуализацию и ограничивайте
виртуальные машины в ресурсах
• Не держите важные и второстепенные
сервисы на одном физическом хосте

33. Платформа (L) – E
• Защищайтесь от подбора пароля
(используйте демоны DenyHosts, fail2ban или
аналоги)
• Перенести сервисы на другие порты?
• Думаете, атакующий их не узнает? 
• Port knocking
• Организация VPN для доступа к внутренним
инфраструктурным сервисам
• Обязательно применение security updates для
используемых сервисов – регулярно
находятся и устраняются remote vulnerabilities

34. Все?
• Сервер мы защитили
• Но остался еще пользователь
• А у пользователя есть браузер
• Который тоже представляет из себя
информационную систему

35. Браузер – S
• Сплошь и рядом – браузер не может отличить
JavaScript-приложение, попавшее в него в
результате срабатывания XSS-уязвимости на
сайте от легальных действий пользователя
• А ведь есть еще и CSRF-атаки

36. XSS
• <script>alert(“Hello, I’m a hacker!”)</script>
• А разгадка одна – слишком высокий уровень
доверия к введенным пользователем данным
• Безжалостно режьте или экранируйте все, что
браузер мог бы интерпретировать как JS
• В библиотеке OWASP есть одна функция...
• А в PHP их миллион
• Общий принцип: доверие к
пользовательским данным должно быть
минимальным

37. CSRF
• Cross Site Request Forgery
• Хороший пользователь залогинен на сайте
a.com
• Сайт a.com позволяет менять состояние через
GET-запрос
• Пользователь идет на сайт
злоумышленника, где ему формируют GET-
запрос, меняющий состояние на сайте a.com
• Защититься легко – различайте GET и POST и
ставьте one-time challenges в формы

38. Браузер – T,R,D
• Раньше браузер не хранил ничего, кроме
cookies, теперь есть еще local file storage
• Наверняка появится много новых интересных
проблем, связанных с его безопасностью
• Ваш браузер – это вы, на серверной стороне
небезосновательно считают, что с той
стороны вашего браузера вы, и никто другой
• Особенно, если вы прошли аутентификацию
• И сложно будет доказать обратное
• DoS браузера? Нет, не слышал

39. Браузер – I,E
• Раскрытие информации происходит сплошь и
рядом благодаря XSS уязвимостям
• Как ни странно, в браузере возможно и
повышение привилегий:
http://habrahabr.ru/company/dsec/blog/14168
4/
• Подобные уязвимости находят и исправляют
постоянно, всегда следите за апдейтами
ваших браузеров

40. Литература
• Rainbow series (good luck!)
• OWASP Guide
• Security mailing lists используемых вами
дистрибутива, сервера приложений, etc
• http://security.stackexchange.com
• Журнал «Хакер»

41. Вопросы?
•
•
•
•
•
•

42. Контакты
• alexclear@gmail.com
• http://alexclear.livejournal.com
• http://github.com/alexclear
• skype://demeliorator