Кибербезопасность с упором на C++20 и современные стандарты!

Введение

Здравствуйте, друзья! В сегодняшней статье мы обсудим безопасность C++ и концепции, которые я часто вижу в реальном мире, которые могут либо создавать нестабильный код, либо даже создавать уязвимости в системе безопасности. Сегодня большая часть мира заполнена копируемым и вставляемым кодом, кодом, который перерабатывается или используется повторно. Что ж, я решил, что если все думают, что это умно, почему бы на самом деле не поднять этот вопрос и не пролить на него свет, сосредоточив внимание на C++. В этой статье также будет затронуто сообщество программистов, а иногда и то токсичное и плохое влияние, которое оно может оказать на будущих разработчиков. Вы увидите фрагменты разных языков, таких как C, C++ и даже PHP.

Влияние сообщества на современных разработчиков

Распространенные ошибки кода, допускаемые в реальном приложении

Вы часто видите, как люди, пишущие статьи, говорят, что определенные способы определения функций или целых чисел неверны, бла-бла-бла. То, что НИКОГДА не будет проблемой в реальной ситуации разработки. Итак, давайте на самом деле поговорим о некоторых реальных ошибках, которые я видел во многих приложениях корпоративного уровня или даже в программах, которые люди используют изо дня в день или которые популярны.

Общие риски безопасности внутри мира разработки

• Постоянный или повторяющийся код. Каждый день я вижу, как кто-то постоянно повторяет фрагменты кода или, например, копирует и вставляет линейные проверки или даже двоичные проверки. Это попадает в тяжелую категорию, которая более или менее говорит о производительности кода и операционной функции. Когда вы пишете код, вы хотите убедиться, что ваш код максимально организован и производительен. Я всегда буду говорить, что приложения должны быть быстрыми, если вы делаете что-то вроде онлайн-игры или даже DNS-провайдера или чего-то сверхсложного, но есть и такая вещь, как слишком быстрая. При разработке таких приложений вы не хотите повторять блоки кода. Следующий пример взят из проекта, который снова и снова проверяет одно и то же значение, используя операторы if. Это был код, который я написал почти полгода назад, пытаясь ускорить частный проект. Причина, по которой я сделал это, заключалась в том, что моя команда и люди, которые работали вместе со мной, просто хотели, чтобы это было сделано, когда на самом деле я усложнял себе задачу. Пример на языке программирования GO.
• Этот код занял около 2000+ строк и навсегда останется на процессоре. Этот пример был из проекта, который будет принимать пользовательский ввод и анализировать его, на самом деле я мог бы создать простую карту, которая сопоставляла бы строку, введенную пользователем, с функцией. Это уменьшит нагрузку на ЦП, особенно при многопоточности. Убедитесь, что ваш код не скопирован, так как вы можете видеть, что я копировал и вставлял проверки флагов, и снова это было сделано более 2000 раз, что привело к тому, что программа даже в двоичной форме работала очень медленно. Это даже может вызвать ошибки сегментации и часто приведет к сбою некоторых других вызываемых потоков, каналов или функций. Конечная мораль: прекратите вставлять свой код, сделайте его более преформным, включив его в функции, используя пространства имен, классы и, если не классы, то отдельные модули для автоматизации такого рода ресурсоемких проверок процессора. Если вы можете, вам даже предлагается держаться подальше от большого количества линейных проверок.

• Чрезмерное использование нескольких языков программирования: это то, что я делал, и почти каждый крупный проект делал достаточно. Иногда при работе с большими проектами вам проще делать определенные вещи на другом языке программирования. Таким образом, вы затем используете другой язык программирования и либо связываете его с помощью специального компоновщика кода и исполнителя, либо просто используете что-то вроде системной команды для запуска двоичного или другого файла кода подъязыка. Это не обязательно плохо, если вы используете 2-3 языка, по большей части это неплохо, особенно если вы используете веб-серверы. В большинстве моих проектов используется только один язык, в более крупных проектах — 2–3, а в совместных проектах, таких как частные команды разработчиков, — 5–7 (включая HTML, CSS, JS и SCSS для веб-серверов или для информации о шаблонах). Если бы вы уберите HTML, CSS, SCSS или JS, и в большинстве случаев вы видите, как люди используют до 4 или даже 5 языков программирования, хотя на самом деле в этом нет необходимости. Если вы тратите свое время на постоянное использование других языков для таких простых вещей, как карты, хеш-карты и т. д., вы просто создадите большую головную боль для себя или своей команды. Я создал один из своих самых больших проектов, в котором вначале использовалось несколько языков программирования: rust, c, c++, ruby, go, perl. Когда вы запускали код в бета-версии, все было в порядке, но после выпуска он вылетал, тормозил или зависал и уничтожал себя или вылетал на вашем ПК. Это просто из-за количества процессов и двоичных файлов, которые вы будете запускать в отдельных потоках или каналах. Если вы создаете свою собственную оболочку для языка, на самом деле смешивать языки не так уж и страшно, но лучше перестать перегружать свои проекты языками программирования. 1–3 достаточно хорошо (учитывая, что это не игровой эксплойт, который внутренне перехватывает код, системный эксплойт, который требует других форм перехватывающих методов, веб-серверы, которым может потребоваться HTML, CSS, JS, TypeScript, Coffescript и т. д. для надежной и безопасной работы или что-то сверхсложное, такое как движок кода или фреймворк).
• Форматирование. Проблема, о которой я говорил до того, как мы переместили разделы, касалась уязвимостей формата. Когда люди форматируют данные, с вероятностью 9 из 10 они знают, как они собираются использовать параметр формата, который может быть чем-то вроде %q, %s, %d, %f, %p, %x, %z и т. д. Давайте посмотрим на следующий код C++.

Большинство угроз безопасности, с которыми вы можете столкнуться или не столкнуться, связаны с ленью программиста. Например, многие команды разработчиков, в которых я работал, были ленивы и, как сказано выше, хотели ускорить разработку и создавали код, подобный следующему примеру.

Этот пример в реальном смысле приведет к тому, что ваш код сломается и выведет segmentation fault, если поле существует. Причина в том, что вы просто возвращаете пустое значение, несмотря на то, что NIL, NULL, 0x00 или «» пусты, вы все равно можете предотвратить ошибку сегментации в коде, назначив value NULL вместо ничего. NULL по-прежнему ничего не значит, но его можно проверить и легко сказать, хорошо, если значение равно NULL, тогда вы можете продолжить. Лучший пример этого кода был бы таким.

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

«Обнаружение уязвимостей C++ BOF (переполнение буфера) в библиотеках
Если вы хотите изучить C++, возможно, вам следует прочитать эту статью! В этой статье рассказывается об уязвимости кода…medium.com»

Еще одна распространенная ошибка в сообществе программистов — это форматирование операторов перед их отправкой во что-то вроде базы данных. Возьмите следующий код в качестве примера на PHP и Ruby.

Что вы заметили в обоих из них и почему это, возможно, уязвимости? Ну, в более сложном смысле, оба этих раздела кода и фрагменты кода могут быть подвержены SQL-инъекциям, потому что они фактически не подготавливают оператор перед его отправкой на сервер. В настоящее время используемый код в порядке, он ничего не делает прямо сейчас, кроме форматирования запроса, но в качестве примера возьмем приведенный выше PHP-код. Если вы берете значение user из почтового запроса и не очищаете ввод или даже не подготавливаете оператор, это может означать, что пользователь может обойти IDS или даже проверку работоспособности и внедрить свои собственные операторы SQL внутри кода, особенно если они получают держите исходный код. Это может произойти и в примере с ruby, если вы берете значение из чего-то вроде ответа JSON POST или общего параметра HTTP, вы можете фактически внедрить свой собственный оператор и выполнить полезную нагрузку SQL на сервере. В общем, когда вы запускаете этот код, это не будет проблемой прямо сейчас, но в более корпоративных средах, где они берут значения из запроса POST, ответов JSON, ответов веб-сайта или из любого другого анализатора значений и не готовят оператор, который они будут скорее всего, уязвимы для SQLI. Я много раз видел формы этого в приложениях PHP и даже недавно во многих приложениях Python, где люди будут форматировать операторы перед созданием проверок работоспособности или созданием какого-либо оператора подготовки, прежде чем он будет отправлен для выполнения или анализа удаленным или целевым парсером и/или исполнитель. Эта проблема не создает такой же уязвимости, но также может быть серьезной проблемой при запуске бинарных приложений, написанных с использованием C++/C/Rust или любого другого низкоуровневого языка. Что подводит нас к следующему разделу

Наиболее распространенные уязвимости C++

Этот код не использует ни один из следующих идентификаторов формата, что представляет угрозу безопасности, потому что, когда мы компилируем и запускаем нашу функцию, мы можем предварительно отформатировать данные самостоятельно, запустив что-то вроде следующего ниже.

• BOF: BOF или Buffer Overflow — это уязвимость, которая обычно возникает, когда буфер в программе переполняется определенным объемом данных. В примере скажем, у нас есть буфер, который может содержать 15 переменных. если этот буфер переполняется, он теперь становится уязвимостью переполнения буфера. В наше время, особенно в корпоративной среде, BOF не так распространен, как раньше, с новыми и более современными компиляторами, способными уловить простую ошибку. То есть, если это просто, как в примере, показанном ниже (C++11, функция GETS устарела и удалена в C++14)

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

./main "data_example %q"

вместо идентификатора формата.

printf("%s", argv[1]);

Если вы запустите или попытаетесь скомпилировать этот код, он скомпилируется, но вы получите следующую ошибку, указанную выше.

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

Если вы запустите этот код и введете строку, состоящую из БОЛЕЕ 20 символов, вы заставите программу вывести ошибку сегментации, что также означает, что мы переполнили буфер в программе с именем str . Как уже говорилось, этот тип уязвимости почти НИКОГДА не существует в реальном мире, так что насчет более современного примера. Ну, так как это был C, давайте посмотрим на C++, следующий пример, показанный ниже, создает ту же ошибку и уязвимость.

Как видите, эта программа совершенно такая же, она определяет переменную с ограничением по размеру, и, несмотря на то, что она использует безопасную функцию, такую ​​как cin, вы все равно можете переполнить буфер. Если мы запустим этот код и введем AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA выдаст ошибку segmentation fault: core dumped из программы. Это ненамного сложнее, чем пример на C, но это то, что я много раз видел в современных программах на C++, и, поскольку компилятор не улавливает его, большинство людей его игнорируют. Как бы вы это исправили? Ну, есть несколько способов исправить это, но это также зависит от вашего кода и ваших знаний. Хорошей практикой, к которой подведут итоги этого раздела и маркированного списка, является убедиться, что вы не используете уязвимые стандартные функции, такие как gets, get, strcpy ( string copy ), scanf и printf. Большинство современных IDE на самом деле скажут вам использовать более безопасную и часто используемую функцию, чем та, которую вы используете, если она создает уязвимость. Еще одна хорошая вещь, которую нужно сделать, — это прислушаться к своей IDE, например, об уязвимостях, которые большинство современных IDE сообщит вам, когда появится предупреждение, и в 99,9%, если не в 100% случаев, вы должны ВСЕГДА исправлять предупреждения, которые могут быть возможными проблемами в будущем.

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

• Использование команд system() или стандартных вызовов для выполнения команды

Это действительно не требует фрагмента кода, чтобы доказать, что это опасно, но почти на каждом языке, особенно в таких языках, как C++, C, Rust и даже Perl, использование операторов os.system, system, __SYS, SYSC и т. д. сделает ваш код уязвимым. В любом случае это плохая практика, так как большую часть времени при создании кода вам не нужно или не нужно использовать системные команды, и даже когда вы это делаете, это хорошая идея, чтобы вы обязательно написали свой собственный модуль для передачи и пюре вызовов . Если вы просто используете стандартные вызовы system(), ваш код, скорее всего, будет восприимчив к выполнению или внедрению кода. Это в основном зависит от того, как используется системная команда, даже если вы ее используете, есть вероятность, что она не будет работать в других системах без полной проверки ОС, чтобы увидеть, какую системную команду выполнять под каким блоком и когда. Когда вы начинаете писать системные команды, вам также нужно беспокоиться о разрешениях, если кто-то обнаружит, что вы запускаете команду от имени пользователя root на C++, например, он может найти способ «захватить» или, что еще лучше, перепроектировать эту программу и получить контроль над ней. мгновенно, если программа или команды запускаются с правами администратора.

• Использование ключевого слова using namespace

Использование пространств имен в C++ в целом не является плохой идеей и не делает код уязвимым, однако в более крупных случаях, когда вы начинаете работать над более крупными проектами, использующими заголовочные файлы, лучше не использовать ключевое слово using namespace. Основная причина в том, что в более крупных проектах у вас могут быть конфликтующие пространства имен, классы, параметры функций, переменные и другие вещи в будущем, когда эта библиотека обновится. Например, у вас есть функция с именем funcdataexample, а стандартная библиотека обновлена ​​функцией с таким же именем. Это было бы очень трудно уловить, когда вы находитесь на полпути, если не больше, на полпути к разработке. Тем не менее, в больших базах кода всегда рекомендуется избегать использования ключевого слова using namespace. На самом деле это не проблема безопасности, а проблема совместимости кода и обработки.

• Пользовательский ввод

Пользовательский ввод сам по себе никогда не бывает ужасным, но это очень и очень рискованная вещь, если вы точно не знаете, что делаете. всегда полезно проверить и подтвердить размер данных, которые вы хотите, тип данных и кодировку символов данных, вводимых пользователем. Несколько причин, по которым это является проблемой, заключаются в том, что это может привести к переполнению буфера при использовании таких операторов, как memcpy strcpy и других подобных, и даже опустошения буфера, что может быть результатом ложно реализованного стека. Всегда полезно проверить, очистить и даже, возможно, подготовить оператор, в котором используется пользователем. Как сказано в разделе BOF этой статьи, всегда полезно держаться подальше от шаблонов или предварительного форматирования переменных с текстовыми строками, введенными пользователем, которые будут выполняться, например, SQL-запрос. Вторичным примером может быть пользователь, который может вводить файлы и вводить файл, который никогда не проверялся и не очищался, что может привести к созданию файла, предназначенного для сбоя или использования вашей программы. Это на самом деле подводит нас к следующему пункту

• Проверка файлов и работа с файловыми системами

При работе с файлами на C++ или любом другом языке программирования полезно убедиться, что вы используете современные и безопасные стандартные функции для открытия и извлечения данных из файлов или даже для записи в файлы. Большинство людей, как я видел, при написании веб-серверов будут неправильно обрабатывать файлы, что приведет к возможности обхода каталогов, LFI, RFI и других форм эксплойтов, особенно на веб-серверах, где это чаще всего встречается. Хорошо сделать хорошую систему, готовую проверять и проверять подлинность файла, используя такие вещи, как средства проверки подписи для проверки заголовков и даже определенных разделов данных в файлах. При создании приложений, которые относятся к самому последнему разделу этой статьи, следует обратить внимание на создание в коде систем предотвращения и обнаружения вторжений.

• Давайте будем честными в течение быстрой минуты. Вся ИТ-индустрия была основана на сообществе с тех пор, как были созданы компьютеры или даже появилась идея. Все, что происходило в области технологий, никогда не касалось того, какой язык вы выбрали, в какой области хотели работать или кем вы были как личность. Откровенно говоря, кажется, что мир поменялся местами с этим, где это действительно имеет значение. Большинство современных разработчиков имеют широкий выбор языков, из которых более 600+ могут выбирать, использовать или изучать. С этим также приходят свои собственные индивидуальные наборы сообществ, например, у вас есть люди, которые говорят python community или java community и т. д. Поэтому, когда вы выбираете язык программирования, есть 100% шанс, что вы пойдете просить кого-то о помощи тот человек, который делает предложение или помогать вам будет показывать вам разные способы использования этого языка, который находится в том же сообществе. В целом это здорово, но как это может сильно повлиять на то, как кто-то растет? Короче говоря, большинство разработчиков теперь просто будут следовать тому, что выберет каждый, и это происходит не только в разработке, но и везде. Длинный ответ? Давайте на секунду рассмотрим это в аспекте безопасности. Допустим, у вас есть PHP-разработчик, разрабатывающий сервер данных для веб-сайта, и ему нужна помощь в устранении ошибки. Скорее всего, они будут искать в Интернете или задавать вопросы на форумах, таких как переполнение стека, чтобы узнать, может ли кто-нибудь помочь. В 99% случаев вы будете получать очень токсичные или бесполезные ответы, которые могут пойти по двум путям: оттолкнуть этого человека от сообщества или заставить его принять совет, который старше и lazier / easier способ делать что-то. В большинстве случаев используется слоган if it works then it works, но это главная проблема. Когда у вас есть люди, которые плохо знакомы с ИТ-сферой, и вы видите группу людей, говорящих if it works it works, то, очевидно, более чем вероятно, что этот новый человек будет следовать той же идеологии. Но правда в том, чтобы сделать наоборот, если это работает, убедитесь, что это безопасно, а не просто ошибка. Ошибки даже передаются как шутка, и, конечно, можно сказать, что bugs are just features может быть просто шуткой, но многие люди относятся к этому серьезно и оставляют ошибки, которые могут быть лежащими в основе уязвимостями, ожидающими своего обнаружения. В целом то, что люди публикуют, говорят или даже упоминают в сообществе, оказывает ОСНОВНОЕ влияние на людей, которые растут. Я говорю всем из личного опыта, кто новичок в сообществе, не всегда слушайте всех, даже меня, да меня, пишущего эту статью. Это полностью зависит от вас, чтобы решить, что безопасно, и протестировать свой код, чтобы увидеть, работает ли он или безопасны ли предложения других людей.

Использование и разработка систем обнаружения вторжений

IDS или также известные как системы обнаружения вторжений — не всегда самые простые вещи для разработки, однако, если вы склонны продавать свое приложение, это может быть чем-то, о чем следует подумать. Давайте возьмем пример из моей повседневной работы: однажды моя команда разработчиков сказала мне, что я работаю вместе с ними, и мне нужно разработать систему аутентификации, но пока она работает, все в порядке. Обычно при разработке систем или приложений я просто запускаю и разрабатываю их без каких-либо мер безопасности, я ВСЕГДА буду следить за тем, чтобы мой код и приложения были безопасны до предела. Поэтому при создании этой системы входа в систему я бы попросил пользователя ввести файл лицензии или лицензионный ключ. Этот ключ снова сохранялся в файле, который открывался программой, анализировался, проверялся и переходил к разрешению пользователя в приложение, если ключ был проверен. Ну, дело в том, что, как сказано выше, вы не должны просто открывать файлы и оставлять их в таком виде. ВСЕГДА рекомендуется проверять тип файла, имя, размер и т. д. Именно здесь была реализована моя система предотвращения и обнаружения вторжений. Когда система была создана, по-прежнему очень сложно даже подсунуть файл или даже байт вредоносного ПО мимо этой функции. На самом деле не весь код на 100% безопасен, если честно, нет кода, даже моего кода или кода Google, который был бы на 100% безопасным, но всегда есть способы сделать код настолько безопасным, насколько это возможно. Внедрение IDS или IPS (защита/предотвращение) всегда стоит вашего времени, особенно при работе в проектах разработки. Как говорилось в предыдущих статьях, люди часто говорят вам, что дополнительные усилия по внедрению таких систем, как IDS или IPS, являются пустой тратой времени и будут реализованы позже. Но опять же, я могу даже сказать вам из личного опыта, если вы не сделаете все возможное, чтобы защитить свой код, вам придется сделать паузу в середине или даже в начале тестирования, разработки или даже бета-релизов, чтобы убедиться, что уязвимость в коде исправлена. означает, что теперь вся ваша команда должна пройти через весь проект, чтобы найти уязвимость, которая обычно в бета-тестировании беспорядочна и неорганизованна. Внедрение этих систем также является очень хорошей практикой для тех, кто хочет работать экспертом по наградам за обнаружение ошибок, рецензентом кода или чем-то четвертым. Даже если вы не хотите быть кем-либо из перечисленных выше, рекомендуется убедиться, что ваш код в ваших собственных приложениях или, возможно, даже проектах безопасен не только для вас и вашей компании, но и для вашей репутации, но и для людей, которые хорошо.

Краткое содержание

Большинство языков в современном мире будут иметь устаревшие функции, уязвимые фрагменты кода и другие части стандарта языка, которые могут сделать ваше приложение уязвимым. Это зависит от вас и вашей команды разработчиков, если вы один из них, чтобы убедиться, что код безопасен, особенно если вы не хотите испортить репутацию своего бизнеса или команды безопасности. Большая часть кода сегодня также пишется и вставляется из Интернета, от чего следует держаться подальше, в первую очередь вы всегда должны следить за тем, чтобы ваши операции, а также проекты и код всегда оставались безопасными, иначе могут произойти массовые утечки, которые могут покинуть вашу компанию. , организация, команда и приложение подвержены утечке кода, что опять же, если система или приложение являются частными и с закрытым исходным кодом, может нанести серьезный ущерб вашим назначенным группам и цене приложения.

Если вы хотите не отставать от моего контента, не забудьте помочь поддержать меня!

«Scare-Security
Scare security — это постоянно развивающаяся группа разработчиков кибербезопасности и эксплойтов. Наши участники очень разнообразны в…github.com»

Страница разработки

Страница в инстаграме

Наличное приложение

Заплатите мне в приложении Cash
Мгновенно бесплатно обменивайте деньги в приложении Cashcash.app

Венмо

Вставка кода. Копирование и вставка кода — очень распространенная ошибка в мире программирования, даже в профессиональном сообществе. Почему именно это является проблемой при разработке приложений, которые люди собираются использовать? Ну, это не серьезная проблема, как некоторые другие в этом списке, но это все же более серьезная проблема. Когда вы копируете и вставляете код из чего-то, например, из чужого проекта, или даже из-за ошибки переполнения стека, и даже не тестируете его и не смотрите на возраст кода, вы можете столкнуться с уязвимостями или ошибками. Я видел, как во многих приложениях на C++, Go, Rust, R и ОСОБЕННО на Python люди просто вставляют код, не зная, что он на самом деле делает. Обычный способ сказать это - как написан код, когда вы смотрите на чей-то код или код организации, вы обычно видите один стиль программирования, но затем, если его скопировать или вставить, вы увидите совершенно другую структуру или стиль программирования. Когда приложения будут вставлять код, особенно из языков, которые постоянно обновляются, таких как C++, это может представлять серьезную угрозу безопасности. Причина в том, что некоторые языки программирования не просто обновляют стиль, они обновляются из-за угроз безопасности, обнаруженных в функциях, и если вы просто вставляете устаревшие и незащищенные функции, что вам остается? Очень очень небезопасное и уязвимое приложение. Некоторые люди, которые вставят код, скажут, что все в порядке, и отчасти они правы. Причина в том, что когда вы вставляете код, это в основном зависит от того, что вы вставляете, вставляете ли вы гигантское приложение или просто простое исправление или простую функцию, которая, как вы точно знаете, безопасна. В общем, никто не должен копировать и вставлять, даже если я подвергся этому и обнаружил, что делаю это, но со временем я узнал, что это приводит к большему количеству уязвимостей. Как вы знаете, больше уязвимостей означает, что вам и команде (если вы работаете с командой разработчиков) больше работы. Я видел это несколько раз в нескольких командах разработчиков, которые торопят проекты, они делают это, потому что хотят сэкономить время, но в конечном итоге возвращаются позже, приостанавливая всю разработку только для того, чтобы исправить эту ошибку. Суть в том, что когда один человек совершает ошибку, наказываются все.