Comments 11
А сколько специалистов по безопасности нужно на одного программиста? И как же так получается, что контроллеры знают больше, чем разработчики? Как поможет знание С отлавливать проблемы в коде на JAVA или python'е?
И это при том, что С меня кормит уже много лет, и, надеюсь, еще долго будет кормить. Как по мне, язык С стоит учить в том случае, если есть желание очень глубоко вникнуть в тему "как именно оно работает". Но если реально глубоко, то С дело не ограничится - дальше схемотехника во всех ее проявлениях.
В остальных случаях эти знания факультативны, и без них вполне можно жить.
Количество безопасников на одного разработчика зависит от того, сколько уязвимостей останется в его коде 🙂 Контролёры не «знают больше» — они просто смотрят на софт под другим углом: не как его использовать, а как сломать. Cи здесь важен не потому, что «поможет ловить баги в Java/Python», а потому что даёт понимание, что происходит под капотом. Когда понимаешь, как работает память, стек и сетевые вызовы на уровне C — начинаешь иначе читать любой код, даже на высокоуровневых языках. А дальше — да, путь глубже уводит уже к железу. Но именно C делает этот переход возможным.
Количество безопасников на одного разработчика зависит от того, сколько уязвимостей останется в его коде 🙂
Мы же помним главный принцип - код без уязвимостей это код который никогда не исполняется. А значит он мертв, и потому никому не нужен. И следствие - в любом коде всегда остаются те или иные уязвимости. Значит ли это, что контролёров должно быть как минимум столько же, сколько разработчиков? Впрочем, по сути это риторический вопрос. Граничащий со словоблудием. Потому отвечать на него не надо.
...не как его использовать, а как сломать...
Вот и плохо, на самом деле. Важнее не "как сломать", а "как сделать так, чтоб не ломалось". Человек с отладчиком сломает все. А вот сделать так, чтоб любой мусор (даже специально сгенерированный) на входе не приводил к проблемам - это важно.
Когда понимаешь ... на уровне C — начинаешь иначе читать ... код ... на высокоуровневых языках
А когда начинаешь на нем серьезно писать, то или оказывается что ты в принципе не можешь писать на высокоуровневых языках, или сводишь их к тому же простому, понятному и логичному С. Правда, очень часто лучше оперировать объектами и методами, чем указателями и регистрами. Каждому свое. И главное понимать границы возможностей. Своих и своего инструмента.
Соглашусь частично ) После плотного погружения в C действительно меняется «карта местности» в голове: начинаешь мысленно держать стек, границы буферов и инварианты — и на высокоуровневых языках порой сам себе усложняешь жизнь, пытаясь всё «приземлить» до байтов и указателей. Но это не повод фетишизировать C и не повод отвергать ОО-подход: у каждого инструмента своя зона эффективности
у каждого инструмента своя зона эффективности
А вот это абсолютно верно. Но это главное, что стоит понимать прежде чем изучать язык С в 2025. Да и позже тоже. Беда лишь в том, что границы эффективного применения языка С - это вообще тема совершенно отдельного обсуждения. Но в любом случае они окажутся вдали от того, что считается денежным или интересным. Это скорее прочный фундамент под архитектурным шедевром. Его не видно. Но некачественный фундамент похоронит любую конструкцию, над ним возведенную. А качественный позволит надстроить впоследствии ещё несколько этажей, когда в этом возникает необходимость.
Так и ломаться может по разному) Одно дело, если тот же out of range просто побьет нечувствительные данные, и совсем другое, когда даст контроль над критическими узлами системы. Его стоит учить хотя бы для нормального понимания определения "не детерминированного" поведения, работы стека, аллокаций. С тут как неподкупный учитель, что бросает тебя в середине озера, чтобы ты научился плавать. Не вызвал free, не проверил указатель - не С тебя по рукам ударит, а заказчик (или как в данном случае безопасник). Очень дисциплинирует)
ну в яве проще с процессами, но их надо завершать (почти похоже на работу форк+exec ) тоесть если ошибка надо очистить память, наверно это первое что можно заметить(например в ходе выполнения процесса произошел сбой, всю цепочку processBuilder надо завершить )
strcpy пример я считаю баян, потомучто ввод может быть буферизован и там не будет выхода за границы просто проверить количество селектор с буфером и скинуть буфер
просто на этом этапе нужна сущность строка и там будет управление количеством, можно предположить что копируем в селектор 8 символьный
Упд: 2 сущности строка на стеке регулируемая отбойником и на куче
Пример со strcpy действительно баян, но он не про то, как приходят данные, а про то, что сама функция не знает границ приёмника. Хоть буферизуй ввод, хоть подавай по байту — если на стеке 8 байт, а пишешь 9, будет выход. Решается только явным контролем длины или нормальной сущностью “строка” с len/cap.
а там еще memcpy/memmove/read/write вызываем без контекста получается просто до ошибки чтоли? с ними такие же примеры получается?
просто строки должны контролироваться \0 концом, и язык организован таким образом чтобы сущности делали сами разработчики тоесть, строки/вектора(группировки)/менеджмент памяти(управление может быть в сущности), тут пример нету конца строки, а мы его должны гарантировать, и у строки должна быть явная длина - это контекст уже
тогда помню самый ходовой пример
sprintf() тоже просто вызов
но можно перед ним посчитать выделить вызвать изменить память и удалить строку полученную из sprintf или тоже самое с snprintf
Испортили статью названием.
Почему C стоит учить в 2025 году, особенно если вы изучаете пентест