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

2. Цели:
1. Повысить осведомленность в области информационной безопасности
2. Собрать и предоставить полезную информацию в удобном формате
3. Заинтересовать к самостоятельному изучению
4. Показать необходимость предметной области
5. Контент должен быть дополняемым и расширяемым

3. Что такое уязвимости?
Уязвимости – это ошибки
Скорее всего их уже кто то допускал
«Без требований или проектирования,
программирование – это искусство добавления ошибок в пустой текстовый файл»
Именно поэтому важно понимать основные угрозы и типичные ошибки или уязвимости,
допускаемые разработчиками при создании аналогичных решений, и не допускать их.
Уязвимости, которые позволяют скомпрометировать Вашу систему – это ни что иное
как ошибки которые были допущены на этапах:
 Проектирования
 Разработки
 Внедрения

4. Уязвимость – ошибка в программном коде или конфигурации системы,
эксплуатация которой приводит к нарушению штатной работы системы,
раскрытию чувствительной информации, утечке или подмене
информации, успешному внедрению и распространению вредоносного
кода.
Эксплойт (Exploit) – программа, реализующая успешную эксплуатацию
уязвимости и содействующая выполнению вредоносного кода на
целевой системе.
Proof-of-Concept (PoC) – демонстрационный эксплойт, не приводящий к
злонамеренным действиям, а служащий лишь для иллюстрации того,
каким образом может быть использована уязвимость.
Терминология

5.  По уровню критичности
 Высокий
 Средний
 Низкий
 Информационный
 По типу программного обеспечения
 Системное
 Прикладное
 По этапу SDLC
 Проектирование
 Компиляция
 Инсталляция
 По причине возникновения
 Недостатки механизмов аутентификации
 Использование функций, допускающих деструктивные действия
 Отсутствие проверки корректности вводимых данных
 Использование настроек по умолчанию
 По характеру влияния на систему
 Переполнение буфера
 Повышение прав в системе (Privileges Escalation)
 Допуск подбора паролей (brute force)
 Отказ в обслуживании (DoS – Denial of Service)
Классификация уязвимостей

6. Система оценки уязвимостей (Common
Vulnerability Scoring System – ) – система,
которая позволяет проводить сравнение
уязвимостей программного обеспечения по
степени их опасности для конечной системы.
Актуальные метрики CVSS v2 и CVSS v3.
Система оценки (метрики)
Я кликабельная

7.  СVE (Common Vulnerabilities and Exposures).
Формат: CVE -%YYYY%-ID.
Для быстрого поиска введите в поисковик название
вашей технологии + CVE и получите перечень
известных уязвимостей в зависимости от версии.
Популярные классификаторы уязвимостей

8.  BID (Bugtraq ID). Данная классификация присутствует
исключительно на портале Securityfocus. Совместима с
классификатором CVE (содержит ссылку на базу CVE).
 OSVDB (Open Source Vulnerabilities DataBase) - Помимо
основной информации об уязвимости, описывает такие
понятия как: локация эксплуатации (сетевой доступ/локальный
доступ), импакт (ущерб от уязвимости, воздействие на какую-
либо часть целевой информационной системы).
 Microsoft Security Bulletins – TechNet – предоставлен поиск по
уязвимостям продуктов компании Микрософт,
например ms-08-067
Популярные классификаторы уязвимостей

9.  В зависимости от метода получения доступа к уязвимому программному обеспечению
 Удалённый эксплоит
 Локальный эксплоит
 В зависимости от предназначения для выполнения сторонних действий на уязвимой
системе
 Эксплоиты для операционных систем
 Эксплоиты для прикладного ПО (музыкальные проигрыватели, офисные пакеты и т. д.)
 Эксплоиты для браузеров (Internet Explorer, Mozilla Firefox, Opera и другие)
 Эксплоиты для интернет-продуктов (IPB, WordPress, VBulletin, phpBB)
 Эксплоиты для интернет-сайтов (facebook.com, hi5.com, livejournal.com)
Классификация Эксплойтов

10. Зачастую, для проверки всех возможных уязвимостей своего ПО нужно
проверить как базы данных уязвимостей так и базы данных эксплоитов, с
помощью которых возможно взломать модули вашей системы.
Базы Эксплойтов
Exploits Database by Offensive Security – Эта база данных
эксплойтов широко популярна, но не всегда содержит
эксплоиты к последним версиям
Для практической проверки уязвимостей экплоитами
можно использовать фремворки, например metasploit
framework, который уже установлен в Kali Linux –
операционную систему, заточенную на тестирование и
эксплуатацию узявимостей

11. Не всегда возможно найти бесплатные эксплоиты под
уязвимые системы, однако могут существовать их платные
аналоги, так называемые zero day эксплойты, наличие
которых тоже нужно проверять для вашей системы.
Например, http://0day.today/ или другие, которые не так
просто доступны.
Базы Эксплойтов

12. Основные стандарты
в зависимости от
направления разработки

13. Преимущества стандартов
Перед началом разработки важно ознакомиться с основными стандартами
информационной безопасности и уязвимостями / векторами атак, которые можно
применить к Вашей платформе, языку программирования и т.д.
Это позволит:
Минимизировать риски
(злоумышленники обычно сами
пользуются этой информацией)
Сэкономить время на разработку (зачастую
стандарты предоставляют примеры реализации
и лучшие практики, которые вы можете
гарантировано использовать, не перерывая
стековерфлоу и не создавая велосипеды)

14. Направления разработки
Зачастую рекомендации отличаются в зависимости от направления разработки
 Веб приложения и сервисы
 Десктопные приложения и системные службы
 Мобильные приложения
 Низкоуровневое ПО для устройств, драйверов и т.д.
Каждый язык программирования имеет свои особенности которые нужно учитывать

15. Веб приложения и сервисы
Open Web Application Security Project (OWASP)
международная некоммерческая организация,
сосредоточенная на анализе и улучшении
безопасности программного обеспечения веб
приложений
Web Application Security Consortium
международная некоммерческая группа
экспертов, практиков и представителей
организаций, которые производят открытые
и согласованные с лучшими практиками
стандарты для WWW
Превосходное практическое описание угроз
WASC THREAT CLASSIFICATION

16. Десктопные приложения и системные службы
SEI CERT Coding Standards (С, С++, Java, Perl)
MSDN Secure Coding Guidelines (.NET/C#) 1 2 3
 National Institute of Standards and Technology (NIST)
Guidelines to Help IT System Developers Build-In
Security

17. Мобильные приложения
OWASP
Mobile Security Project
 SEI CERT
 Coding Standards (Android)
Android Application Secure Design
Secure Coding Guidebook
Secure Coding Guidelines
For Android Developer

18. Низкоуровневое ПО для устройств, драйверов
 CERT
 C Programming Language
 Secure Coding Standard
The art of
Software Security Sssessment

19. Веб приложения и
сервисы

20. Security Development Lifecycle (SDL) – must have

21. Валидация входящих параметров
Никогда не доверяйте пользовательским данным !
Неспособность должным образом проверить ввод приводит к почти всем основным уязвимостям
в приложениях (интерпретируемые инъекции, атаки locale/Unicode, атаки на файловую систему и
переполнения буфера)
И что же делать?
 Валидируйте входящие данные  Кодируйте исходящие данные
«Все пользовательские входные данные небезопасны
пока не доказано обратное или пока они не проверены»
Я кликабельная

22. Не доверяйте даже своим собственным запросам!
CSRF (cross-site request forgery) и Clickjacking -
два примера того как злонамеренный запрос
инициируется с Вашего браузера, используя
Ваши данные.

23. Cross-Site Request Forgery (CSRF)
CSRF – атака, которая приводит к тому,
что злоумышленник может выполнить на
неподготовленном сайте различные действия
от имени других, зарегистрированных посетителей.
Внедряйте анти-CSRF токены!
Для Java 1 2
Для .NET

24. Cross-Site Request Forgery (CSRF)
AutoValidateAntiforgeryToken
IgnoreAntiforgeryToken - для страниц где нет активных операций, например лендинг без авторизации или
информационные страницы

25. Clickjacking
Атака Clickjacking позволяет злоумышленнику
выполнить клик на сайте-жертве от имени посетителя.
Настройте Заголовок X-Frame-Options
Для Java
Для .NET

26. Многоуровневый подход
Проверка целостности гарантирует что данные не были изменены
при обновлении ПО и конфигураций,
когда данные приходят с доверенной границы в не доверенную и
возвращаются, например:
 <input type=”hidden”>
 платежный шлюз
Методы проверки целостности:
 Контрольная сумма
 HMAC
 Шифрование
 Цифровая подпись
Я кликабельная
Валидация внедряется на каждом уровне:
уровень представления для проблем с данными
переданными через HTML
уровень хранения данных для противодействия SQL
инъекциям
Я кликабельная

27. Многоуровневый подход
 Бизнес правила
 Обеспечить соблюдение контекста
 Тщательное документирование и тестирование
 Рассматривайте крайние случаи (в том числе INFINITY и NaN)
Примеры ошибок:
 E-trade и Schwab, в процессе регистрации, не провалидировали лимит одного банковского счета для
пользователя. Это позволило злоумышленнику присвоить один и тот же счет в банке десяти тысячам
пользователей и это привело к потере $50,000.00.
 QVC потерял больше чем $412,000.00 когда одна женщина определила что она может делать покупки
через QVC, а потом сразу отменять их, но все равно получать товар.
 Злоумышленник, в качестве законного eBay покупателя был в состоянии приобрести компьютер,
удалить дорогостоящие компоненты из него, а затем вернуть его как «поломанный» продавцу,
успешно минуя бизнес-политики eBay, Paypal и UPS.
Примеры взяты с: http://projects.webappsec.org/Insufficient-Process-Validation

28. Стратегии валидации данных
 Пропускайте только заведомо валидные данные (whitelisting)
 Параметры должны быть проверены в отношении положительных спецификаций:
 Тип данных (string, integer, real, etc…)
• Минимальная и максимальная длина/значение
• Разрешен ли null
• Требуется ли параметр или нет
• Числовой диапазон
• Specific patterns (regular expressions)
 Откажитесь от блокирования заведомо не валидных (blacklisting)
 Не валидные данные не должны пропускаться. Их обработка (частичное удаление) или
приведение в корректный вид может содержать уязвимости, например если вы удалите
слово script со стоки <SCRscriptIPT>alert(‘XSS’)</SCRsciptIPT>

29. Аутентификация
Идентификация пользователя / credentials
Привязать системную сущность к личности
Связать с оценкой рисков
Выбирайте контроль аутентификации базируясь на рисках
Детектируйте и блокируйте злоумышленника
Все инциденты, например подбор пароля, должны детектироваться в журнальных файлах.
Должны быть разработаны механизмы противодействия этим атакам

30. Лучшие практики
Процесс управления пользователями
Сложность аутентификации зависит от критичности актива
Пароли для простых систем, без критических ресурсов
+ SMS для простых платежных систем (онлайн банкиг)
+ Токены для сложных платежных систем с высокими оборотами и критичными активами
Повторная аутентификация на границе подсистем приложения или между разными
системами предприятия, например при переходе с онлайн банкинга в кабинет ведения
бизнеса
Пароли подбираются – блокируйте и детектируйте это!!!
Любой пароль длиной меньше чем 16 символов может быть подобран в течении 2 недель, если нет механизмов
блокировки подбора
Также лучшие практики на OWASPе

31. Логины и пароли
Пускай пользователь сам определяет логин
 Так их тяжелее перечислить
 Избегайте использовать для логина Firstname.Lastname, e-mail, номер кредитной карты или еще какую ни
будь публичную информацию
Парольные политики
 Надежность! Минимум 8 символов, но чем больше тем лучше, спецсимволы, цифры, кириллица и
латиница
 Контроль смены пароля! Чем чаще тем лучше, хотя если вы заставите пользователя менять пароль
каждый день то он будет записывать их на стикере
 Хранение пароля в хешированном виде и обязательно с солью! Если у вас угонят базу то хоть будет время
сменить доступа)
Безопасный транспорт(SSL) + проверка в коде: [if(server_port == 443)]
Очень внимательно реализуйте функционал забытого пароля
Удалите или заблокируйте дефолтные или тестовые учетки
Запретите кеширование заголовков HTTP и мета тегов
<form … AUTOCOMPLETE="off"> - для всех полей формы
<input … AUTOCOMPLETE="off"> - для одного поля

32. Строгая Аутентификация
Двухфакторная аутентификация: что то что у вас есть, вы знаете, вы собой представляете
В дополнение к паролям:
Одноразовые пароли (OTP), минимальное время жизни и количество попыток
Программные сертификаты, в том числе и Certificate and Public Key Pinning 1 2
Подключайте аппаратные сертификаты
Запрос ответа по СМС
Подписание транзакций

33. Положительная аутентификация
(все параметры заведомо не определены или false)
bAuthenticated := false
securityRole := null
try {
userrecord := fetch_record(username)
if userrecord[username].password != sPassword then
throw noAuthentication
end if
if userrecord[username].locked == true then
throw noAuthentication
end if
if userrecord[username].securityRole == null or banned then
throw noAuthentication
end if
… other checks …
bAuthenticated := true
securityRole := userrecord[username].securityRole
}
catch {
bAuthenticated := false
securityRole := null
// perform error handling, and stop
}
return bAuthenticated

34. Авторизация
Удостоверяет привилегии для доступа к ресурсам
и для выполнения действий
В основном базируется на ролевой политике

35. Лучшие практики
Принцип минимальных привилегий
Централизованные механизмы авторизации
Матрица авторизации (авторизация проверяется на каждой странице)
Контроль доступа для защиты ресурсов (приложение контролирует не только возможность передачи
средств, но и с какого счета)
Защищенный доступ к статическим и сгенерированным ресурсам
Будьте осторожны при контроле авторизации (лучше всего используйте фреймворки)
Никогда не внедряйте проверку и генерацию токенов на стороне клиента (cookies, заголовки, скрытые
поля, контейнеры браузера)
Разделяйте способы авторизации и функционал администратора и пользователя
Анализ кода Авторизации

36. Управление сессиями
HTTP - протокол не имеющий состояний
Определяйте пользователя по запросу
J2EE, PHP, ASP.NET имеют встроенные механизмы сессий
Cookies !

37. Лучшие практики
Используйте фреймворки
Сохраняйте информацию в сессии на стороне сервера
Ограничивайте время жизни сессии
Внедряйте функцию выхода и завершения сессии
Генерируйте новые токены
Во время log-on / log-off (без этого возможна атака на подбор фиксированного токена сессии )
После определенного количества времени
Детектируйте, логируйте атаки подбора
HTTPS!

38. Предотвращение инъекций
Чтоб понять от чего защищаться надо понять чего бояться
XSS Cross-Site Scripting
«межсайтовый скриптинг» — тип атаки на веб-системы,
заключающийся во внедрении в выдаваемую веб-
системой страницу вредоносного кода (который будет
выполнен на компьютере пользователя при открытии
им этой страницы) и взаимодействии этого кода с веб-
сервером злоумышленника.
Примеры обнаружения XSS уязвимости 1 2

39. Предотвращение инъекций
SQLi SQL injection —
один из распространённых способов
взлома сайтов и программ, работающих с базами данных,
основанный на внедрении в запрос произвольного SQL-кода.
Внедрение SQL, в зависимости от типа используемой СУБД и
условий внедрения, может дать возможность атакующему
выполнить произвольный запрос к базе данных (например,
прочитать содержимое любых таблиц, удалить, изменить или
добавить данные), получить возможность чтения и/или записи
локальных файлов и выполнения произвольных команд на
атакуемом сервере.
Атака типа внедрения SQL может быть возможна из-за
некорректной обработки входных данных, используемых в
SQL-запросах.

40. Предотвращение инъекций
LDAPi
(LDAP Injection) является методом
нападения, используемым для
эксплуатирования веб-сайтов, которые
формируют LDAP операторы из потока
входных данных от пользователей
XML-инъекция представляет собой
метод нападения на веб-приложения,
построенные на языке XML. Атака
заключается в нарушении логики
работы приложения с целью
выполнения произвольных
конструкций кода. Кроме того, XML-
инъекция может быть применена для
встраивания вредоносного
содержимого
XMLi

41. Предотвращение инъекций
XPATHi
OSi
XPath инъекция - атака направленная
на приложения, создающие XPath
(XML Path Language) запросы от
пользовательских данных
OS инъекция - атака направленная на
приложения, которые интерпретируют
команды

42. Атаки на перенаправление
Согласно Open Web Application Security Project, открытое перенаправление происходит, когда приложение
принимает параметр и перенаправляет пользователя к значению этого параметра без какой-либо
валидации и проверки содержимого этого параметра.
Промежуточное перенаправление — это простое перенаправление, следующее за другим перенаправлением,
где окончательное перенаправление становится возможным после указания на него первым.
https://hackerone.com/zendesk_session?locale_id=1&amp;retur
n_to=https://support.hackerone.com/ping/redirect_to_acc
ount?state=company:/
Я кликабельна

43. Предотвращение атаки на перенаправление
Invalidated Redirects and Forwards Cheat Sheet Preventing Open Redirection Attacks (C#)

44. Манипуляции с ID или IDOR (Insecure Direct Object Reference)
Манипулирование переменными и параметрами на
стороне клиента, при неправильном контроле доступа
к ресурсам других пользователей, может привести к
полному овладению аккаунтом жертвы (подмена при
подтверждении регистрации или смене пароля) либо же
другим опасным последствиям (регистрация платежей,
Загрузка чужих документов, смена конфигурации)
Для правильной защиты от атак этого типа необходимо
контролировать принадлежность пользователя и его
права доступа к выполнению всех запросов / операций.
Так же полезным будет минимизировать количество
параметров передаваемых пользователем (например
выдавать на фронт всю доступную информацию,
проверяя токен сессии), оставшиеся параметры
рекомендовано хешировать или кодировать.
Мы кликабельны

45. Загрузка файлов
 Применяйте whitelist для типов файлов
 Одинаковые проверки как на фронтенде так и на бекенде
 Не раскрывайте и не возвращайте путь куда был сохранен файл
 Проверяйте чтоб тип файла соответствовал его контенту
например по явным идентификаторам или применяя какие то действия
как изменение размера картинки
 Проверяйте размер файлов и так же другие их размерности, например
можно положить сервер обыкновенной картинкой если изменить ее
расширение в пикселях 64250x64250 – выделиться много памяти
 Не сохраняйте файл на основной сервер – используйте облака или
специальные файловые сервера и базы определенных типов
 Валидируйте файл по полному пути – возможны несколько расширений в файле
 Определитесь и проверяйте на бекенде Content-Type хедер
 Разрабатывайте свое приложение в соответствии с
Unrestricted File Upload

46. Server Side Request Forgery (SSRF)
Server Side Request Forgery (SSRF) - атака
позволяющая злоумышленику совершать запросы с
уязвимого сервера (сайта) во внутреннюю сеть
(Интранет). При этом нет возможности послать
прямой запрос во внутреннюю сеть атакуемой
инфраструктуры извне.
<?php /** * Check if the 'url' GET variable is set * Example -
http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif
*/
if (isset($_GET['url'])){ $url = $_GET['url']; /** * Send a request
vulnerable to SSRF since * no validation is being done on $url *
before sending the request */
$image = fopen($url, 'rb');
/** * Send the correct response headers */ header("Content-
Type: image/png"); /** * Dump the contents of the image */
fpassthru($image); }
GET /?url=file:///etc/passwd HTTP/1.1
Host: example.com
Я кликабельна
GET
/?url=http://169.254.169.254/latest/m
eta-data/ HTTP/1.1 Host:
example.com

47. Предотвращение Server Side Request Forgery (SSRF)
 Белые списки и разрешение DNS
 Обработка ответов
 Отключить неиспользуемые URL схемы
 Аутентификация внутренних служб
 Внедрить paranoid-request

48. Защита данных
 Никаких машинных клавиш
 Криптография высокого уровня из коробки
 Хранилище ключей из коробки
 Автоматическая замена ключей
 Обеспечение автоматической изоляции

49. Защитить / снять защиту

50. Password Hashing

51. Configuration
 HKLMSOFTWAREMicrosoftDotNetPackages Microsoft.AspNetCore.DataProtection
 EncryptionType
 DefaultKeyLifetime
 KeyEscrowSinks

52. Лучшие практики
API вместо CMD
XSS:
Входящая валидация
Кодирование исходящих данных
Библиотеки Anti-XSS 1 2 3 4
SQLi:
Входящая валидация
Строгая типизация
Хранимые процедуры
Принцип минимальных привилегий

53. Криптография
Сложно сделать правильно!
Функции:
Аутентификация
Неотрекаемость (Non-repudiation)
Конфиденциальность
Целостность
Алгоритмы:
Симметричный
Асимметричный
Хеши

54. Лучшие практики
Не перепутайте с кодированием, криптография использует ключи!
Используйте безопасные алгоритмы, не изобретайте свои собственные и не используйте
устаревшие
Тщательно определяйте длину ключа и алгоритм
Симметричные: минимум 128 бит
Асимметричный: минимум 1536 бит
Хеши: минимум 128 бит
Разрабатывайте приложение с учетом
рекомендаций длины ключа по состоянию на текущее время
Защищайте ключи

55. Обработка ошибок аудит и логирование
Отслеживайте и обрабатывайте ошибки приложения
Безопасность ошибок – не раскрывайте информацию
Структурированная обработка ошибок
Безопасные ошибки (Fail Safe)
Ошибки выводятся конечному пользователю в
обобщенном виде с минимальной детализацией: «что то
пошло не так»
Отключайте отладку на продуктивных системах
Не выводите трассировку стека или приватную
информацию
Предусмотрите обработку ошибок на разных уровнях,
отображайте их в логах и внедряйте системы
мониторинга событий и инцидентов информационной
безопасности (SIEM)
Я кликабельная

56. Аудит и логирование
Отслеживайте события в рамках приложения
Атрибуты (отслеживайте изменения состояний пользователя)
Отслеживайте все уровни приложения
Гарантированная целостность (не модифицируемые логи)
Двойная цель логирования (аудит и мониторинг)
Любая обработка даже просмотр осуществляется с копией логов
Сохраняйте логи безопасно и конфиденциально даже во время бекапа
Проверьте юридические требования
Аудируйте только действительно важную информацию
Централизованное логирование
Анализируйте только копии логов
Отсылайте, копируйте, дублируйте логи только доверенным системам и
доверенным (которые имеют соответствующие права) сотрудникам
Использование носителей с однократной записью или аналогичных

57. Файловая система
Защита от создания, модификации и удаления
Дефейс. Злоумышленник использует различные
техники или ошибки конфигурации чтобы загрузить
вредоносный контента поверх существующих файлов.
Не дайте этим ребятам издеваться над вашей
системой.
Защищайтесь! 1 2
Еще примеры защиты от внедрение файлов 1 2 3

58. Лучшие практики
“chroot” операция для Unix систем
Минимальные права к файловой системе
Права только на чтение (RO) где только возможно
Не используйте указанные пользователем имена файлов при сохранении или работе локальными
файлами.
Валидация входящих параметров
Убедитесь что пользователь не может подавать все части пути – окружите их своими путями в коде
Используйте robots.txt – контролируйте поисковые машины
Удаляйте все неиспользуемые файлы или файлы бекапов или устаревших (тестовых) версий систем
Защищайте временные файлы
Запретите просмотр файлов (browsing)

59. Конфигурация
Безопасность
Общая ответственность
Ответственность разработчиков
Ответственность администраторов
Ответственность операторов
Настройки безопасности должны быть предустановлены, задокументированы и
контролироваться механизмами Управления Изменениями (Change Management)!
Выключите все ненужные фичи по умолчанию
Не используйте дефолтные аккаунты
Конечно же не встраивайте бекдоры
Никаких чистых паролей в конфигурации
SSL / SSH
Оперативно обновляйте операционную систему, программное обеспечение, библиотеки.
Обновления сначала проводите на тестовых средах

60. Web 2.0
Те же самые проблемы безопасности что и для других веб-систем
Сложность, двунаправленность и асинхронность только увеличивают вектор атаки
Также должны иметь безопасные:
Передачу данных
Аутентификацию и управление сессиями
Контроль доступа
Валидацию входящих параметров
Обработку ошибок и логирование

61. Сканирование
 Сканирование после каждого деплоя! Не зависимо тест или прод
 В идеале оно должно быть частью CI (Continuous Integration)
 Последовательное сканирование разными сканерами, опенсорсными и платными
 Авторизированное сканирование по всей системе
 Сканирование под несколькими учетками с разными правами (admin и пользователь с ограниченными правами)
 Не доверяйте полностью сканерам – проверяйте вручную
Перечень сканеров

62. Анализ безопасности кода
Статический Динамический
 Ревю кода должно осуществляться постоянно
 Ревю кода НЕ должен проводить тот кто его писал
 Тщательно анализировать, отсеивать фолспозитивы
 Комбинировать разные автоматические анализаторы

63. Bug Bounty
Если у Вас достаточно средств можно задействовать
неограниченное количество внешних этичных хакеров,
используя различные Bug Bounty программы, например
HACKENPROOF. Большое внешнее комьюнити повысит
вероятность нахождения всех уязвимостей. Ознакомиться
с деятельностью этих парней и возможно стать одним
Из них возможно прочитав эту книгу:

64. OWASP РУКОВОДСТВО ПО ЗАЩИТЕ ВЕБ-ПРИЛОЖЕНИЙ
 Следование актуальным требованиям безопасности
 Использование безопасных фреймворков и библиотек
 Обеспечение защищенного доступа к базам данных
 Шифрование и безопасность данных
 Проверка входящих данных
 Защита “цифровой личности”
 Управление доступом
 Повсеместная защита информации
 Мониторинг и ведение журналов безопасности
 Корректная обработка ошибок и исключений

65. Чеклист безопасного программирования
Для более расширенной проверки
своего приложения на безопасность
рекомендуется пройти следующий
быстрый обзор и чеклист
По мотивам презентации Sebastien Deleersnyder