Что такое безопасное программирование ?

это несколько лукавое предложение strcat в данном случае является неотъемлемой частью join, тч обрушить его эксплойтиком не получится.

это с аких пор переполнение буфера стало "фантомными страхами" 777 либо оно в коде есть, либо его в коде нет -- 3го нет к тому же, твоё утв (мол-де допущение таких ансейф фунок в коде) способствует ускорению кода весьма сомнительно..

1. защита стека осью есь ТОРМОЗА.
2. добавление канарок компилем есь опять ТОРМОЗА.
3. аверки == ещё одни ТОРМОЗА.
***
Итого-сь получаем == overflow-free buffer даёт реальный буст кодам + увеличивает их устойчивость и безопасность.

 

UbIvItS, либо оно в коде есть, либо его нет, если ты его не сможешь спровоцировать входными данными, то его нет верно?

 

простой пример: твою либу аки-она-есть взяли для интерпретатора скриптов и благодаря ей (твоей либе) в интерпретаторе появляется buffer overrun чрез скриптики.

 

Ну, то есть, вы согласны с тем, что я безопасно использую strcat, соблюдая контракт, который был описан в комментарии к функции?

Не весьма и не сомнительно. Лишний бранч - минус 10 тактов процессора. Если бранчей будет много, то сами посмотрите, сколько тактов вы проиграете. При этом, в большинств случаев бранч можно реализовать в вызывающем коде один раз, что значительно увеличит производительность.

Вы не путайте внутренний API и внешний API. Если API внешний, то там надо применять весь спектр защит. А если API внутренний - то смысла защищаться нет, достаточно досконально описать его поведение.

Чего-чего добавление???

Аверки не нужны. Это костыль, призванный защитить от дырявого API.

Правильный дизайн приложения даёт реальный буст кодам и увеличивает их устойчивость и безопасность. А что внутри будет использоваться - всё равно.

 

небезопасная функа можь быть определена чрез #define и в бинарных кодах её не будет от слова СОВСЕМ + Ты в общем и целом привёл частный случай. а в большинстве вариаций небезопасная функа остаётся небезопасной. Опять же простой пример: твоя прога должна поддерживать аддоны чрез скриптики.

хмм.. еть чрезвычайно оптимистично при кодах без переполнения буфера можно отключать защиту стека/ASLR/прочую крень. а тамо тиков-таков поболей.. сильно поболей.

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

https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stack_canaries

так о том и речь

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

 

Это не пример, это плод твоего воображения.

Код (C):

1.   /**
2.    * Копирование строки.
3.    *
4.    * @param dst     конечная строка.
5.    * @param src     исходная строка.
6.    * @param maxlen  максимальная длина конечной строки с учетом нулевого символа.
7.    *
8.    * @return  требуемая длина конечной строки без учета нулевого символа,
9.    *          требуемая длина >= maxlen означает недостаточный размер буфера,
10.    *          0 в случае ошибки.
11.   */
12.   size_t strcpy_la(char* dst, const char* src, size_t maxlen);
13.   size_t strcpy_lw(wchar_t* dst, const wchar_t* src, size_t maxlen);
14.  
15.   /**
16.    * Копирование строки.
17.    *
18.    * @param dst     конечная строка.
19.    * @param src     исходная строка.
20.    * @param maxlen  максимальная длина конечной строки с учетом нулевого символа.
21.    * @param maxcnt  максимальное количество копируемых символов исходной строки.
22.    *
23.    * @return  требуемая длина конечной строки без учета нулевого символа,
24.    *          требуемая длина >= maxlen означает недостаточный размер буфера,
25.    *          0 в случае ошибки.
26.   */
27.   size_t strcpy_lna(char* dst, const char* src, size_t maxlen, size_t maxcnt);
28.   size_t strcpy_lnw(wchar_t* dst, const wchar_t* src, size_t maxlen, size_t maxcnt);

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

Меня удивляют столь абсурдные примеры и нелепые утверждения от человека, который знаком с WASM более 5 лет. Неужели ты всего этого не знаешь на полном серьезе? Уже порядка двух страниц ты пытаешься убедить людей в том, что ты сам придумал потому, что хочешь поспорить ради того, чтобы поспорить. Мне уже жалко тратить время, так как это бессмысленно что-то объяснять и делиться опытом.

 

Тебе показать печальную статистику 777 https://www.cyber-security.ro/blog/2018/02/12/cloudme-sync-1-10-9-remote-buffer-overflow/
И казалось бы, еть ужо 2018 кстати, практика отключения костылей по защите стека весьма живая, ибо уж очень заметен подъём производительности компа + портабельность кодов улучшается

 

@UbIvItS, а где собственно статистика?

 

https://packetstormsecurity.com/files/tags/overflow некие сводные графики искать не буду, но списки и даты уж говорят сами за себя

 

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

 

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

 

https://www.ptsecurity.com/upload/corporate/ww-en/analytics/WebApp-Vulnerabilities-2017-Q4-rus.pdf
скриптики дажь при идеальном интерпретаторе == вещь крайне подлая и гнусная

 

Проблема не в скриптиках, а в тех, кто эти скриптики пишет. Ваша статистика это ещё раз подтверждает.

 

перво-наперво, всё же стоит учитывать, что любой код/решение/устройство == еть Диавольский клубок компромиссов. а в скриптах обеспечить качественный уровень защиты действительно сложно: дажь элементарное разграничение меж рид-онли и экзе мод тамо весьма сумрачное.. cat /path/to/readOnly.sh|sed $cmd|bash иль та же команда source, + ещё есть весьма годная фича акь отсутствие жёсткого типа переменной, что способствует массе логических сюрпризов. Но при этом скриптики крайне удобная чертовщина в хозяйстве

 

UbIvItS, Ты так сильно уперт на своей позиции. Представленный выше кусочек сыра это неаргумент. Здесь необходимо сопоставлять количество Lines of Code с количеством найденных ошибок, по годам, как это например сделано в книге Хоглунда "Взлом программного обеспечения", как раз на полке стоит, поглядываю на нее и вспоминаю оттуда примеры. Так вот учитывая популяризацию разработки ПО, количество критических багов не так и велико, по отношению на строчки кода тенденция идет на снижение, это говорил Крис Касперски при жизни. Публично или в личных беседах не могу сказать, но точно говорил опираясь на свой опыт.

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

 

а что ты понимаешь под выражением "критический баг" ???

 

Что вы понимаете под надежностью ?

Во первых HTML это не язык программирования, а язык разметки. Дебажить его можно при помощи разных браузеров.

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

https://habr.com/post/248971/
https://xakep.ru/2010/02/16/51166/

Можно также проверять на уязвимости, не только PHP кода, но и сервера, например при помощи Netsparker.

Также можно писать нагрузочные тесты.

Хочу добавить, если говорить про тесты, есть неплохие фреймворки:

1)Для С++:https://ru.wikipedia.org/wiki/Google_C++_Testing_Framework

2)Для Си:https://habr.com/post/244835/

 

Надёжность трудно измерить и высчитать. Вот к приему надёжность SSD 100 лет, а гарантия 1 год!
А у программ ещё хлеще. Не может у них функция сломаться как то делает электроника. Вот электроника она состоит из электрических элементов транзисторы, резисторы, катушки, конденсаторы и каждый этот элемент имеет срок службы и вероятность отказа. К примерупленочные конденсаторы расслаиваются с течением времени, маслянные конденсаторы высыхают. Катушка если она в моторе можете перетереться или перегреться и разорваться от тряски

Вот вы скажете, но у программистов такого нет! И ошибётесь. Эту историю мне пересказывали ни раз и не два, причем даты разнились на пару десятков.
Вот её пересказ от Самат Кудайбергенов на портале warhead.su. Он утверждает, что ни самая сильная армия в мире, ни штат программистов, ни новейшее вооружение не спасут от смерти, если в дело вмешаются математика и невнимательный кодер! Такая вот математическая оплошность в ЗРК Patriot привела к гибели пятой часть всех погибших американцев за всё время войны в Заливе.

По другой версии эта история произошла на пару десятков раньше в 70-тых годах и с неё зародилась программная надёжность.
Но до сих пор мы толком не умеем ни считать ни измерять надёжность.

Одна из причин это детерминированность программ. Что предлагается?
I. Статическое тестирование.
Все мы компилировали программы и видели журнал компилятор он обычно ругается на ошибки, а так же даёт предупреждения. Вот это и есть статическое тестирование.
Ворнингы как раз и предупреждают программиста о ошибках. Обычно такие анализаторы проверяют типичные ошибки, позволяя вспомнить, то о чем он забыл.
Разные статические анализаторы работают по разному, можно выделить 3 разных. Встроенный в компилятор делает минимум проверок. Для расширенного анализа следует скачать PVS-Studio Analyzer или любой другой. А есть 3 вид анализаторов направленный на выявление уязвимостей.
II. Фазинг - словно слово из фантастического фильма.
На самом деле это очень большой труд по написанию тестов.
Фазинг техника проверки кода, когда вы подбираете входные данные для тестов чтобы зайти во все ветки условий и циклов.
Процитирую ГОСТ РВ 51719-2001
- Тестирование это процесс проверки функционирования программ с использованием представленных входных данных или условий, для которых известны ожидаемые результаты.
- Каждая ветвь программы должна быть опробована по крайней мере один раз.

В основном фазинг делается вручную иногда автоматически. А что-бы облегчить себе жизнь применяют генераторы программ. Такие как protobuf. Считается что сгенерированный код вам тестировать не нужно, а это забота разработчика генератора.

Для нативных ЯП автоматический фазинг сделать проще если программа выдала исключение или упала это свидетельствуют о ошибках в коде. Автоматический фазинг годится для проверки форматов файлов а так же протоколов но почти не годится для проверки бизнес логики. Тут уже придётся писать тесты вручную.
---------------------

Покрытие кода тестами выявляет большинство ошибок. Что касается PHP, то тут проверка на пустые страницы, не активные кнопки.
По нажимать кнопками можно автоматически через Accessibility вот парочка фреймворков .
https://www.joecolantonio.com/2018/02/08/accessibility-testing-tools-automation/
https://habr.com/company/infopulse/blog/253729/

 

> а можно ли как то проверить надёжность программы написанной на высоко уровневом языке программировании?

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

 

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