дыры в безопасности что это
Найти и устранить: кто ищет «дыры» в безопасности ПО
За 3 года «белые хакеры» нашли 250 уязвимостей в программном обеспечении ведущих разработчиков мира
Киберугрозы в наше время — такая же обыденная реальность, как и сама возможность жить в цифровом мире. Уязвимости того или иного характера можно найти в любом программном обеспечении. Вопрос — в том, насколько они критичны, к чему могут привести и кто находит их раньше — «белые» хакеры или «черные». Вопросы защиты от киберугроз обсудили на минувшей неделе в Москве на международном форуме по практической безопасности Positive Hack Days, организованном компанией Positive Technologies. Соорганизатором форума выступили казанские разработчики — ГК Innostage. Дмитрий Серебрянников, директор по анализу защищенности компании Positive Technologies, раскрыл любопытную информацию. Какие уязвимости находятся в ПО ведущих мировых вендоров, как быстро удается их закрыть, что мешает делать это вовремя и чем они могут быть опасны — в репортаже «Реального времени» с полей форума.
250 уязвимостей за 3 года
Специалисты компании Positive Technologies с 2018 по 2020 годы проанализировали ряд программных продуктов российских и зарубежных вендоров. Когда поступает заказ на оценку системы безопасности от какой бы то ни было компании, специалисты начинают оценивать, откуда исходят те или иные угрозы. В рамках этой работы, конечно же, оценивается и защищенность программного обеспечения, которое используется у заказчика. Таким образом, получается, что собранная статистика представляет собой срез ПО, использующегося в крупнейших компаниях страны, продуктов, которые используются повсеместно. И когда обнаруживается та или иная уязвимость, то эксперты Positive Technologies направляют вендорам подробное описание найденных «дырок» в безопасности, те проверяют и уточняют информацию — и начинают работать над закрытием проблемы.
За 3 года специалисты Positive Technologies обнаружили более 250 уязвимостей в ПО, разрабатываемом 60 вендорами. Из них 35% относятся к критическим, еще 35% — имеют высокую степень опасности. Это очень и очень много.
В информационной безопасности есть своеобразное джентльменское соглашение: на то, чтобы закрыть уязвимость, компания должна потратить не больше 90 дней. Но это — сферический случай в вакууме, который встречается не так часто, как хотелось бы. По факту, на снятие проблем порой уходит больше года. И связано это может быть с разными причинами — вплоть до того, что у самих вендоров не хватает компетенций на то, чтобы понять, в чем кроется уязвимость и что с ней можно сделать. Так что «отлов» и уничтожение уязвимостей в программном обеспечении в современном мире — задача не самая банальная и не самая простая.
Промышленность — самая уязвимая сфера
Топ-10 вендоров по количеству уязвимостей, согласно представленной статистике по большей части разрабатывают ПО в сфере промышленности. В грустном топе лидеров — Siemens, Schneider Electric и Cisco. По статистике, промышленные компании дольше всех закрывают уязвимости в своем ПО.
При этом тот же Siemens — один из мировых лидеров в разработке промышленного ПО. Уязвимость, найденная специалистами Positive Technologies в Siemens Simatic S7-1500, позволил бы злоумышленнику полностью заблокировать работу ПЛК, останавливать технологический процесс, портить оборудование или вызывать аварии. Например, одним из кейсов, который легко реализовывался при этой уязвимости, мог стать массивный разлив топлива.
За последние годы количество кибератак на промышленные компании выросло на 90%. Так что можно констатировать: этот сегмент с точки зрения кибербезопасности — самый незащищенный.
От Cisco до Verifone
Примеры найденных уязвимостей достаточно стандартные, но грозные. И под угрозой оказываются миллионы бизнесов. Например, в разгар пандемии была найдена проблема в безопасности в серии аппаратных межсетевых экранов Cisco ASA — для хакеров становился доступен VPN. А учитывая, сколько компаний по всему миру пользуется этим техническим решением, под ударом оказалось множество бизнесов — к концу пандемии под ударом оказались более 220 тысяч подключенных устройств по всему миру. Уязвимости позволяли злоумышленникам проводить атаки на устройства, отключать VPN (а значит, и блокировать работу удаленных сотрудников в компании), нарушать работоспособность ключевых систем — например, электронной почты или EPR), прочитать Cookies пользователя, подключенного по VPN, из памяти устройства или проникать во внутреннюю сеть компании с украденным идентификатором.
Множество уязвимостей разной степени критичности было найдено в ПО производства VMware — например, в vCenter Server. Продуктом пользуются по всему миру примерно 20 000 компаний. Это позволяло неавторизованному пользователю выполнять произвольные команды на сервере, продвинуться по корпоративной сети, получить доступ к данным. Достаточно квалифицированный хакер мог получить доступ к огромному количеству серверов в два клика. А на закрытие этой уязвимости потребовалось 144 дня — и это вполне типичная ситуация.
Но не всегда получается снять проблему, «накатив» обновление программного обеспечения. Иногда приходится физически менять компоненты системы. Один из таких примеров — найденная уязвимость в одном из чипсетов Intel. Процессоры Intel могут помочь в шифровании данных, но их можно расшифровать, украв ключи. И это позволяет обойти системы защиты от копирования, выдать свой компьютер за ПК жертвы, обманув систему проверки подлинности. Найденная уязвимость позволяла вытащить ключи шифрования, причем сделать это совершенно незаметно. Новое программное обеспечение не могло спасти систему от опасности, так что под угрозой оказались все процессоры, выпущенные за последние 5 лет. В таком случае специалисты рекомендовали или устанавливать новые процессоры, или не пользоваться встроенной системой шифрования.
Фото: vk.com/phdays
Все плохо?
Но, как неоднократно повторил Дмитрий Серебрянников, в вышеприведенных примерах ничего страшного нет. Более того, если об уязвимости программного обеспечения до сих пор ничего не известно — это означает только, что его недостаточно глубоко исследовали. Нет полностью защищенных систем, есть недообследованные (точно так же, как и со здоровьем людей). Кстати, бывает и так, что вендор выпускает обновление продукта — и не говорит, что в предыдущей версии были критические уязвимости. И это тоже огромная ошибка — ведь, не зная об опасности, клиент может и не спешить поставить обновленную версию.
Приведенные данные демонстрируют, как ситуация развивалась с 2018 по 2020 годы. Статистика, накопленная за первые месяцы 2021, свидетельствует: тренд нарастает. Количество найденных лазеек для хакеров растет с каждым днем — и это объясняется чисто статистически. Растет рынок ПО, постоянно появляются новые продукты, программисты по всему миру ожесточенно пишут код, и все больше секторов жизни переходит в Сеть. А значит, тем больше в Сети становится и мошенников, и это нормально.
Борьба с уязвимостями становится обычным будничным процессом, ведь они находятся в любых продуктах. Поэтому, чтобы защитить свой бизнес от утечки данных или денег, техногенных аварий и прочих происшествий, нужно, во-первых, внимательно относиться к инфобезопасности в компании, а во-вторых, своевременно устанавливать обновления, предлагаемые вендором. Во многих случаях это делается именно с целью повышения безопасности.
Из курилки программиста — в ООН
Проблема становится глобальной, она уже давно вышла за рамки отдельных компаний. Страны на уровне правительств по-разному справляются с уязвимостями. Например, в Нидерландах, когда была найдена очередная уязвимость в Citrix, вопрос решали на уровне государства (дело в том, что это ПО стояло в разных официальных ведомствах). Министерство юстиции моментально объявило, что нужно отключить это программное обеспечение в госучреждениях — до того, пока вендор его не обновит. И это — очень правильный кейс с точки зрения безопасности государства.
Мир кибербезопасности не так велик, как кажется. Большинство крупных игроков на нем так или иначе знакомы друг с другом и стараются работать в едином векторе. И они уже давно предлагают взаимодействовать в сфере информационной безопасности на надгосударственном уровне. Ведь по сей день еще не создано единого межстранового органа, который занимался бы этой проблемой на мировом уровне. Возможно, поэтапная программа «по связыванию всех со всеми» должна быть взята на контроль в ООН. Но ясно одно: один хакер способен вызвать глобальную катастрофу. А значит, всем вместе надо сесть и задуматься над тем, как не дать ему это сделать.
11 ошибок новичка, которые могут привести к дырам в кибербезопасности
Авторизуйтесь
11 ошибок новичка, которые могут привести к дырам в кибербезопасности
Разработчики стоят у основания любого ПО, и уже на самых ранних этапах им приходится думать не только о производительности и эффективности продукта, но и о его безопасности.
Однако мало кто из программистов в рамках своей специальности изучает методы написания безопасного кода или аспекты криптографии. Постоянно держать в голове техники кибербезопасности и возможные уязвимости — сложная задача, особенно для начинающего специалиста.
Ведущий специалист по тестированию компании BI.ZONE Андрей Колесников разобрал 11 распространенных ошибок, которые могут сделать ваше приложение уязвимым. По большей части эти ошибки влекут за собой кражу денег или данных, удаленное выполнение кода, отказ в обслуживании или повышение привилегий.
В статье рассмотрено, как тот или иной недочет приводит к дырам в безопасности, а также предложены варианты решения.
ведущий специалист по тестированию компании BI.ZONE
1. Отсутствие экранирования, неправильное форматирование, а также некорректное использование форматной строки и параметров у printf-функции
Проблема. Данные, попадающие в приложение из внешнего источника, недостаточно валидируются и фильтруются, в результате чего нарушается логика работы приложения.
Угроза. Такие ошибки связаны с целым рядом уязвимостей и атак: SQL Injection, NoSQL Injection, XXE, XSS, уязвимость форматной строки и прочими. Последствием наличия таких недостатков может стать возможность компрометации системы организации.
Решение. Фильтруйте и валидируйте все данные, поступающие из внешних недоверенных источников, а также используйте встроенные средства языков программирования, спроектированные специально для устранения таких проблем (например, Prepared Statements в случае с SQL).
2. Некорректная работа с конфиденциальными данными
Проблема. Чувствительные данные, например, номера банковских карт, пароли или персональная информация, выводятся в журналы или передаются третьей стороне в открытом виде.
Угроза. Из-за недостаточно бережного отношения к конфиденциальным данным они могут стать доступны третьей стороне.
3. Десериализация ненадежных данных
Проблема. Приложение десериализует данные из недоверенного источника без достаточной их валидации. Такая уязвимость имеет идентификатор CWE-502 и находится на восьмом месте в рейтинге критических рисков веб-приложений OWASP Top Ten.
Угроза. В результате атаки на механизмы десериализации злоумышленник нередко получает возможность удаленно исполнять команды в скомпрометированной системе.
Решение. По возможности используйте простые форматы (например, JSON) для передачи данных и для их сохранения на диск или в базу данных. Кроме того, ведите белый список допустимых классов и подписывайте передаваемые сериализованные данные.
4. Хранение аутентификационных данных в исходном коде
Проблема. Пароли, ключи, токены хранятся в исходном коде или репозитории исходного кода.
Угроза. Информация из кода может попасть к третьим лицам. Если там хранятся аутентификационные данные, злоумышленник легко получит доступ к системе или ее компонентам.
Решение. Храните ключи, пароли и токены отдельно от основного кода проекта. Когда потребуется передать их в приложение, делайте это, например, через переменные среды или отдельные конфигурационные файлы.
5. Использование непроверенного чужого кода
Проблема. Использовать чужой код всегда проще, но если вы его не проверили — это большой риск. Такой код может содержать уязвимости или намеренно оставленные бэкдоры.
Угроза. Злоумышленник, знающий о существовании уязвимости или бэкдора, может скомпрометировать систему.
Решение. Не рискуйте без необходимости: обязательно проверяйте чужой код, а лучше всегда обращайтесь к уже зарекомендовавшим себя библиотекам, например GSON, Apache Commons, Bouncy Castle и так далее.
6. Использование устаревших версий библиотек и софта
Проблема. Устаревшие версии библиотек и ПО содержат уязвимости, информация о которых есть в открытом доступе.
Угроза. Злоумышленники хорошо осведомлены о таких уязвимостях. Поэтому устаревшие библиотеки, плагины и ПО могут стать входной точкой при компрометации системы. Проэксплуатировать уязвимость может даже неопытный пользователь: в этом помогают общедоступные эксплоиты.
Решение. Регулярно обновляйте версии библиотек и ПО, которые используете. Также указывайте в конфигурационных файлах конкретные версии библиотек: в будущем это поможет избежать проблем с совместимостью.
7. Неграмотное использование криптографии
Проблема. Принципы криптографии весьма неочевидны и в попытке изобрести лучшее решение неопытные разработчики используют свои «костыли» вместо проверенных средств.
Угроза. С непроверенными алгоритмами криптографическая стойкость снижается: уязвимости могут появиться где угодно. Выстроенная защита не работает и злоумышленникам легко ее обойти.
Решение. Глубоко погружаться в криптографию не обязательно. Но будет полезно узнать общие принципы этой науки, чтобы понимать, когда нужно использовать тот или иной алгоритм, в каких ситуациях необходимо применять шифрование, в каких — цифровую подпись, а в каких и вовсе будет достаточно кодирования.
8. Использование паролей по умолчанию или полное отсутствие аутентификации
Проблема. В конфигурациях различных сервисов и программных продуктов (базы данных, CMS и т. д.) остаются настройки, заданные по умолчанию.
Угроза. Слабые пароли или отсутствие аутентификации — прямой путь для доступа злоумышленника к системе и ее компонентам.
Решение. Не забывайте везде включать аутентификацию и меняйте дефолтные конфигурации на более защищенные. Согласно лучшим практикам кибербезопасности, в первую очередь нужно позаботиться о двух аспектах: сложных паролях и ограничении сетевого доступа к компонентам.
9. Игнорирование официальной документации
Проблема. В процессе разработки продукта не учтены рекомендации и практики из официальной документации.
Угроза. Если не задать объектам определенные свойства, качество кода в целом снизится и могут возникнуть уязвимости.
Решение. Все объекты, с которыми вы работаете, требуют бережного отношения и скрупулезно заданных свойств. Официальная документация — отличный помощник в этом: в ней содержится огромное количество практических советов. Мы регулярно сталкиваемся с ситуациями, когда подход Secure by default совершенно не работает даже в очень популярных open-source-решениях. В таких случаях единственный способ безопасно использовать компонент — внимательно изучать документацию и возможные настройки.
10. Проверки на стороне клиента
Проблема. Проверки корректности входных данных выполняются исключительно на клиентской стороне.
Угроза. В серверную часть приложения могут попасть непровалидированные данные, что нередко приводит к уязвимостям (см. п. 1) или нарушениям бизнес-логики.
Решение. Выполняйте все проверки на стороне сервера приложения. Проверки на стороне клиента — это не мера безопасности, а улучшение пользовательского опыта.
11. Недостаточные журналирование и мониторинг
Проблема. В системе реализовано недостаточное количество методов журналирования и мониторинга происходящих событий и параметров.
Угроза. Когда в системе остаются слепые пятна, есть опасность пропустить происходящие в ней аномалии и не заметить атаку злоумышленника.
Решение. Необходимый объем журналирования и мониторинга — это когда вы можете в любой момент получить представление о том, как функционирует тот или иной компонент системы и какие проблемы в нем возникают. Чтобы не допустить появления слепых пятен в ваших механизмах сбора данных, единые механизмы логирования лучше планировать на этапе проектирования архитектуры системы.
Ошибки совершают все. Но опытных разработчиков от начинающих отличает умение предвидеть хотя бы некоторые из них. Думать о безопасности, а значит, думать стратегически — это признак профессионала. К такому подходу и стоит стремиться в разработке.
Смертные грехи безопасности сайта: что мы узнали из статистики сканера уязвимостей за год
Примерно год назад мы в DataLine запустили сервис для поиска и анализа уязвимостей в ИТ-приложениях. В основе сервиса – облачное решение Qualys, про работу которого мы уже рассказывали. За год работы с решением мы провели 291 сканирование для разных сайтов и накопили статистику по распространенным уязвимостям в веб-приложениях.
В статье ниже я покажу, какие именно дыры в безопасности сайтов скрываются за разными уровнями критичности. Посмотрим, какие уязвимости сканер находил особенно часто, почему они могут возникать и как защититься.
Все уязвимости веб-приложений Qualys делит на три уровня критичности: низкий, средний и высокий. Если смотреть на распределение по «тяжести», кажется, что все не так плохо. Уязвимостей с высоким уровнем критичности мало, в основном все некритичные:
Но некритичные – не значит безобидные. Они тоже могут нанести серьезный ущерб.
Топ «некритичных» уязвимостей
Стандартом безопасности сайтов считается передача данных между клиентом и сервером по протоколу HTTPS, который поддерживает шифрование и защищает информацию от перехвата.
Некоторые сайты используют смешанное содержимое: передают часть данных через незащищенный протокол HTTP. Чаще так передают пассивное содержимое – информацию, которая влияет только на отображение сайта: картинки, css-стили. Но иногда так передается и активное содержимое: скрипты, которые управляют поведением сайта. В этом случае при помощи специального ПО можно анализировать приходящую от сервера информацию с активным содержимым, модифицировать на лету свои ответы и заставлять машину работать так, как не было задумано ее создателями.
Браузеры новых версий предупреждают пользователей, что сайты со смешанным содержимым небезопасны, и блокируют контент. Разработчики сайтов также получают предупреждения от браузера в консоли. Например, так это выглядит в Firefox:
Чем опасно: Злоумышленники используют незащищенный протокол для перехвата информации о пользователе, подмены скриптов и отправки запросов на сайт от его имени. Даже если посетитель сайта не вводил данных, это не защищает его от фишинга – выуживания конфиденциальной информации мошенническими методами. Например, с помощью скрипта можно перенаправить пользователя на небезопасный сайт, который маскируется под знакомый пользователю. В отдельных случаях злонамеренный сайт выглядит даже лучше оригинала, и пользователь может сам заполнить форму и передать конфиденциальные данные.
Что стоит помнить веб-разработчику: Даже если администратор сайта установил и настроил SSL/TLS-сертификат, уязвимость может возникнуть из-за человеческого фактора. Например, если на какой-то из страниц поставили не относительную ссылку, а абсолютную с http, и вдобавок не настроили редиректы с http на https.
Обнаружить смешанный контент на сайте можно с помощью браузера: поискать по исходному коду страницы, почитать уведомления в консоли разработчика. Однако разработчику предстоит долго и нудно ковыряться в коде. Ускорить процесс можно с автоматизированными средствами анализа, например: SSL Check, свободное ПО Lighthouse или платный софт Screaming Frog SEO Spider.
Атрибут «HTTPOnly» защищает файлы куки от обработки скриптами, которые злоумышленники используют для кражи пользовательских данных. Флаг «secure» не разрешает передачу куки в открытом виде. Обмен данными будет разрешен, только если для отправки куки используется защищенный протокол HTTPS.
Оба атрибута прописываются в свойствах куки:
Чем опасно: Если разработчик сайта не указал эти атрибуты, злоумышленник может перехватить информацию пользователя из куки и воспользоваться ей. Если куки используются для аутентификации и авторизации, он сможет угнать сессию пользователя и совершить действия на сайте от его имени.
Что стоит помнить веб-разработчику: Как правило, в популярных фреймворках эти атрибуты задаются автоматически. Но все равно проверьте конфигурацию веб-сервера и поставьте флаг: Set-Cookie HttpOnly; Secure.
Сканер сообщает о такой уязвимости, если находит публично доступный файл или директорию сайта с потенциально конфиденциальной информацией. Например, обнаруживает отдельные файлы с конфигурацией системы или доступ к файловой системе целиком. Такая ситуация возможна, если на сайте неправильно заданы права доступа.
Чем опасно: Если файловая система «торчит наружу», злоумышленник может провалиться в интерфейс операционной системы и попробовать найти папки с паролями, если они хранятся в открытом виде (не надо так!). Или можно украсть хэши паролей и перебором подобрать пароль, а также попытаться поднять привилегии в системе и продвигаться вглубь инфраструктуры.
Если пользователь часто заполняет формы на сайтах, его браузер сохраняет эту информацию с помощью функции автозаполнения.
Формы на сайтах могут включать поля с конфиденциальной информацией, например, пароли или номера кредитных карт. Для таких полей стоит на самом сайте отключить функцию автозаполнения форм.
Чем опасно: Если браузер пользователя сохранит конфиденциальную информацию, злоумышленник может перехватить ее позже, например, с помощью фишинга. По сути, веб-разработчик, забывший об этом нюансе, подставляет своих пользователей.
Что стоит помнить веб-разработчику: В этом случае у нас классический конфликт: удобство vs безопасность. Если веб-разработчик думает о комфорте пользователя, он может сознательно выбрать автозаполнение. Например, если важно следовать Web Content Accessibility Guidelines – рекомендациям по доступности контента для пользователей с ограниченными возможностями.
Для большинства браузеров отключить автозаполнение можно атрибутом autocompete=«off», например:
Этот заголовок влияет на теги frame, iframe, embed или object. С его помощью можно полностью запретить встраивать свой сайт внутрь фрейма. Для этого нужно указать значение X-Frame-Options: deny. Или можно указать X-Frame-Options: sameorigin, тогда встраивание в iframe будет доступно только на вашем домене.
Чем опасно: Отсутствие такого заголовка можно использовать на вредоносных сайтах для кликджекинга. Для такой атаки злоумышленник создает прозрачный фрейм поверх кнопок и обманывает пользователя. Например: мошенники ставят во фрейм на сайте страницы социальных сетей. Пользователь думает, что кликает на кнопку на этом сайте. Вместо этого клик перехватывается и отправляет запрос пользователя в социальную сеть, где есть активная сессия. Так злоумышленники рассылают спам от имени пользователя или накручивают подписчиков и лайки.
Если не запретить такую возможность, злоумышленник может поставить кнопку вашего приложения на вредоносный сайт. Он может быть заинтересован в вашей реферальной программе или в ваших пользователях.
Что стоит помнить веб-разработчику: Уязвимость может появиться, если X-Frame-Options с конфликтующим значением задан на веб-сервере или балансировщике нагрузки. В этом случае сервер и балансировщик просто перезапишут заголовок, так как имеют более высокий приоритет по сравнению с кодом бэкенд-части.
Значения deny и sameorigin заголовка X-Frame-Options будут мешать работе вебвизора Яндекса. Чтобы позволить использовать iframe для вебвизора, нужно написать в настройках отдельное правило. Например, для nginx можно настроить вот так:
Это уязвимость в стилях сайта. Она возникает, если для обращения к файлам стилей используются относительные ссылки вида href=»/somefolder/styles.css/». Злоумышленник воспользуется этим, если найдет способ перевести пользователя на вредоносную страницу. Страница подставит относительную ссылку в свой url и имитирует обращение к стилям. Получится запрос наподобие badsite.ru/. /somefolder/styles.css/, который под видом стиля может совершать вредоносные действия.
Чем опасно: Мошенник сможет воспользоваться этой уязвимостью, если найдет еще одну дыру в безопасности. В результате так можно украсть пользовательские данные из куки или токены.
Что стоит помнить веб-разработчику: Задайте заголовок X-Content-Type-Options: nosniff. В этом случае браузер проверит тип контента для стилей. Если тип отличается от text/css, браузер заблокирует запрос.
Критичные уязвимости
Ответ от сервера по нешифрованному каналу уязвим для атак типа «Man in the middle». Злоумышленник может перехватить трафик и вклиниться между клиентом и сервером, когда страница идет от сервера к клиенту.
Чем опасно: Мошенник сможет подменить страницу и прислать пользователю форму для конфиденциальных данных, которые уйдут на сервер злоумышленника.
В этом случае от пользователя на сервер по нешифрованному каналу отправляется форма с логином и паролем.
За время сканирования самой используемой библиотекой стал jQuery с обширным скопом версий. В каждой из версий есть хотя бы одна, а то и больше известных уязвимостей. Влияние может быть самым разным – зависит от природы уязвимости.
Чем опасно: Для известных уязвимостей есть эксплойты, например такие:
Хранимые XSS (Stored XSS) более опасны, так как скрипт внедряется на сервере и выполняется каждый раз при открытии в браузере атакованной страницы.
Отраженные XSS (Reflected XSS) проще проводить, так как злонамеренный скрипт можно внедрить в HTTP-запрос. Приложение получит HTTP-запрос, не проверит данные, упакует их и немедленно отправит. Если атакующий перехватит трафик и вставит скрипт вида
то от имени клиента уйдет вредоносный запрос.
Яркий пример XSS: js-снифферы, которые имитируют страницы для ввода CVC, срока действия карты и так далее.
Что стоит помнить веб-разработчику: В заголовке Content-Security-Policy используйте атрибут script-src, чтобы браузер клиента загружал и исполнял только код с доверенного источника. Например, script-src ‘self’ вносит в белый список все скрипты только с нашего сайта.
Наилучшей практикой считается Inline code: разрешите только inline javascript с помощью значения unsafe-inline. Такое значение разрешает использовать inline js/css, но не запрещает подключать js-файлы. В комбинации со script-src ‘self’ мы запрещаем выполнять внешние сценарии.
Чем опасно: Если злоумышленник введет в такую форму SQL-запрос, то может уронить базу данных или выдать конфиденциальную информацию.
Что стоит помнить веб-разработчику: Не доверяйте тому, что приходит от браузера. Защищаться нужно и на стороне клиента, и на стороне сервера.
На стороне клиента напишите проверку полей с помощью JavaScript.
Встроенные функции в популярных фреймворках также помогают экранировать подозрительные символы на сервере. На сервере также рекомендуется использовать параметризованные запросы к базам данных.
Определите, где именно идет взаимодействие с базой данных на веб-приложении.
Взаимодействие возникает, когда мы получаем какую-либо информацию: запрос с id (смена id), создание нового пользователя, новый комментарий, – новые записи в базе. Здесь могут возникать sql-инъекции. Даже если удаляем запись из базы, возможна sql-инъекция.
Общие рекомендации
Следите за обновлениями вендора и обновляйте регулярно. Уязвимость найдут, затем напишут эксплойт, выложат в публичный доступ, и все повторится по-новой. Подпишитесь на обновления до стабильных версий от вендора ПО.
Проверяйте права доступа. Со стороны сервера всегда относитесь к вашему коду так, как будто он весь, от первой до последней буквы, написан вашим самым ненавистным врагом, желающим сломать ваш сайт, нарушить целостность ваших данных. Тем более, что иногда это действительно так.
Используйте клоны, тестовые площадки, а потом уже лейте на прод. Это поможет, во-первых, избежать ляпов и косяков на продуктивной среде: продуктивная среда приносит деньги, простой продуктивной среды критичен. При добавлении, исправлении или закрытии какой-либо проблемы стоит проводить работы в тестовом окружении, потом проверять функциональность и найденные уязвимости, а затем уже планировать работы с продуктивной средой.
Защищайте веб-приложение при помощи Web Application Firewall и интегрируйте с ним отчеты от сканера уязвимостей. Например, в DataLine в качестве связки сервисов используются Qualys и FortiWeb.