Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

разработка безопасного кода

•Download as PPTX, PDF•
•
Andrey Somsikov
Andrey Somsikov

Secure coding guidelines for University students (http://www.wl.unn.ru/).

1 of 30
Андрей Сомсиков andrey.somsikov@gmail.com
 Не используйте лабораторные машины для тестирования на безопасность ◦ Требуется разрешение от лаборанта  Последствия ◦ Лишение прав доступа ◦ Переустановка OS
 Создание безопасного ПО  Написание безопасного кода  Обзор решения Microsoft
 Безопасность (Security) ◦ Is the condition of a system that results from the establishment and maintenance of measures to protect the system. ◦ Security is an aspect of a product, not a feature. ◦ Устойчивость к воздействиям.  Защита персональных данных (Privacy) ◦ Право на неприкосновенность частной жизни.  Угроза (англ. threat) – возможная опасность.  Риск (англ. risk) – количественная оценка угрозы.
Обзор
 ПО получает все большее распространение ◦ Банковские и финансовые системы ◦ Государственные системы ◦ Персональные системы  Рост киберпреступности ◦ Повышение профессионализма хакеров ◦ Появление новых бизнес моделей ◦ Низкий уровень компьютерной грамотности пользователей  Проблемы безопасности обходятся дорого ◦ Security incident handling (≈$100K-$500K) ◦ Негативное и широкое освещение в прессе ◦ Недовольство пользователей
 Жизненный цикл разработки ПО ◦ Разбиение процесса на стадии ◦ Нет общепринятого стандарта:  Microsoft SDL (http://msdn.microsoft.com/security)  Intel SDL  Безопасность должна быть на всех стадиях: ◦ Тренинги по безопасности ◦ Моделирование угроз ◦ Тестирование на безопастность ◦ ... Проектирование Написание Тестирование Поддержка
 Анализируют уязвимые места дизайна или реализации ПО: ◦ Исследуют взаимодействие с системой ◦ Собирают и анализируют выходные данные ◦ Изучают компоновку системы и потоки данных ◦ Ищут применимость опубликованных атак и уязвимостей  Инструменты ◦ SoftIce, WinDBG, OllyDebug, gdb/kdb, сетевые сканеры, ... ◦ Dump памяти, depends, dumpbin (дисассемблирование), декомпиляторы, ... ◦ Fuzzers – подача случайных входных данных
разработка безопасного кода
 Проверка входных данных ◦ “All input is evil, until proven otherwise” ◦ Проверяйте неправильность входных данных:  Формат, длина, тип, интервал  Уменьшай площадь атаки ◦ Используй только необходимые сервисы и оганичивай время их использования  Файлы, устройства, сторонние компоненты ◦ Все методы взаимодействия с ПО должны быть документированы и протестированы  Отсутствие «секретного» API или скрытой функциональности
 Использовать минимально необходимые привилегии ◦ Проверяй запуск приложения с пользовательскими правами доступа:  user/guest, доступ к системным папкам  User Account Control (UAC) должен быть включен  Многоуровневая защита ◦ Несколько уровней защиты ПО повышают стойкость к взлому  Firewall, проверка входных данных, аутентификация и авторизация.
 Неизвестность≠ Защищенность ◦ Сокрытие может быть только дополнительным уровнем защиты.  Готовность к нештатным ситуациям ◦ Ошибка не должна приводить систему в небезопасное состояние. ◦ Сообщение об ошибках не должно бфть слишком детальным  «Неверное имя пользователя или пароль» ◦ Журнал ошибок должен быть доступен только авторизованным пользователям
 Тесты на безопасность ◦ Тесты на распространенные ошибки ◦ Проверки на недокументированное поведение ◦ ...  Учеба на ошибках ◦ Документируй и анализируй ошибки
разработка безопасного кода
 Переполнение буфера - происходит при записи данных в память за границу выделенной области: ◦ На стеке (stack) ◦ В динамической памяти (heap)  Сложно но возможно в managed коде (C#, Java)  Цели: ◦ Исполнение вредоносного кода, ◦ Получение доступа к информации, ◦ Нарушение стабильной работы.
Buffers Other vars EBP EIP Args void func(char *p, int i) { int j = 0; CFoo foo; int (*fp)(int) = &func; char b[128]; strcpy(b,p); } Адрес возврата функции Обработчики исключений Указатели на функции Виртуальные методы Задают порядок исполнения кода Исполнения вредоносного кода возможно если * p будет больше буфера b 16
• Пример 2: #define MAX (50) char szDest[MAX]; strncpy(szDest,pszSrc,MAX); • Пример 1: // Code verifies pszSrc is <= 50 chars) // pszSrc is a char * #define MAX (50) char *pszDest = malloc(sizeof(pszSrc)); strncpy(pszDest,pszSrc,MAX); 17 Переполнение буфера возможно даже при использованиии n-функций sizeof(pszSrc) 4 байта, а не 50 szDest не будет null- terminated если длина pszSrc >= MAX
Уязвимость в модуле mod_ssl (версии до 2.8.10). ... char *cp; char caCmd[1024]; char *cpArgs; ... cp = (char *)oline; for (i = 0; *cp !=' ' && *cp !='t' && *cp != NUL && i < 1024; ) caCmd[i++] = *cp++; caCmd[i] = NUL; cpArgs = cp; ... Возможно выполнение произвольного кода. ^^^^^^^^
Поиск и исправление ошибок переаолнения буфера Уменьшить площадь атаки Security Code Review – Поиск уязвимостей до выпуска продукта Использовать более безопасную функциональность (strsafe, Safe CRT, STL) Опции сборки кода: /GS, NX, Heap Checking, ... Инструменты для анализа кода на безопасность FuzzTesting - Тесты со случайными входными данными 19
 Переполнение (overflow/underflow). unsigned int a = 0xefffffff; unsigned int b = a + 2;  Потеря или приобретение знака int c = a  Потеря старших разрядов char d = a; 20 Арифметические ошибки приводят к переполнению буфера
void Example(char * str, int size) { char buf[80]; // Check to make sure size is ‘valid’ if (size < sizeof(buf)) { // Should be safe to copy str strcpy(buf,str); } } 21
 Тщателно проверяйте вычисления сдвигов в массивах, адресов памяти  Используйте беззнаковые типы для: ◦ Индексов ◦ Размеров буферов ◦ Closely examine any calculation used to determine an array offset or memory location  Обращайте внимания на предупреждения b ошибки компилятора а также на иструкции по отключению ошибок (#pragma) 22
 Данные представленые по разному могут быть эквивалентны: ◦ filename_secret.ext ≡ filena~1.ext ◦ www.site.ru/secret ≡ www.site.ru/%73ecret  Проблемы с использованием канонических представлений: проверки безопасности ориентированы на одно представление данных, хотя фактически может быть использовано другое 23 Используются для обхода проверок
SecretFile.txt SecretFile.txt. Secret~1.txt SecretFile.txt::$Data String FileName = System.Console.ReadLine(); if (FileName.ToLower().Equals(“secretfile.txt”)) { // deny access to file } else { // grant access to file } 24 Именем файла может быть “Secret~1.txt” или “SecretFile.txt::$Data”?
• Приводите к канонической форме перед использованием или проверкой. • Используйте возможности операционной системы для приведения к канонической форме • Используйте регулярные выражения для поиска запрещенных символов 25
 Только правильное использование криптографии позволит защитить данные и скрыть секреты ◦ Некоторые алгоритмы признаны взламываемыми: MD4, MD5, RC4, DES, SHA1. ◦ Существуют атаки на некоторые реализации алгоритмов: RSA, AES ◦ NIST – как правильно применять алгоритмы  Проблемы хранения, использования и уничтожения секретных данных в памяти.  Генерация случайных данных.
 Используйте стандартные реализации алгоритмов SSL, CryptoAPI.  Не разрабатывайте собственный алгоримы - используйте проверенные.  Используйте правильные генераторы случайных чисел.  Обновляйте ключи переодически.  Используйте специальные функции для очиски памяти SecureZeroMemory.
 DOS Attck – Атака на систему призванная привести к отказу в обслуживании  Остновные векторы атаки: ◦ Остановка или падение системы (проверка входных данных, переполнение буфера, арифметическая ошибка) ◦ Перегрузка CPU ◦ Нехватка памяти, ресурсов ◦ Загрузка сети
 Аутентификация и авторизация ◦ Доступ к ресурсам должны иметь только авторизованные пользователи.  Фильтрация ◦ Проверка входных данных  Ограничения ◦ Не позволять использовать максимальное количество ресурса.
 http://msdn.microsoft.com/ru- ru/magazine/cc163518.aspx - Безопасные привычки: 8 простых правил для разработки более безопасного кода  http://msdn.microsoft.com/ru- ru/security/default.aspx - Центр безопасности  http://www.microsoft.com/security/sdl/defa ult.aspx - Microsoft Security Development Lifecycle

More Related Content

разработка безопасного кода

  • 2.  Не используйте лабораторные машины для тестирования на безопасность ◦ Требуется разрешение от лаборанта  Последствия ◦ Лишение прав доступа ◦ Переустановка OS
  • 3.  Создание безопасного ПО  Написание безопасного кода  Обзор решения Microsoft
  • 4.  Безопасность (Security) ◦ Is the condition of a system that results from the establishment and maintenance of measures to protect the system. ◦ Security is an aspect of a product, not a feature. ◦ Устойчивость к воздействиям.  Защита персональных данных (Privacy) ◦ Право на неприкосновенность частной жизни.  Угроза (англ. threat) – возможная опасность.  Риск (англ. risk) – количественная оценка угрозы.
  • 6.  ПО получает все большее распространение ◦ Банковские и финансовые системы ◦ Государственные системы ◦ Персональные системы  Рост киберпреступности ◦ Повышение профессионализма хакеров ◦ Появление новых бизнес моделей ◦ Низкий уровень компьютерной грамотности пользователей  Проблемы безопасности обходятся дорого ◦ Security incident handling (≈$100K-$500K) ◦ Негативное и широкое освещение в прессе ◦ Недовольство пользователей
  • 7.  Жизненный цикл разработки ПО ◦ Разбиение процесса на стадии ◦ Нет общепринятого стандарта:  Microsoft SDL (http://msdn.microsoft.com/security)  Intel SDL  Безопасность должна быть на всех стадиях: ◦ Тренинги по безопасности ◦ Моделирование угроз ◦ Тестирование на безопастность ◦ ... Проектирование Написание Тестирование Поддержка
  • 8.  Анализируют уязвимые места дизайна или реализации ПО: ◦ Исследуют взаимодействие с системой ◦ Собирают и анализируют выходные данные ◦ Изучают компоновку системы и потоки данных ◦ Ищут применимость опубликованных атак и уязвимостей  Инструменты ◦ SoftIce, WinDBG, OllyDebug, gdb/kdb, сетевые сканеры, ... ◦ Dump памяти, depends, dumpbin (дисассемблирование), декомпиляторы, ... ◦ Fuzzers – подача случайных входных данных
  • 10.  Проверка входных данных ◦ “All input is evil, until proven otherwise” ◦ Проверяйте неправильность входных данных:  Формат, длина, тип, интервал  Уменьшай площадь атаки ◦ Используй только необходимые сервисы и оганичивай время их использования  Файлы, устройства, сторонние компоненты ◦ Все методы взаимодействия с ПО должны быть документированы и протестированы  Отсутствие «секретного» API или скрытой функциональности
  • 11.  Использовать минимально необходимые привилегии ◦ Проверяй запуск приложения с пользовательскими правами доступа:  user/guest, доступ к системным папкам  User Account Control (UAC) должен быть включен  Многоуровневая защита ◦ Несколько уровней защиты ПО повышают стойкость к взлому  Firewall, проверка входных данных, аутентификация и авторизация.
  • 12.  Неизвестность≠ Защищенность ◦ Сокрытие может быть только дополнительным уровнем защиты.  Готовность к нештатным ситуациям ◦ Ошибка не должна приводить систему в небезопасное состояние. ◦ Сообщение об ошибках не должно бфть слишком детальным  «Неверное имя пользователя или пароль» ◦ Журнал ошибок должен быть доступен только авторизованным пользователям
  • 13.  Тесты на безопасность ◦ Тесты на распространенные ошибки ◦ Проверки на недокументированное поведение ◦ ...  Учеба на ошибках ◦ Документируй и анализируй ошибки
  • 15.  Переполнение буфера - происходит при записи данных в память за границу выделенной области: ◦ На стеке (stack) ◦ В динамической памяти (heap)  Сложно но возможно в managed коде (C#, Java)  Цели: ◦ Исполнение вредоносного кода, ◦ Получение доступа к информации, ◦ Нарушение стабильной работы.
  • 16. Buffers Other vars EBP EIP Args void func(char *p, int i) { int j = 0; CFoo foo; int (*fp)(int) = &func; char b[128]; strcpy(b,p); } Адрес возврата функции Обработчики исключений Указатели на функции Виртуальные методы Задают порядок исполнения кода Исполнения вредоносного кода возможно если * p будет больше буфера b 16
  • 17. • Пример 2: #define MAX (50) char szDest[MAX]; strncpy(szDest,pszSrc,MAX); • Пример 1: // Code verifies pszSrc is <= 50 chars) // pszSrc is a char * #define MAX (50) char *pszDest = malloc(sizeof(pszSrc)); strncpy(pszDest,pszSrc,MAX); 17 Переполнение буфера возможно даже при использованиии n-функций sizeof(pszSrc) 4 байта, а не 50 szDest не будет null- terminated если длина pszSrc >= MAX
  • 18. Уязвимость в модуле mod_ssl (версии до 2.8.10). ... char *cp; char caCmd[1024]; char *cpArgs; ... cp = (char *)oline; for (i = 0; *cp !=' ' && *cp !='t' && *cp != NUL && i < 1024; ) caCmd[i++] = *cp++; caCmd[i] = NUL; cpArgs = cp; ... Возможно выполнение произвольного кода. ^^^^^^^^
  • 19. Поиск и исправление ошибок переаолнения буфера Уменьшить площадь атаки Security Code Review – Поиск уязвимостей до выпуска продукта Использовать более безопасную функциональность (strsafe, Safe CRT, STL) Опции сборки кода: /GS, NX, Heap Checking, ... Инструменты для анализа кода на безопасность FuzzTesting - Тесты со случайными входными данными 19
  • 20.  Переполнение (overflow/underflow). unsigned int a = 0xefffffff; unsigned int b = a + 2;  Потеря или приобретение знака int c = a  Потеря старших разрядов char d = a; 20 Арифметические ошибки приводят к переполнению буфера
  • 21. void Example(char * str, int size) { char buf[80]; // Check to make sure size is ‘valid’ if (size < sizeof(buf)) { // Should be safe to copy str strcpy(buf,str); } } 21
  • 22.  Тщателно проверяйте вычисления сдвигов в массивах, адресов памяти  Используйте беззнаковые типы для: ◦ Индексов ◦ Размеров буферов ◦ Closely examine any calculation used to determine an array offset or memory location  Обращайте внимания на предупреждения b ошибки компилятора а также на иструкции по отключению ошибок (#pragma) 22
  • 23.  Данные представленые по разному могут быть эквивалентны: ◦ filename_secret.ext ≡ filena~1.ext ◦ www.site.ru/secret ≡ www.site.ru/%73ecret  Проблемы с использованием канонических представлений: проверки безопасности ориентированы на одно представление данных, хотя фактически может быть использовано другое 23 Используются для обхода проверок
  • 24. SecretFile.txt SecretFile.txt. Secret~1.txt SecretFile.txt::$Data String FileName = System.Console.ReadLine(); if (FileName.ToLower().Equals(“secretfile.txt”)) { // deny access to file } else { // grant access to file } 24 Именем файла может быть “Secret~1.txt” или “SecretFile.txt::$Data”?
  • 25. • Приводите к канонической форме перед использованием или проверкой. • Используйте возможности операционной системы для приведения к канонической форме • Используйте регулярные выражения для поиска запрещенных символов 25
  • 26.  Только правильное использование криптографии позволит защитить данные и скрыть секреты ◦ Некоторые алгоритмы признаны взламываемыми: MD4, MD5, RC4, DES, SHA1. ◦ Существуют атаки на некоторые реализации алгоритмов: RSA, AES ◦ NIST – как правильно применять алгоритмы  Проблемы хранения, использования и уничтожения секретных данных в памяти.  Генерация случайных данных.
  • 27.  Используйте стандартные реализации алгоритмов SSL, CryptoAPI.  Не разрабатывайте собственный алгоримы - используйте проверенные.  Используйте правильные генераторы случайных чисел.  Обновляйте ключи переодически.  Используйте специальные функции для очиски памяти SecureZeroMemory.
  • 28.  DOS Attck – Атака на систему призванная привести к отказу в обслуживании  Остновные векторы атаки: ◦ Остановка или падение системы (проверка входных данных, переполнение буфера, арифметическая ошибка) ◦ Перегрузка CPU ◦ Нехватка памяти, ресурсов ◦ Загрузка сети
  • 29.  Аутентификация и авторизация ◦ Доступ к ресурсам должны иметь только авторизованные пользователи.  Фильтрация ◦ Проверка входных данных  Ограничения ◦ Не позволять использовать максимальное количество ресурса.
  • 30.  http://msdn.microsoft.com/ru- ru/magazine/cc163518.aspx - Безопасные привычки: 8 простых правил для разработки более безопасного кода  http://msdn.microsoft.com/ru- ru/security/default.aspx - Центр безопасности  http://www.microsoft.com/security/sdl/defa ult.aspx - Microsoft Security Development Lifecycle

Editor's Notes

  1. Todo: цитировать закон
  2. http://secunia.com/advisories/33089/ - Internet Explorer Data Binding Memory Corruption Vulnerability
  3. Todo put NIST address
  4. DoS-атака (от англ. Denial of Service, отказ в обслуживании) — атака на вычислительную систему с целью вывести её из строя, то есть создание таких условий, при которых легитимные (правомерные) пользователи системы не могут получить доступ к предоставляемым системой ресурсам, либо этот доступ затруднён. http://ru.wikipedia.org/wiki/DoS-%D0%B0%D1%82%D0%B0%D0%BA%D0%B0