SlideShare a Scribd company logo

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

•Download as PPT, PDF•
•
Maxim Krentovskiy
Maxim Krentovskiy

Встреча группы GetDev.net от 17 марта 2012 года.

Related slideshows

Безопасность сессий в веб-приложениях: практическое применение
Безопасность сессий в веб-приложениях: практическое применениеБезопасность сессий в веб-приложениях: практическое применение
Безопасность сессий в веб-приложениях: практическое применение
 
Check Point. Сергей Чекрыгин. "На один шаг впереди"
Check Point. Сергей Чекрыгин. "На один шаг впереди"Check Point. Сергей Чекрыгин. "На один шаг впереди"
Check Point. Сергей Чекрыгин. "На один шаг впереди"
 
Waf.js: как защищать веб-приложения с использованием JavaScript
Waf.js: как защищать веб-приложения с использованием JavaScriptWaf.js: как защищать веб-приложения с использованием JavaScript
Waf.js: как защищать веб-приложения с использованием JavaScript
 
1 of 45
Информационная безопасность и web-приложения
У нас опять есть план! 1. Что такое инфобез и с чем его едят • Аутентификация, авторизация и аккаунтинг • Основные типы атак на web и как с ними бороться
Информационная безопасность
Цель Абсолютно защитить информацию от несанкционированного доступа - сказок не бывает. Защитить информацию так, чтобы получение доступа к ней стоило на порядки больше той ценности, которую эта информация имеет.
Парадокс Черной* королевы * - но мы-то знаем, что королева на самом деле красная
Если вас еще не взломали - это не ваша заслуга, а чья-то недоработка Паранойя - не профессиональная болезнь, а естественное состояние организма
Проблема чаще всего расположена между компьютером и стулом
НИКОМУ НЕЛЬЗЯ ВЕРИТЬ! Даже себе. Мне - можно.
Методы работы инфобезовцев 1. создание формального описания системы; 2. построение модели угроз; 3. классификация и оценка рисков; 4. выбор и установка средств технической защиты; 5. разработка регламентов и административных правил по защите; – контроль выполнения регламентов, корректировки согласно новым требованиями и изменениям в законодательстве, аудит безопасност��. Защищают не отдельные приложения или аспекты, а информационные системы в целом.
Аутентификация, авторизация и аккаунтинг AAA
Пароли - плохо, очень плохо
Байка
Данные с потолка • 95% пользователей имеет два, максимум - три пароля на все; • генерация паролей на каждый ресурс - удел истинных параноиков; • пароли чаще всего содержат номера телефонов и даты рождения; • показатель защищенности пароля - бесполезный и раздражающий элемент; • хранить пароли в едином хранилище (пусть даже защищенном) - все равно, что класть все ключи от разных мест в одну банку; • хешированные пароли - иллюзия защищенности.
И если все-таки пароли • не давайте пользователю вводить пароль, генерируйте его принудительно, максимум - смена; • сброс пароля - двушаговый (сначала ссылка- подтверждение, затем генерация нового пароля); • запоминать - ни в коем случае не сам пароль или хэш от него, лучше отдельный токен (и периодически менять) или пароль + "соль"; • учет входов и последующий анализ - если пользователь зашел с иного (необычного для него) сегмента сети или из другой страны (параноики из i2p и tor будут недовольны); • дополнительные средства защиты offline - например, через мобильный телефон.
Альтернативы OpenID, OAuth, PKI
Информационная безопасность и web-приложения
Информационная безопасность и web-приложения
OAuth
Информационная безопасность и web-приложения
Информационная безопасность и web-приложения
Public Key Infrastructure
Не реклама
Задача на 1М$ Крипторалгоритмы: • RSA - факторизация • DSA - логарифмы на конечных полях • ECDSA - DSA на группе точек эллиптической кривой Хеши: (однозначное необратимое преобразование) • MD5 (самый популярный из MD*) • SHA-1 и SHA-2 • ГОСТ Р 34.11-94
Шифрование
Подпись
Применение • Аутентификация и авторизация o HTTPS o SSH o VPN (IPSec) • Проверка целостности и надежности o данных (юридически значимых документов) o программного кода (Java Applets, .NET, мобильные приложения Android и iOS)
Получение сертификата
Как сделать авторизацию по 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
.. и клиента 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; }
...и попробуем авторизоваться, предварительно добавив сертификат в браузер Сертификат можно хранить не только в хранилище браузера (в некоторых системах - централизованно), но и на специальных устройствах:
Применимость различных методов аутентификации небольшие web-системы, CMS Пароли публичные массовые web- OAuth приложения OpenID финансовые системы системы, содержащие PKI коммерческую или государственную тайну
Основные типы атак на 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
Внедрение JS: Cross-site request forgery • компрометация пользователя <img (перехват cookies и сессии); src="http://bank.example.com • повышение привилегий с /withdraw? последующим выполнением account=bob&amount=1000000&f неавторизованных действий. or=Fred"> Clickjacking
Способы защиты • экранирование, экранирование и экранирование - желательно перед тем, как положить в базу; • фильтрация HTML-тегов (если ввод их предполагает); • токены на CRUD-операции; • понадеяться на средства технической защиты в браузерах (NoScript, Mozilla's Content Security Policy).
Отказ в обслуживании DoS и DDoS
Методки • флуд; • генерация большого числа запросов (например, через ботнет); • "тяжелые" запросы; • эксплуатация ошибок в ПО.
Способы защиты • закрыться от атаки сетью VDS с фильтрами (например, по geoip), особыми настройками TCP/IP и traffic shaping; • воспользоваться antiDDoS-сервисом (например, QRator); • изначально проектировать в расчете на нагрузку, на два порядка превышающую предполагаемую; • оптимизировать тяжелые запросы; • не впадать в излишества (где достаточно статического HTML - там должен быть статический HTML); • использовать ресурсы тех, кто постоянно под DDoS; • кеширование, кеширование, кеширование (и не забудьте запихнуть в сервера максимум RAM); • позвонить провайдеру. :)
Общие рекомендации по безопасности web систем
– нельзя никому верить; 2. пользователям - в первую очередь; 3. разработчикам и тестерам - вообще нельзя; 4. администраторам - совсем; 5. подписка на списки рассылки по уязвимостям и security бюллетени для используемой ОС; 6. постоянные обновления (используйте LTS); 7. использование средств обнаружения и защиты от атак (IDS); 8. постоянный анализ событий и действий пользователей; 9. периодический аудит инфраструктуры приглашенными специалистами; 10.защиты никогда не бывает мало (если есть возможность сделать DMZ - не стесняйтесь); 11.если вы что-то не понимаете - это скорее всего небезопасно и приведет к компрометации систем.
??? Это не кодировка побилась, а предложение задать докладчику вопросы :)

More Related Content

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

  • 2. У нас опять есть план! 1. Что такое инфобез и с чем его едят • Аутентификация, авторизация и аккаунтинг • Основные типы атак на web и как с ними бороться
  • 4. Цель Абсолютно защитить информацию от несанкционированного доступа - сказок не бывает. Защитить информацию так, чтобы получение доступа к ней стоило на порядки больше той ценности, которую эта информация имеет.
  • 5. Парадокс Черной* королевы * - но мы-то знаем, что королева на самом деле красная
  • 6. Если вас еще не взломали - это не ваша заслуга, а чья-то недоработка Паранойя - не профессиональная болезнь, а естественное состояние организма
  • 7. Проблема чаще всего расположена между компьютером и стулом
  • 8. НИКОМУ НЕЛЬЗЯ ВЕРИТЬ! Даже себе. Мне - можно.
  • 9. Методы работы инфобезовцев 1. создание формального описания системы; 2. построение модели угроз; 3. классификация и оценка рисков; 4. выбор и установка средств технической защиты; 5. разработка регламентов и административных правил по защите; – контроль выполнения регламентов, корректировки согласно новым требованиями и изменениям в законодательстве, аудит безопасности. Защищают не отдельные приложения или аспекты, а информационные системы в целом.
  • 11. Пароли - плохо, очень плохо
  • 13. Данные с потолка • 95% пользователей имеет два, максимум - три пароля на все; • генерация паролей на каждый ресурс - удел истинных параноиков; • пароли чаще всего содержат номера телефонов и даты рождения; • показатель защищенности пароля - бесполезный и раздражающий элемент; • хранить пароли в едином хранилище (пусть даже защищенном) - все равно, что класть все ключи от разных мест в одну банку; • хешированные пароли - иллюзия защищенности.
  • 14. И если все-таки пароли • не давайте пользователю вводить пароль, генерируйте его принудительно, максимум - смена; • сброс пароля - двушаговый (сначала ссылка- подтверждение, затем генерация нового пароля); • запоминать - ни в коем случае не сам пароль или хэш от него, лучше отдельный токен (и периодически менять) или пароль + "соль"; • учет входов и последующий анализ - если пользователь зашел с иного (необычного для него) сегмента сети или из другой страны (параноики из i2p и tor будут недовольны); • дополнительные средства защиты offline - например, через мобильный телефон.
  • 18. OAuth
  • 23. Задача на 1М$ Крипторалгоритмы: • RSA - факторизация • DSA - логарифмы на конечных полях • ECDSA - DSA на группе точек эллиптической кривой Хеши: (однозначное необратимое преобразование) • MD5 (самый популярный из MD*) • SHA-1 и SHA-2 • ГОСТ Р 34.11-94
  • 26. Применение • Аутентификация и авторизация o HTTPS o SSH o VPN (IPSec) • Проверка целостности и надежности o данных (юридически значимых документов) o программного кода (Java Applets, .NET, мобильные приложения Android и iOS)
  • 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-ответа отдельных элементов; • организации гонок; • похищение информации и • подделка межсайтовых персональных данных; запросов • использование системы • подстановка невидимых для совершения атак или элементов других сайтов; анонимизации. • фишинг.
  • 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).
  • 41. Методки • флуд; • генерация большого числа запросов (например, через ботнет); • "тяжелые" запросы; • эксплуатация ошибок в ПО.
  • 42. Способы защиты • закрыться от атаки сетью VDS с фильтрами (например, по geoip), особыми настройками TCP/IP и traffic shaping; • воспользоваться antiDDoS-сервисом (например, QRator); • изначально проектировать в расчете на нагрузку, на два порядка превышающую предполагаемую; • оптимизировать тяжелые запросы; • не впадать в излишества (где достаточно статического HTML - там должен быть статический HTML); • использовать ресурсы тех, кто постоянно под DDoS; • кеширование, кеширование, кеширование (и не забудьте запихнуть в сервера максимум RAM); • позвонить провайдеру. :)
  • 44. – нельзя никому верить; 2. пользователям - в первую очередь; 3. разработчикам и тестерам - вообще нельзя; 4. администраторам - совсем; 5. подписка на списки рассылки по уязвимостям и security бюллетени для используемой ОС; 6. постоянные обновления (используйте LTS); 7. использование средств обнаружения и защиты от атак (IDS); 8. постоянный анализ событий и действий пользователей; 9. периодический аудит инфраструктуры приглашенными специалистами; 10.защиты никогда не бывает мало (если есть возможность сделать DMZ - не стесняйтесь); 11.если вы что-то не понимаете - это скорее всего небезопасно и приведет к компрометации систем.
  • 45. ??? Это не кодировка побилась, а предложение задать докладчику вопросы :)

Editor's Notes

  1. Межконтинентальная баллистическая ракета LGM-30 Minuteman - единственная американская МБР наземного (шахтного) базирования. Все пуски ракет, которые вы видите в фильмах в фильмах - &amp;quot;Минитмены&amp;quot;. И они же в нас полетят, если что. Кроме собственно пусков ракет в фильмах любят показывать сложные шаманские танцы вокруг пуска. Офицер связи при получении приказа на пуск достаёт из сейфа конверт, код оттуда посимвольно зачитывается и вводится в пульт. Потом синхронно два офицера поворачивают два ключа... Весь этот балет придумал Роберт Стрэйндж Макнамара - человек, которого Кеннеди переманил в министры обороны из президентов &amp;quot;Форда&amp;quot;. Идея была очень разумная - не упускать из рук политиков управление ядерным арсеналом страны и не допустить самовольных или случайных пусков. Военные тоже были люди разуминые. Они провели несколько учений и поняли, что шаманские танцы вокруг ввода кода задерживают запуск. В худшем случае офицеры в состоянии стресса умудрялись даже делать ошибку в коде. Поскольку помимо учений межконтинентальные баллистические ракеты с ядерными боеголовкамии ещё и стоят наготове для оперативного отражения удара противника, Стратегическое командование ВВС США (в Штатах МБР шахтного базирования - это ВВС) приказало установить все предохранительные коды на всех пультах всех &amp;quot;Минитменов&amp;quot; в 00000000. Сия нехитрая рационализация резко повысила шансы Соединённых Штатов Америки успеть ответить ударом на удар. Макнамара узнал обо всём этом только полвека спустя. Случайно. Ему бывший ракетчик рассказал. Сейчас, естественно, там уже не нули.