1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

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

Тема в разделе "WASM.ZEN", создана пользователем X-Shar, 17 фев 2018.

  1. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.443
    это несколько лукавое предложение :) strcat в данном случае является неотъемлемой частью join, тч обрушить его эксплойтиком не получится.
    это с аких пор переполнение буфера стало "фантомными страхами" 777 :) либо оно в коде есть, либо его в коде нет -- 3го нет :grin: к тому же, твоё утв (мол-де допущение таких ансейф фунок в коде) способствует ускорению кода весьма сомнительно..

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

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    300
    UbIvItS, либо оно в коде есть, либо его нет, если ты его не сможешь спровоцировать входными данными, то его нет верно?
     
  3. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.443
    простой пример: твою либу аки-она-есть взяли для интерпретатора скриптов и благодаря ей (твоей либе) в интерпретаторе появляется buffer overrun чрез скриптики.
     
  4. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.586
    Адрес:
    г. Санкт-Петербург
    Ну, то есть, вы согласны с тем, что я безопасно использую strcat, соблюдая контракт, который был описан в комментарии к функции?

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

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

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

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

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

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.443
    небезопасная функа можь быть определена чрез #define и в бинарных кодах её не будет от слова СОВСЕМ :grin: + Ты в общем и целом привёл частный случай. а в большинстве вариаций небезопасная функа остаётся небезопасной. Опять же простой пример: твоя прога должна поддерживать аддоны чрез скриптики.
    хмм.. еть чрезвычайно оптимистично :) при кодах без переполнения буфера можно отключать защиту стека/ASLR/прочую крень. а тамо тиков-таков поболей.. сильно поболей.
    вот ЫмЭнно == достаточно исключить наиболее вопиющие косяки в изначальном коде, а потом ненужна будет туева хуча костылей. И тута совсем неважно внутренний апи иль внешний.. к тому же, столь строгое разграничение не всегда достижимо.
    https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stack_canaries
    так о том и речь :)
    целостность подхода как раз-таки и требует чётко реализовать потроха, дабы хвосты не торчали, за кои можно потянуть :grin:
     
  6. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    300
    Это не пример, это плод твоего воображения.

    Код (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 лет. Неужели ты всего этого не знаешь на полном серьезе? Уже порядка двух страниц ты пытаешься убедить людей в том, что ты сам придумал потому, что хочешь поспорить ради того, чтобы поспорить. Мне уже жалко тратить время, так как это бессмысленно что-то объяснять и делиться опытом.
     
    Последнее редактирование: 27 апр 2018
  7. UbIvItS

    UbIvItS Well-Known Member

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

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    300
    :acute:@UbIvItS, а где собственно статистика?
     
  9. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.443
    https://packetstormsecurity.com/files/tags/overflow некие сводные графики искать не буду, но списки и даты уж:crazy: говорят сами за себя :grin:
     
  10. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    300
    UbIvItS, понятно, статистики нет судя по всему, хоть проверяй в следующий раз, чтобы так в лужу не садиться :grin:
     
  11. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.586
    Адрес:
    г. Санкт-Петербург
    UbIvItS, в общем, не знаю, что вы там себе возомнили, но всё звучит как какой-то бред.
    Опытный разработчик грабли аккуратно обойдёт, нуб наступит на грабли даже там, где их нет. Не вижу смысла дальше что-то обсуждать.
     
  12. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.443
    upload_2018-4-28_12-33-56.png
    https://www.ptsecurity.com/upload/corporate/ww-en/analytics/WebApp-Vulnerabilities-2017-Q4-rus.pdf
    скриптики дажь при идеальном интерпретаторе == вещь крайне подлая и гнусная :)
     
  13. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.586
    Адрес:
    г. Санкт-Петербург
    Проблема не в скриптиках, а в тех, кто эти скриптики пишет. Ваша статистика это ещё раз подтверждает.
     
  14. UbIvItS

    UbIvItS Well-Known Member

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

    im. Active Member

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

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

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.443
    а что ты понимаешь под выражением "критический баг" ???:blush2:
     
  17. X-Shar

    X-Shar Active Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    354
    Что вы понимаете под надежностью ?

    Во первых 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/
     
  18. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.407
    Адрес:
    Fryazino
    Надёжность трудно измерить и высчитать. Вот к приему надёжность 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/
     
    Mikl___ и Indy_ нравится это.
  19. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.430
    > а можно ли как то проверить надёжность программы написанной на высоко уровневом языке программировании?

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