The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Стандарт по безопасному программированию на языках Си и Си++

14.03.2008 22:52

Готовится к выходу первая версия неформального стандарта, обобщающего требования и рекомендации по созданию безопасных программ на языке Си - "CERT C Secure Coding Standard" и Си++ - "CERT C++ Secure Coding Standard". Релиз документа будет выпущен 18 апреля, до этого момента разработчики будут рады выслушать замечания и предложения.

Кроме того, можно отметить две ссылки:

  • "Top 10 Secure Coding Practices" - десять простых правил для разработчиков безопасного ПО;
  • "2007 CERT Research Annual Report Published" (PDF, 3.5Мб) - достижения CERT в разработке теоретического базиса и инженерных методов по обеспечению безопасности критических систем и сетей.


  1. Главная ссылка к новости (http://seclists.org/dailydave/...)
  2. CERT Secure Coding Standards
Лицензия: CC-BY
Источник: lwn.net
Тип: английский / Справочная информация
Ключевые слова: cert, display, cvs, search, port, http, postscript, text
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, chesnok (ok), 00:16, 15/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А существует стандарт безопасного "программирование" на PHP ?
     
     
  • 2.3, grislock (ok), 00:29, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    как и для любого другого средства разработки веб-приложений, стандарт простой:
    не верь данным приходящим снаружи.

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

     
     
  • 3.5, aleoparin (ok), 01:53, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ну не только это, еще хотя-бы деление на нуль тоже проверить не помешает .. ;)
     

  • 1.2, AdVv (??), 00:27, 15/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ошибка в ссылке на top 10 secure coding
     
     
  • 2.4, zaa (??), 00:45, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Cod
     

  • 1.6, pavlinux (ok), 04:01, 15/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Одна из единиц, полезных ссылок и новостей за этот год!
     
  • 1.7, Kisa (??), 09:11, 15/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мыши плакали и кололись, но продолжали упорно жрать кактус.
     
     
  • 2.8, ДяДя (?), 11:07, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    +1

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

     
     
  • 3.9, Pilat (?), 13:09, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Металл это что ?
     
     
  • 4.11, Bj (?), 13:35, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Паскаль ^_^
     
  • 3.10, Vvv (?), 13:13, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Esli ne secret, chto vi imeete v vidu pod "derevyanniy samolyot" i chto togda po vashemu "metal"?
     
  • 3.12, earl (?), 14:57, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, когда то мой товарищ си-плюс-плюсник был в замешательстве, читая книжку какогото корифея C++, в ней в одном разделе писалось, что его нельзя ипользовать для написания высоконадежных программ, особенно связаных с критическими вещами и безопасностью жизни, приводились примеры почему.
    В качестве альтернатив упоминалась АДА, и еще что то, непомню
     
  • 2.17, TyLLIKAH (?), 16:35, 16/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    C - это инструмент, которым можно либо легко и удобно работать, а можно отрезать себе руку. Всё зависит от вашей квалификации. Например: все должны есть ложками, вилками можно выколоть себе глаз ненароком. Прокатит такое в реальной жизни ? Например: у мебели не должно быть острых углов, а все стены должны быть оббиты мягким материалом - добро пожаловать в дурдом. В С программисту предоставлена свобода: не хочешь использовать множественное наследование - не используй, не хочешь использовать голые указатели - не используй.

    У нас один "корифей" преподавал язык Ада в универе таким образом: говорил "множественное наследование - это ужас, мучения и смерть. В Аде такой бяки нет!" и тут же рисовал пример на Аде: подключение кучи пакетов, и написание альясов к ним. Разобрать потом, что откуда он дёргает было невозможно. Реально адский язык.

    По поводу мышей: сначала мне говорили: пролог - язык будущего, С - мёртв. Потом мне говорили Паскаль - язык настоящего, а С мёртв. Потом мне говорили Java - язык завтрашнего дня, С - мёртв окончательно, наконец-то изобрели СHash - теперь С точно помер... А С всё живёт и живёт. И Борланд ворует в свой Delphi сишные фишки, и cvsup на С переписали наконец-то (с ультрабезопасной модулы, придуманной гениальным Виртом), и стандарты вот разные принимают. Странно как-то для мёртвого языка. Нет? С\С++ - это идеальный компромисс между быстродействием и надёжностью, всё остальное академические поделки, представляющие лишь научный интерес.  

     
     
  • 3.25, f00l (ok), 10:19, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >С\С++ - это идеальный компромисс между быстродействием и надёжностью,
    >всё остальное академические поделки, представляющие лишь научный интерес.

      полностью поддерживаю !!!


     
  • 3.32, muxas (??), 16:58, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >C - это инструмент, которым можно либо легко и удобно работать, а
    >можно отрезать себе руку. Всё зависит от вашей квалификации. Например: все
    >должны есть ложками, вилками можно выколоть себе глаз ненароком.

    Однако, согласитесь, кусок мяса есть вилкой удобнее, чем ложкой. А суп вилкой одолеть будет еще сложнее. Так что не забудем, для какой задачи мы используем язык.

    >всё остальное академические поделки, представляющие лишь научный интерес.

    зачастую далеко не академические, иногда не поделки, и если до сих пор существуют, значит к ним есть интерес в широких массах... ;-)

     

  • 1.13, SnoWLight (?), 18:30, 15/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сразу скажу я не программист, но в начале пример
    int avg(int a, int b) { return (a + b) / 2; }
    поверг меня в шок и ужас
    http://bugtraq.ru/library/programming/badcode.html
     
     
  • 2.14, ilikeFreeBSD (?), 19:18, 15/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    статья по линку - супер !
     
  • 2.16, coder (?), 14:54, 16/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    статья по линку очень смешная
    это еще автор всего опенсоурс нерасматривал....там еще хуже)))))
    но речь не о том
    все что рассматривал автор имет смысл ТОЛЬКО если это разработка ведеться группой разработчиков

    но если это работа двух трех девелоперов
    то поверте ничего страшного в int avg(int a, int b) { return (a + b) / 2; }
    я невижу
    если изначально вся программа использующая это продумана
    и уже изначально a и b не будут приходить такими.....

    есть много примерв
    где к примеров программ очень граммотно написаных
    делают write(fd, element->buffer, element->length) когда
    element = NULL;
    НО
    список из которого это читаеться никогда не будет включать таких NULL элементов
    но это ньюансы

     
  • 2.18, KBAKEP (??), 19:26, 16/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Чёт автор перемудрил. Если ему не нравится
    int avg(int a, int b) { return (a + b) / 2; }
    то легко можно переписать так:
    int avg(int a, int b) { return 0.5*a + 0.5*b; }
    Без условных переходов, переполнений и "левых" функций типа sign().
     
     
  • 3.19, аноним (?), 22:23, 16/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А ничего, что функция возвращает int (целое), а возвращаемое значение вычисляется делением на 2? :) Т.е. возвр. значение должно быть числом с плавающей точкой.
     
     
  • 4.20, никто (??), 23:34, 16/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда уж логичнее
    int avg(int a, int b) { return a/2 + b/2; }
    хотя умножение на 0.5 тоже нормально работает. :)
     
     
  • 5.21, citrus (??), 01:08, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Тогда уж логичнее
    > int avg(int a, int b) { return a/2 + b/2; }

    Подумайте, что вернет этот вариант avg(1,1)

     
     
  • 6.22, никто (??), 02:19, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Вернёт 0, но речь то о том что нужно избежать переполнение буфера, а точность возвращаемого результата зависит от поставленной задачи. Может мне и нужно чтобы функция в таком варианте параметров возвращала 0, главное чтобы не было переполнения. :)
     
     
  • 7.26, xor2003 (?), 10:22, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь не переполнение буфера, а переполнение переменных/регистров
     
  • 6.24, аноним (?), 07:52, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >> int avg(int a, int b) { return a/2 + b/2; }
    >Подумайте, что вернет этот вариант avg(1,1)

    1/2 + 1/2 = 1

    Не знаю где тут выкопали 0 %)

     
     
  • 7.27, f00l (ok), 10:23, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>> int avg(int a, int b) { return a/2 + b/2; }
    >>Подумайте, что вернет этот вариант avg(1,1)
    >
    >1/2 + 1/2 = 1
    >
    >Не знаю где тут выкопали 0 %)

    это на бумаге 1 а в программе 0

     
  • 2.23, Vital (??), 05:26, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Жуткое решение предлагает автор, такое мог написать разве что школьник, только изучающий  программирование. Если имеется вероятность переполнения, то куда правильней использовать более вместительный тип данных, например, если int - это 32 бита, то функция будет выглядеть так:

    int avg(int a, int b) { return ((int64)a + (int64)b) / 2; }

    Однако, на ассемблере можно сделать еще элегантнее с тем же самым типом :)

     
     
  • 3.28, Keeper (??), 10:35, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше сразу тип данных с плавающей запятой, тогда и округление будет точнее.

    int avg( int a, int b) {
       return (int) lround( ((double)a + (double)b) * 0.5);
    }

     
     
  • 4.34, Vital (??), 18:17, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    нет не лучше, ибо совсем другие инструкции процессора и совсем другие такты
     
     
  • 5.35, smb (?), 21:19, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    FPU достаточно быстро работает на современных процессорах, не надо ля-ля. Ничуть не медленней АЛУ. На конвертацию да, придётся потратиться...Но я бы стал так писать, если что - ибо пара тактов в нерасчётной задаче абсолютно некритична.
     
     
  • 6.36, Vital (??), 21:49, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    да конечно можно кивать в сторону скорости процессоров, и писать проги в стиле "лижбы работало", но применять решения с плавающей точкой, там, где все элементарно делается целыми числами, мягко говоря не разумно.. хотя, конечно, у каждого свой взгяд на жизнь...
     
  • 5.37, Keeper (??), 09:41, 18/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Но:
    1. Смотря какого процессора. На i686 преобразование int <-> double займет лишь несколько тактов.
    2. В исходной задаче нигде не было сказано, что пользоваться следует только целочисленной арифметикой. ;)
     
  • 3.29, иван (??), 12:24, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    в твоем варианте результат будет неверен оно будет усечено >int avg
     
     
  • 4.33, Vital (??), 18:12, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    результат будет верен, ничего не потеряется :)
     
  • 3.38, 11a (?), 02:37, 19/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Жуткое решение предлагает автор, такое мог написать разве что школьник, только изучающий
    > программирование.

    Полностью не согласен!! Пустые штампы без аргументов%)

    > Если имеется вероятность переполнения, то куда правильней использовать более
    >вместительный тип данных,

    Да, "куда правильней"??

    > например, если int - это 32 бита, то
    >функция будет выглядеть так:
    >
    >int avg(int a, int b) { return ((int64)a + (int64)b) / 2;
    >}

    Я считаю просто лишние операции на преобразование и вычисление для x86 например.
    Так а если у нас аргументы сами уже будут avg(long long int a, long long int b) что тогда?? ;))
    К тому же с переносимостью тоже не всё ясно - С99??

    На том же сайте обсуждается более эффективый алгоритм.

    >Однако, на ассемблере можно сделать еще элегантнее с тем же самым типом

    PS. В тему!! http://www.wasm.ru/article.php?article=onebyte


     

  • 1.15, yantux (??), 00:33, 16/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда будет аналогичный стандарт по java?
     
  • 1.30, аноним (?), 13:06, 17/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    При умножении на 0.5 происходит автоматическое приведение к типу double. Приведение к int происходит только когда уже вычислено значение выражения, так что  в таком варианте avg(1,1) вернёт 1.

    Имеем два преобразования int в double, три операции с плавающей точкой, и обратное преобразование double в int. В варианте из статьи имеет два вычисления знака int, один переход и две операции с int( вычисление знака тоже можно сюда отнести, так что будет всего 4 с int и один if).

     
     
  • 2.31, аноним (?), 13:35, 17/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >что будет всего 4 с int

    хотя нет,их ещё и сравнить надо

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру