The OpenNET Project / Index page

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

Рейтинг самых опасных ошибок при создании программ

01.07.2011 15:33

Институт SANS (SysAdmin, Audit, Network, Security), совместно с организацией MITRE и ведущими экспертами по компьютерной безопасности, подготовил новую редакцию рейтинга 25 самых опасных ошибок, приводящих к возникновению серьезных уязвимостей. Рейтинг построен на основе анализа уязвимостей, обнаруженных в течение 2010 года. Ошибки были отобраны с учетом их распространенности, трудоемкости обнаружения и простоты эксплуатации уязвимости. В опубликованном документе подробно разбирается каждый из 25 видов ошибок, приводятся примеры уязвимостей и рекомендации для разработчиков по предотвращению появления подобных ошибок.

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

Общий рейтинг:

  • 1. SQL Injection: Неспособность сохранения целостной структуры SQL запроса, что может привести к подстановке злоумышленником SQL запроса;
  • 2. OS Command Injection: Неспособность корректного формирования структуры запускаемого приложения, может привести к подстановке кода злоумышленника при выполнении внешней команды, через определение некорректных значений, используемых в качестве параметров запускаемой программы;
  • 3. Buffer Overflow: Копирование содержимого буфера без предварительной проверки размера входных данных. Неспособность удержать действия в определенных жестких рамках или в пределах заданного буфера памяти, приводит к классическим уязвимостям вида выхода за допустимые границы и переполнению буфера;
  • 4. XSS, Cross-site Scripting: Неспособность сохранения структуры web-страницы, что позволяет злоумышленнику внедрить на страницу свой скрипт или html-блок;
  • 5. Missing Authentication: Отсутствие аутентификации при выполнении критических действий (например, при смене пароля, отсутствует проверка старого пароля);
  • 6. Missing Authorization: Отсутствие должной проверки авторизации, что может привести к получению доступа к ресурсам или выполнения операций, не имея на это полномочий;
  • 7. Hard-coded Credentials: Задание базового пароля или параметров аутентификации прямо в коде скрипта или в общедоступных файлах конфигурации;
  • 8.: Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде;
  • 9.: Неограниченная возможность загрузки файлов опасного типа, например, когда через форму загрузки картинки на сайт можно загрузить (и затем выполнить) ".php" скрипт;
  • 10.: Доверие к непроверенному вводу при принятии решений, связанных с безопасностью. Например, излишнее доверие к содержимому cookie (кодирование прав доступа или уровня пользователя через cookie);
  • 11.: Выполнение приложений с предоставлением излишних привилегий и без надлежащего сброса привилегий;
  • 12. Cross-Site Request Forgery (CSRF): Отсутствие проверки источника запроса, что может быть использовано злоумышленником для незаметного перенаправления авторизированного пользователя для выполнения определенных скрытых действий;
  • 13. Path Traversal: Возможность внешнего переопределения путей или имен файлов, например, когда в качестве имени файла используется какой-то передаваемый параметр, используя "../" в котором можно выйти за пределы текущей директории;
  • 14.: Загрузка исполняемого кода без проверки его целостности через сверку с цифровой подписью, например, в результате взлома сайта или подстановки неверной информации в DNS, злоумышленник может изменить содержимое пакета с программой;
  • 15.: Некорректная авторизация. При доступе к требующему определенных привилегий ресурсу проверка доступа осуществляется некорректно, давая возможность атакующему преодолеть ограничения, свойственные его уровню доступа;
  • 16.: Включение внешней функциональности из недоверительной области. Например, включение на страницу виджета со внешнего ресурса, который теоретически может быть подменен злоумышленником через взлом сторонней системы или некорректное использование директивы include в PHP, позволяющей атакующему совершить включение кода с внешнего сайта;
  • 17.: Небезопасное назначение прав доступа к критически важным ресурсам, например, возможность чтения или изменения другим пользователем конфигурационных или служебных файлов;
  • 18.: Использование потенциально опасных функций, которые при неосторожном использовании могут привести к появлению уязвимостей. Классический пример подобных функций - strcpy и sprintf;
  • 19.: Использование ненадежных или рискованных криптографических алгоритмов. Например, использование XOR или DES;
  • 20.: Некорректный расчет размера буфера;
  • 21.: Отсутствие ограничения излишних попыток авторизации. Например,отсутствие лимита на число неудачных попыток авторизации в единицу времени может привести к осуществлению атак, направленных на подбор паролей (brute force);
  • 22.: Перенаправление на вызывающий доверие сайт через некорректное использование средств переброса на другой URL в веб-приложениях (например, когда когда в скрипт локального переброса вместо "/redirect?url=form.php" передают "/redirect?url=http://example.com");
  • 23.: Неконтролируемое форматирование строк (ошибка форматирования строк в функциях подобных printf);
  • 24.: Проблемы, связанные с целочисленным переполнением;
  • 25.: Создание хэшей на основе входных данных (например, пароля) без задействования случайного salt, что позволяет атакующим при проведении словарной атаки использовать списки предгенерированных хэшей, например, rainbow-таблицы.

Проблемы в рейтинге разделены на три категории:

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


  1. Главная ссылка к новости (http://cwe.mitre.org/top25/ind...)
  2. OpenNews: Рейтинг самых опасных ошибок, зафиксированных в 2009 году
  3. OpenNews: 25 самых опасных ошибок при создании программ в 2008 году
  4. OpenNews: 20 самых значительных уязвимостей 2007 года
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31061-security
Ключевые слова: security, bug
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, VoDA (ok), 15:53, 01/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    Вроде как бОльшая часть этих ошибок - чисто PHP или близкие к нему.

    Пишите люди на Java и не будет SQL injection и минимум десятки указанных уязвимостей )))

     
     
  • 2.3, XPEH (?), 15:59, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пишите люди на Java и не будет SQL injection

    Ну да конечно.

     
  • 2.6, Аноним (-), 16:04, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Жабистов сразу видно: они полагают что умный фреймворк почему-то заменяет программеру мозг. В результате - самое ламерское шифрование, идиотские ошибки авторизации, тотальное доверие вводу пользователя и прочие классические баги - у жабистов просто дуром прут. А что, за них же фреймворк подумает.
     
     
  • 3.12, VoDA (ok), 16:52, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Жабистов сразу видно: они полагают что умный фреймворк почему-то заменяет программеру мозг.
    > В результате - самое ламерское шифрование, идиотские ошибки авторизации, тотальное доверие
    > вводу пользователя и прочие классические баги - у жабистов просто дуром
    > прут. А что, за них же фреймворк подумает.

    Шифрование, ЭЦП по ГОСТ-у. Может С++ или PHP делает не ГОСТ шифрование, но это дело наказуемое )))

    Я считаю, что если есть возможность сделать ошибку программер рано или поздно ее совершит. А на большом проекте однозначно совершит.

     
     
  • 4.20, Карбофос (ok), 23:47, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >А на большом проекте однозначно совершит.

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

     
  • 4.27, AHAHAC (ok), 02:37, 03/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Проснулся!

    $ openssl engine gost -t -c -vvvv

    (gost) Reference implementation of GOST engine
    [gost89, gost89-cnt, md_gost94, gost-mac, gost94, gost2001, gost-mac]
         [ available ]
         CRYPT_PARAMS: OID of default GOST 28147-89 parameters
              (input flags): STRING

     
  • 2.8, klalafuda (?), 16:31, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Пишите люди на Java и не будет SQL injection и минимум десятки указанных уязвимостей )))

    Почему то автоматически вспоминается боян про дурака и стеклянный хер.

     
     
  • 3.10, VoDA (ok), 16:45, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    почему то в 2011 году еще существуют ошибки типа SQL injection... я сильно удивлен вообще их наличием. И полный ахтунг, что это САМАЯ критичная ошибка.
     
     
  • 4.13, klalafuda (?), 16:54, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > почему то в 2011 году еще существуют ошибки типа SQL injection... я сильно удивлен вообще их наличием. И полный ахтунг, что это САМАЯ критичная ошибка.

    Элементарно, Ватсон! Вот когда уберут вот эту ф-ю http://ru2.php.net/manual/en/function.mysql-query.php из API PHP только тогда резко пойдет на спад кол-во инжектов.

     
     
  • 5.15, pro100master (ok), 18:57, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А при чем тут она? Данные надо проверять. Аксиома родилась на следующий день, когда первую программу дали первому пользователю :) Так что причины всех ошибок - в голове.
     
  • 5.21, Щекн Итрч (ok), 00:23, 02/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Пока "программист" НЕ СТАНЕТ чистить запросы - будут инъекции.
    При чем там пхп ваще?
     
     
  • 6.22, PereresusNeVlezaetBuggy (ok), 00:56, 02/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока "программист" НЕ СТАНЕТ чистить запросы - будут инъекции.
    > При чем там пхп ваще?

    Притом, что PHP и другие языки (фреймворки, среды...), которые позволяют легко обращаться со строками, а также «простота» самого SQL провоцируют написание кода в духе:


    query("SELECT * FROM table WHERE id = " . $_REQUEST["id"]);


    Более того, не раз и не два видел руководства по написанию программ на самых разных языках (но чаще всего именно на PHP), где предлагалось так писать программы, даже без комментария, что это плохо. Чего удивляться, что юные индусские умы, которые банально (ещё) не в курсе нюансов того же SQL, пишут вслед такой же код. Сил ругаться уже нет, просто мрачно считаю.

     
  • 5.25, Sw00p aka Jerom (?), 15:16, 02/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    идём по ссылке и видим

    // Formulate Query
    // This is the best way to perform an SQL query
    // For more examples, see mysql_real_escape_string()
    $query = sprintf("SELECT firstname, lastname, address, age FROM friends WHERE firstname='%s' AND lastname='%s'",
        mysql_real_escape_string($firstname),
        mysql_real_escape_string($lastname));

    // Perform Query
    $result = mysql_query($query);


    пс: уже радует ))))))))))))

     
  • 2.9, Аноним (-), 16:44, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Пишите люди на Java и не будет SQL injection и минимум десятки указанных уязвимостей

    Девятки десятых производительности вы лишитесь. И не буду про магический float напоминать.

     
     
  • 3.11, VoDA (ok), 16:49, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Пишите люди на Java и не будет SQL injection и минимум десятки указанных уязвимостей
    > Девятки десятых производительности вы лишитесь. И не буду про магический float напоминать.

    0,9% производительности я могу потратить за удобство разработки ;)))

    много лет занимаюсь разработками больших корпоративных систем. Везде только int и long - никакой потери точности не допускается. ИМХО float нужен только для обсчета мега-задач по физике и анализу результатов экспериментов, когда потеря точности компенсируется тем, что процессор может оперировать подобными данными напрямую, чем ускоряет обработку.

    Для точных систем считаю, что нужно делать обертку поверх int/long и самостоятельно обрабатывать данные без потери точности.

     
     
  • 4.14, Andrew Kolchoogin (?), 17:20, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Для точных систем считаю, что нужно делать обертку поверх int/long и самостоятельно
    > обрабатывать данные без потери точности.

    Откройте для себя GNU GMP.

    Там есть Arbitrary Precision и для int, и для float. И ещё для рациональных дробей.

     
  • 3.29, cerberus (?), 14:26, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Девятки десятых производительности вы лишитесь.

    А вы уверены, кто вам такие сказки рассказал? PHP каждый божий раз компилирует скрипт и чем больше скрипт, тем дольше компиляция. Есть правда всякие механизмы кеширования, но это костыли, не более. Тогда как JAVA WEB приложение компилируется (JIT) один раз при его запуске и каждый HTTP запрос работает на тред-пуле (Thread pool).  Итог: JavaWeb кушает больше ОЗУ, чем PHP, зато ест меньше процессорного времени, ибо не компилирует скрипт при каждом HTTP запросе.

     
     
  • 4.33, Guest (??), 17:28, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, видимо кое кто не слышал про кэширование. Откройте для себя eaccelerator, к примеру
     

  • 1.4, qwerty (??), 16:00, 01/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а чем отличаются п. 20 и п. 3?
     
     
  • 2.7, letsmac (ok), 16:04, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    3 - не проверяем размер и корректность данных.
    20 - забываем выделить память.
     

  • 1.5, Аноним (-), 16:02, 01/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вроде все честно относительно. Ошибки наиболее типичные и хорошо наблюдаемые на практике.
     
     
  • 2.16, pro100master (ok), 18:59, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вроде все честно относительно. Ошибки наиболее типичные и хорошо наблюдаемые на практике.

    Более того - все они сводятся к одной единственной - отсутствие должной проверки входных данных :)

     
     
  • 3.17, PereresusNeVlezaetBuggy (ok), 21:27, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не все. 17, например, имеет отношение скорее к «выходу», чем ко входу.
     
     
  • 4.18, pro100master (ok), 22:05, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен - двояко, но спорно. Проверка прав, локально, это тоже входящие :)
     
     
  • 5.19, PereresusNeVlezaetBuggy (ok), 22:41, 01/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Согласен - двояко, но спорно. Проверка прав, локально, это тоже входящие :)

    Сама проверка — т.е., авторизация — идёт отдельным пунктом. Здесь же речь о кривости рук админа, которые к данным от юзера-хакера не относятся. :) Ну да не суть, это я так, по привычке придираюсь... :)

     

  • 1.23, ZloySergant (ok), 14:16, 02/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Хм. Штук пять из этого списка лечится умением (не учебой, епт) программирования на асме. В жестких рамках синтаксиса AT&T.

    З.Ы. Я не призываю писать код на асме. Просто умение им пользоваться налагает определенный отпечаток на мышление программиста.

     
     
  • 2.24, Sw00p aka Jerom (?), 15:13, 02/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Просто умение им пользоваться налагает определенный отпечаток на мышление программиста.

    умеющие им пользоваться ваще пишут свои языки и свои оси ))

     
  • 2.26, Ytch (?), 02:24, 03/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > ...лечится умением (не учебой, епт) программирования на асме.
    > Просто умение им пользоваться налагает определенный отпечаток на мышление программиста.

    Точно! Это как прививка - если есть, то срабатывает автоматически. ))

     
     
  • 3.28, AHAHAC (ok), 02:46, 03/07/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> ...лечится умением (не учебой, епт) программирования на асме.
    >> Просто умение им пользоваться налагает определенный отпечаток на мышление программиста.
    > Точно! Это как прививка - если есть, то срабатывает автоматически. ))

    Также и автоматически отключается, когда руководитель проекта дышит в затылок,
    со словами "Харош х...й заниматься, давай код генерируй!"

     
     
  • 4.31, десептикон (?), 15:34, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    не в бровь, а в глаз :)
     
  • 2.34, Карбофос (ok), 10:02, 05/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    минимизация объёма кода и/или повышение его эффективности, знание "подводных камней" архитектуры и фреймворков...
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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