The OpenNET Project / Index page

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

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

17.02.2010 21:16

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

Краткое содержание рейтинга (цифра вначале указывает на место в рейтинге):

  • Небезопасное взаимодействие между компонентами, определяет проблемы, вызванные небезопасной отправкой или получением данных между модулями, программами, процессами, нитями или системами.
    • 1: Неспособность сохранения структуры web-страницы, что позволяет злоумышленнику внедрить на страницу свой скрипт или html-блок (XSS, Cross-site Scripting);
    • 2: Неспособность сохранения целостной структуры SQL запроса, что может привести к подстановке злоумышленником SQL запроса (SQL Injection);
    • 4: Cross-Site Request Forgery (CSRF), отсутствие проверки источника запроса, что может быть использовано злоумышленником для незаметного перенаправления авторизированного пользователя для выполнения определенных скрытых действий;
    • 8: Неограниченная возможность загрузки файлов опасного типа, например, когда через форму загрузки картинки на сайт можно загрузить (и затем выполнить) ".php" скрипт;
    • 9: Неспособность корректного формирования структуры запускаемого приложения, может привести к подставке кода злоумышленника при выполнении внешней команды, через определение некорректных значений, используемых в качестве параметров запускаемой программы (OS Command Injection);
    • 17: Утечка сведений о системе при выводе сообщения об ошибке, например, часто в сообщении об ошибке можно видеть текущие пути или имя базы, что может быть использовано злоумышленником.
    • 23: Перенаправление на вызывающий доверие сайт через некорректное использование средств переброса на другой URL в веб-приложениях (например, когда когда в скрипт локального переброса вместо "/redirect?url=form.php" передают "/redirect?url=http://example.com");
    • 25: "Эффект гонки" (Race Condition), проблемы вызванные возможностью одновременного использования одного ресурса несколькими обработчиками, отсутствием атомарных операций или ненадлежащими блокировками;
  • Рискованное управление ресурсами, ситуации когда к проблемам приводит ненадлежащее управление созданием, использованием, передачей или уничтожением важных ресурсов системы.
    • 3: Копирование содержимого буфера без предварительной проверки размера входных данных. Неспособность удержать действия в определенных жестких рамках или в пределах заданного буфера памяти, приводит к классическим уязвимостям вида выхода за допустимые границы и переполнению буфера;
    • 7: Возможность внешнего переопределения путей или имен файлов, например, когда в качестве имени файла используется какой-то передаваемый параметр, используя "../" в котором можно выйти за пределы текущей директории;
    • 12: Доступ к буферу без учета его размера, например, когда осуществляется копирование из одного буфера в другой без проверки, что во втором буфере хватит места;
    • 13: Отсутствие проверки на необычные ситуации, например, при невыполнении проверки результата выполнения функции malloc (разработчик подразумевает, что она никогда не вернет NULL) злоумышленник может инициировать переход на нулевой указатель. Или при выполнении "fgets(buf, 10, stdin); strcpy(cp_buf, buf);" разработчик уверен, что после fgets строка всегда терминирована, но при ошибке ввода/вывода это не так;
    • 14: Некорректная обработки имени файла перед его использованием в PHP директивах Include/Require. Типичный пример: "$dir = $_GET['module_name']; include($dir . "/function.php");", если в передачей "module_name=http://сайт_злоумышленника";
    • 15: Некорректная проверка индекса массива, например, обращение к -23 или 978 элементам массива, когда общий размер всего 100 элементов;
    • 16: Проблемы, связанные с целочисленным переполнением;
    • 18: Некорректный расчет размера буфера;
    • 20: Загрузка исполняемого кода без проверки его целостности через сверку с цифровой подписью, например, в результате взлома сайта или подстановки неверной информации в DNS, злоумышленник может изменить содержимое пакета с программой;
    • 22: Выделение ресурсов без задания максимальных ограничений, например, классическая fork-бомба или забивание всего свободного места на диске;
  • Ненадежная защита, некорректное использование, игнорирование или злоупотребление средствами защиты.
    • 5: Некорректный контроль доступа (авторизации);
    • 6: Доверие к непроверенному вводу при принятии решений, связанных с безопасностью. Например, излишнее доверие к содержимому cookie (кодирование прав доступа или уровня пользователя через cookie);
    • 10: Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде;
    • 11: Задание базового пароля прямо в коде скрипта или в общедоступных файлах конфигурации;
    • 19: Отсутствие аутентификации при выполнении критических действий (например, при смене пароля, отсутствует проверка старого пароля);
    • 21: Небезопасное назначение прав доступа к критически важным ресурсам, например, возможность чтения или изменения другим пользователем конфигурационных или служебных файлов;
    • 24: Использование ненадежных или рискованных криптографических алгоритмов;

В заключение можно отметить интересную статистику, опубликованную в блоге Марка Кокса (Mark Cox), возглавляющего подразделение Red Hat, занимающееся выявлением и исправлением проблем безопасности. Марк проанализировал число устраненных в Red Hat уязвимостей по каждой из позиций вышепредставленного рейтинга Top25. Особый акцент сделан на уязвимостях, которые удалось предотвратить благодаря использованию таких технологий, как SELinux, ExecShield, защищенных вариантов malloc/free и активации FORTIFY_SOURCE опции glibc (дополнительная внутренняя проверка выхода за пределы буфера для функций, таких как strcpy). Например, дистрибутив оказался заведомо невосприимчив к серии уязвимостей, связанных с разыменованием NULL указателя.

  1. Главная ссылка к новости (http://cwe.mitre.org/top25/...)
  2. OpenNews: 25 самых опасных ошибок при создании программ
  3. OpenNews: Анализ рисков, связанных с проблемами безопасности в Red Hat Enterprise Linux
  4. OpenNews: Анализ проблем безопасности и оценка времени поддержки Red Hat Enterprise Linux
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: security, bug
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (72) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Zenitur (?), 23:13, 17/02/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.
     
     
  • 2.2, XoRe (ok), 23:22, 17/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.

    Угу.
    А установка SElinux делает Windows намного безопаснее)
    Там немалая часть уязвимостей относится к безопасности в web.
    На основании каких данных был сделан вывод о Windows, если не секрет?

     
     
  • 3.5, Zenitur (?), 00:56, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть от ужаса
     
     
  • 4.18, XoRe (ok), 10:08, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть
    >взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть
    >от ужаса

    С этим я не спорю)
    Я просто хочу указать ваше внимание, что все эти уязвимости не могут быть только на Windows.
    Так как там куча уязвимостей, относящихся к web (php, sql, алгоритмы обработки форм).
    Так же куча уязвимостей, относящихся к приемам программирования вообще.
    Ну и указание на то, что SElinux помогает, как-бы намекает на то, что это не только в Windows)

     
  • 4.64, Трухин_Юрий_Владимирович (ok), 12:19, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    И какие сотни обновлений была для поддерживаемых на сегодня ОС MS? В 2009 году Vista - 28 уязвимостей http://secunia.com/advisories/product/13223/?task=statistics_2009

    Windows 7 - 4 уязвимости! http://secunia.com/advisories/product/27467/?task=statistics_2009

    Red Hat Enterprise Linux 5 - 135 уязвимостей! http://secunia.com/advisories/product/13652/?task=statistics_2009

     
     
  • 5.65, Аноним (-), 20:18, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы тогда либо в поиске только ядро Linux выбирайте с минимальными GUI, либо все ... текст свёрнут, показать
     
     
  • 6.67, Трухин_Юрий_Владимирович (ok), 22:09, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год. Это без всяких Xов, графической оболочки и др. А значит - присутствовали во всех! дистрибутивах Linux в 2009 году на ядре 2.6.... http://secunia.com/advisories/product/2719/?task=statistics_2009
     
     
  • 7.70, Глеб В (?), 23:49, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год.

    Посмотрите на усердно вами цитируемом secunia степень опасности этих уязвимостей - Less critical или  Not critical. Я ни одной даже со статусом Moderately critical (умеренная опасность) не смог найти. Теперь набираем в поиске http://secunia.com/advisories/search/ Windows и видим только за февраль 9 уязвимостей из которых половина имеет статус Highly critical. Теперь я понимаю почему вас не любят на этом форуме, вы упорно подтасовывайте факты.

     
  • 5.66, Глеб В (?), 20:22, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр в web-приложениях это вы мощно сравнили.
     
     
  • 6.68, Трухин_Юрий_Владимирович (ok), 22:10, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр
    >в web-приложениях это вы мощно сравнили.

    какие веб-приложения в настольных системах... читайте внимательно

     
     
  • 7.69, Трухин_Юрий_Владимирович (ok), 22:11, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    это все я пишу в ответ на заявления человека о многих сотнях дыр в виндах в 2009 году...


     
     
  • 8.71, Глеб В (?), 23:52, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы ссылались на статистику по числу дыр в Red Hat, а не только в настольных прил... текст свёрнут, показать
     

  • 1.3, Tav (ok), 23:39, 17/02/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка PHP: построение SQL-запросов путем конкатенации, смешивание html-кода и программной логики, скрипты и файлы с данными вперемешку, изначальное отсутствие пространств имен, "magic quotes hell" (убрали, но каким местом раньше думали), register_globals (понятно, что обычно выключено, но как вообще можно было в здравом уме до такого додуматься).
     
     
  • 2.4, Cobold (??), 00:51, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    хорошо сказано :)
     
     
  • 3.8, vbv (ok), 02:49, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А Oracle не хочет приобрести php???
     
  • 2.7, Deffic (?), 02:48, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "..которая связанна с использованием непоследовательного и непродуманного языка PHP.."
    Если в Вашем тексте PHP заменить на SQL, то смысл не измениться. Всякие там иньекции и т.п.
    Но на SQL ни кто не гонит.
    На PHP есть масса очень грамотных проектов.
    Возможно, всё-таки проблема с руками.
     
     
  • 3.12, polymorphm1 (ok), 03:40, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    самая больная проблема в PHP -- это mod_php , который ПООЩРЯЕТ помещщение (и выполнение) php-файлов в тойже самой директории что и статические media-файлы..

     
  • 3.22, Tav (ok), 10:42, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема не в SQL. Все нормальные API для работы с SQL работают так: запрос с параметрами (например "SELECT * FROM table WHERE id = ?") сначала компилируется, а значения параметров подставляются уже при выполнении запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL и делает инъекции невозможными.

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

     
     
  • 4.26, Cobold (??), 11:50, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    эта норма пришла скорее от mysql, потому что там изначально небыло компиляции запросов, и любая прослойка позволявшая пользоваться переменными по сути ничего кроме конкатенации не делала. А ещё php во все времена имел очень низенькую планочку для IQ разработчика, поэтому им пользуются столько людей которые даже слова "фреймворк" не знают. В принципе, как windows - своей убогостью создал себе огромный рынок.
     
  • 4.29, Deffic (?), 12:19, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Проблема не в SQL. Все нормальные API для работы с SQL работают
    >так: запрос с параметрами (например "SELECT * FROM table WHERE id
    >= ?") сначала компилируется, а значения параметров подставляются уже при выполнении
    >запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL
    >и делает инъекции невозможными.

    А если логика запроса посложнее и состоит из 100 вложений ("инъекций")
    и поведение следующего вложения завязано на результате предыдущего (или нескольких)?
    Пелёнки всё вырежут?

    >
    >Для PHP тоже есть такие API, но в PHP построение запросов путем
    >подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные
    >функции предполагают именно такой способ.

    Разговор был о языках а не о API.
    При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются в бомбу.

     
     
  • 5.38, Tav (ok), 14:22, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А если логика запроса посложнее и состоит из 100 вложений ("инъекций")
    >и поведение следующего вложения завязано на результате предыдущего (или нескольких)?

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

    >Разговор был о языках а не о API.

    Вместе с языком предоставляется стандартный API.

    >При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются
    >в бомбу.

    Как будто не бывает плохих языков программирования. Понятно, что можно писать надежный код даже на PHP. Проблема в том, что PHP провоцирует порочную практику программирования, как я уже писал выше. Это как Бейсик: студенты изучавшие его, по словам Дейкстры, "подверглись необратимой умственной деградации".

     
  • 4.35, thirteensmay (?), 13:25, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Проблема не в SQL. Все нормальные API для работы с SQL работают
    >так: запрос с параметрами (например "SELECT * FROM table WHERE id
    >= ?") сначала компилируется, а значения параметров подставляются уже при выполнении
    >запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL
    >и делает инъекции невозможными.
    >
    >Для PHP тоже есть такие API, но в PHP построение запросов путем
    >подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные
    >функции предполагают именно такой способ.

    Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно.

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

     
     
  • 5.39, Tav (ok), 14:27, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно.

    Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных.

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

    Говорит, как минимум, о разгильдяйстве.

     
     
  • 6.41, thirteensmay (?), 14:50, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных.

    Нет никаких проблем с моделью данных, есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Кроме разных таблиц там еще куча динамически изменяющихся условий, т.е. and, or, between, case и т.п., ну не реализуется такое плейсхолдерами никак, и модель тут не причем.

    > Говорит, как минимум, о разгильдяйстве.

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

     
     
  • 7.43, Tav (ok), 15:34, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть.

    Это все-таки не обычное использование БД, исключение, а не норма. Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев.

    > ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.

    Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли все сложно?

     
     
  • 8.45, thirteensmay (?), 16:03, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вот с этим не могу не согласится Моя же речь про то что эти исключительные случ... текст свёрнут, показать
     
  • 8.51, Deffic (?), 18:25, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Позвольте не согласиться - это как раз НОРМА Если у Вас база нормализована, то ... текст свёрнут, показать
     
  • 8.73, AlexAT (ok), 13:47, 12/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ошибаетесь Это давно уже норма Время, когда все можно было сделать запросами в... текст свёрнут, показать
     
  • 5.42, Cobold (??), 14:57, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Проблема безопасности заключается в первую очередь не в языках или технологиях, а
    >в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во,
    >специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость
    >тоже конечно имеет место быть, но вот я лично прекрасно знаю
    >кучу уязвимостей в своих поделках, но не исправляю их ибо не
    >до того, не интересно, есть др. задачи, лень, за это не
    >заплатят, и т.п. что в общем то заметьте не говорит о
    >моей криворукости.

    А вот смотрите, не в защиту перла а просто как сравнение: на перле с базой работают через DBI, весь её интерфейс и документация изначально подразумевают компиляцию запросов и исполльзование переменных, и никому не приходится тратить какие-то дополнительные усилия чтобы узнать как работать с ней безопасно (разве что этот кто-то из php пришёл). Почему? - потому что перл не имеет нативных функций для sql , там изначально работают с фреймворками и к этому привыкли, а этот фреймворк был написан не как api wrapper для mysql а как универсальный инструмент для профессиональной работы с базами. И что получается? PHP для той-же самой функциональности требует от разработчика более низкого интеллекта чем перл, в результате новичёк работая с перлом подтянется, а хороший специалист работая с php расслабится и будет писать плохой код, потому что "и так работает". При том что качественный код каких-то дополнительных трудозатрат особо и не требует, это только следствие определённой культуры. Культурному человеку ведь не приходится тратить время чтобы им оставаться?

     
     
  • 6.44, thirteensmay (?), 15:40, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполнять, тыщу раз такое видел и сам делал, говорю вам не в инструменте дело, точнее не в первую очередь в инструменте. Качественный продукт к сожалению таки требует дополнительных трудозатрат. А вот про культуру вы хорошо заметили, все прекрасно, но это только в идеальном сферическом мире, а на практике все под елочку ходят когда приспичит.

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


     
     
  • 7.47, Cobold (??), 17:29, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    я не о том что на перле это невозможно, я о том что там в отличии от php при работе с базой наиболее лёгкий и удобный способ одновременно является и более безопасным, и при этом приучает делать более качественный код. Может быть в этом главная слабость php - он реализует очень много функциональности на уровне языка вместо того чтобы стимулировать развитие более качественных фреймворков, а все эти стандартные расширения практически монополизируют свою функцию, какому-то конкурирующему решению очень сложно пробиться.

    P.S. ещё раз, я здесь имею в виду только DBI и отдельные особенности перла, не говорю про весь язык и всё что на нём написанно.

     
     
  • 8.52, thirteensmay (?), 18:35, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а я вам про то что я например, при освоении DBI был весьма озадачен таким подход... текст свёрнут, показать
     
  • 7.49, Cobold (??), 17:39, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых местах водятся очень даже культурные клиенты которые готовы доплатить небольшой бонус за качество чтобы потом не потерять бóльшие деньги
     
     
  • 8.50, thirteensmay (?), 18:04, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    это всеже не мэйнстрим, в основном то ПО впаривается, посмотрите на туже винду и... текст свёрнут, показать
     
  • 2.9, Deffic (?), 02:51, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    "..смешивание html-кода и программной логики.."
    Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?


     
     
  • 3.10, Ян Злобин (?), 03:34, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >"..смешивание html-кода и программной логики.."
    >Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?

    Ну ведь действительно так и есть.  Смешивание неправильно по сути.

     
     
  • 4.13, Deffic (?), 03:50, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>"..смешивание html-кода и программной логики.."
    >>Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
    >
    >Ну ведь действительно так и есть.  Смешивание неправильно по сути.

    Неправильно - смешивание данных и кода.
    А смешивание кода и кода - это вопрос вкуса.

     
     
  • 5.15, polymorphm1 (ok), 04:06, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Неправильно - смешивание данных и кода.
    > А смешивание кода и кода - это вопрос вкуса.

    код коду рознь...

    txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером -- в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно какую), где дожен перейти на следущую строчку, где поставить пробел, или серию пробелов (\t)...

    html-код -- чуть сложнее txt-кода ..

    ...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...

     
     
  • 6.16, Deffic (?), 04:35, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Неправильно - смешивание данных и кода.
    >> А смешивание кода и кода - это вопрос вкуса.
    >
    >код коду рознь...
    >
    >txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером --
    >в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно
    >какую), где дожен перейти на следущую строчку, где поставить пробел, или
    >серию пробелов (\t)...

    Текстовый файл не содержит инструкций, которые нужно выполнить (в идеале).
    (\t \n и др. это не код, а просто невидимые символы)

    >
    >html-код -- чуть сложнее txt-кода ..

    Дело не в сложности.

    >
    >...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять
    >от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ
    >кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...
    >

    IMHO это не нужно рассматривать как правило.
    В некоторых случаях проще и эффективнее вставить html в лигику.
    Очень, ОЧЕНЬ зависит от задач проекта.

     
     
  • 7.17, Аноним (-), 09:30, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > \t \n и др. это не код, а просто невидимые символы

    http://ru.wikipedia.org/wiki/Управляющий_символ

    сюрприз? :)

     
     
  • 8.24, Deffic (?), 11:25, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Специалисты меня порвали ... текст свёрнут, показать
     
  • 7.20, XoRe (ok), 10:26, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >IMHO это не нужно рассматривать как правило.
    >В некоторых случаях проще и эффективнее вставить html в лигику.
    >Очень, ОЧЕНЬ зависит от задач проекта.

    Ваше imho нам понятно)
    В качестве точки зрения могу указать на темы (skins), шаблоны (templates).
    При разделении выполняемой и показываемой частей, впендюрить новый шаблон или новую тему куда проще.
    А при смешивании - это такой гемморой...
    Для примера могу указать на скрипты для web-магазина oscommerce.
    Там изначально все в перемешку.
    И поменять скин там - задачка ещё та.

    Так же при этом разделении куда проще сделать переход на другой язык программирования (или на более новую версию текущего языка).

     
     
  • 8.32, thirteensmay (?), 12:42, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Есть мнение что впендюривание новых шаблонов и тем - туфта гламурных домохозяек,... текст свёрнут, показать
     
  • 3.23, Tav (ok), 11:00, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это противоречит архитектурному шаблону Model–View–Controller, затрудняет модификацию кода и контроль его корректности.
     
     
  • 4.27, Cobold (??), 12:03, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а сколько господ даже здесь рассуждают о языке без намёка на MVC в своих текстах?
     
     
  • 5.30, Deffic (?), 12:23, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >а сколько господ даже здесь рассуждают о языке без намёка на MVC
    >в своих текстах?

    MVC никто не отменял.

     
     
  • 6.33, thirteensmay (?), 12:51, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    НеMVC тоже ;)


     
     
  • 7.34, Deffic (?), 12:57, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >НеMVC тоже ;)

    Согласен.
    Фанатизм - Зло!

     
  • 6.40, Cobold (??), 14:29, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > MVC никто не отменял.

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

     
     
  • 7.74, AlexAT (ok), 13:50, 12/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> MVC никто не отменял.
    >
    >я скорее о том что очень многие php программисты или о нём
    >совсем не знают, или не понимают зачем он им нужен (или
    >не нужен). В большинстве дискуссий это заметно.

    А вы даже для HelloWorld готовы юзать MVC?

     
  • 2.14, polymorphm1 (ok), 03:57, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка PHP ...

    это верно... причём код на PHP можно писать довольно надёжно, но выглядеть такой код будет ГРАМОЗДКО и НЕВЫНОСИМО...

    вот например такой пример:

    <?php

    $name_arg = stripslashes($_GET['name']);

    echo
    '<а href="'.htmlspecialchars(
    $_SERVER['SCRIPT_NAME'].'?profile='.urlencode($name_arg)
    ).'">'.
    htmlspecialchars('Перейти к профелю: '.$name_arg).
    '</а>';

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

    ...становиться понятным что новечку в web (кто только изучает web и PHP) -- кажется что чтобы вывести ссылку нужно всеголишь написать:

    <?php

    echo
    '<а href="'.$_SERVER['SCRIPT_NAME'].'?profile='.$_GET['name'].'">'.
    'Перейти к профелю: '.$_GET['name'].
    '</а>';


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

     
     
  • 3.21, XoRe (ok), 10:34, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >
    >$name_arg = stripslashes($_GET['name']);
    >
    >echo
    > '<а href="'.htmlspecialchars(
    >   $_SERVER['SCRIPT_NAME'].'?profile='.urlencode($name_arg)
    > ).'">'.
    >  htmlspecialchars('Перейти к профелю: '.$name_arg).
    > '</а>';
    >

    <?php
    $name_arg = stripslashes($_GET['name']);
    $href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
    $prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
    echo '<а href="' . $href . '">' . $prof .  '</а>';
    ?>

    не?

     
     
  • 4.25, Deffic (?), 11:47, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>
    >
    ><?php
    >$name_arg = stripslashes($_GET['name']);
    >$href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
    >$prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
    >echo '<а href="' . $href . '">' . $prof .  '</а>';
    >?>
    >
    >не?

    Смешиваем код с html? ))

     
  • 4.62, polymorphm1 (ok), 03:20, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >
    > <?php
    > $name_arg = stripslashes($_GET['name']);
    > $href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
    > $prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
    > echo '<а href="' . $href . '">' . $prof .  '</а>';
    > ?>
    >
    >не?

    не! потомучто смотрите как вы называете свои переменные!

    $href -- это например "http://www.example.ru/?mode=war&level=danger&page=3"

    а после операции htmlspecialchars(...) это уже совсем не $href получается... а чорт-че-чо, которое ужн НЕЛЬЗЯ использовать нигде ниже в программе, кроме как один раз вставить в HTML-код...

    ...изза таких неправильно названных переменных (а потом РАЗУМЕЕТСЯ их неправильного оиспользования) -- как раз и возникают в PHP-сайтах -- АД-КОВЫЧГ (quote-hell) и различный "e;-и-&-мусор

     

  • 1.11, polymorphm1 (ok), 03:35, 18/02/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    больше всего нанавижу что люди (разработчики функциональных web-страниц) -- недооценивают возможность Cross-Site Request Forgery (CSRF) при разработке своих страничек ...

    ..каждые 9/10 сайтов подвержены "межсайтовой подмене запроса" , и ПОДСТАВЛЕНЫМИ таким образом оказываются ПОЛЬЗОВАТЕЛИ таких сайтов .

    ...например напишут от твоего имени сообщение на форуме opennet.ru оскорбительного содержания, а ты потом доказывай кому хочешь что просто-навсего opennet.ru не проверяет испочник (HTTP_REFERER) POST-запроса , а следовательно запрос мог быть присланным с ЛЮБОГО другого подставного сайта, но с использованием МОИХ Cookie и моего ip :-( ...

    # p.s.: про Opennet -- сказал чисто гипотетически . на самом деле может он и проверяет HTTP_REFERER при принятии POST запроса , этого я не проверял ещё покачто :-)

    # p.p.s.:
    хорошо хоть "window.XMLHttpRequest" [при использовании XML или JOSN] уже ПОУМОЛЧАНИЮ ЗАЩИЩЁН от CSRF , и web-разработчику не нужно прилогать дополнительные усилия для фильтрования запросов в зависимости от источника (а можно лишь наоборот приложить дополнительные усилия -- чтобы создать дыру в безопасности :-) , но так делать врядли кто захочет ) .
    ...
    ...в отличии от статических HTML POST "<form ...></form>" , где если не написать дополнительной строчки кода [проверяющщей HTTP_REFERER] -- то ДЫРА СУЩЕСТВУЕТ какбы ПОУМОЛЧАНИЮ...

     
     
  • 2.28, thirteensmay (?), 12:15, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А чем перехват и подмена кук и ip отличается от подмены HTTP_REFERER ?
     
     
  • 3.31, Аноним (-), 12:35, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    От подмены IP защитит протокол TCP/IP. (если вы не внедрились в канал связи)
    Перехват кук так же не возможен при тех же условиях. (нужно хотя бы чтение канала связи)

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

     
     
  • 4.36, thirteensmay (?), 13:31, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ? И для этого даже не придется прослушивать канал связи ?
     
     
  • 5.46, Аноним (-), 16:36, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ?

    Нет. Или это дыра в браузере. Может быть запрос любой страницы или любого действия на странице другого сайта. Вполне штатная функция. Блокируется лишь там где это явно необходимо.

    >И для этого даже не придется прослушивать канал связи ?

    Да. Не придется.

     
     
  • 6.48, thirteensmay (?), 17:36, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Какая дыра в браузере ? Запрос отправляется не из браузера а с сайта злоумышленника. Я не понимаю почему человек считает что если у него перехватили куку то он сможет защититься реферером, он же в плане безопасности по сравнению с куками сопля полная, светиться всем.
     
     
  • 7.53, Аноним (-), 19:04, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Запрос отправляется не из браузера а с сайта злоумышленника.

    Нет. Из браузера. Referer: сайт злоумышленника.
    Куку не перехватили. Всё работает и отправляется стандартно.

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

     
     
  • 8.54, thirteensmay (?), 19:33, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Цитирую Referer может подменить клиент, все правильно, но не клиент обычного по... текст свёрнут, показать
     
     
  • 9.55, Аноним (-), 19:57, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужен Засветит откуда пришёл Злосайту это не важно Referer может подменить... текст свёрнут, показать
     
     
  • 10.56, thirteensmay (?), 20:44, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    За тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным рефере... текст свёрнут, показать
     
     
  • 11.57, Аноним (-), 21:17, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Отправлять запрос злосайт не будет Он показывает страницу Реферер формируется ... текст свёрнут, показать
     
     
  • 12.58, thirteensmay (?), 21:39, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да злосайт сайтом называется только ради красоты, обычная машинка с доступом к с... текст свёрнут, показать
     
     
  • 13.59, Аноним (-), 22:13, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет Ради определённости Нужны термины для ведения дискуссии Да Нет И то и д... текст свёрнут, показать
     
     
  • 14.60, thirteensmay (?), 22:32, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ооо кажись понял, автор имел ввиду использование его кук в рамках понятия CSRF... текст свёрнут, показать
     
     
  • 15.61, Аноним (-), 22:40, 18/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да ... текст свёрнут, показать
     
  • 15.63, polymorphm1 (ok), 03:37, 20/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    да так - давно меня небыло на этом обсуждении, извеняюсь - просто когда я ... текст свёрнут, показать
     

  • 1.37, luzers (?), 14:14, 18/02/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Распечатать и большим плакатом в программерских развесить.
    для альтернативноодаренных - заставлять зубрить.
    потом спросить за отче наш, гимн СССР и гимн России)
     
  • 1.75, gHg (?), 09:15, 04/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    админам составьте пожалуйста ПОЛНЫЙ список из инета, обязательно по категорям (языки, назначение программ/алгоритмов,....).
    + >"Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде"
    - полуказанно, так даже шифруя их - они могут быть взломаны, или тупо проданы персоналом или владельцем.
    ----
    + использование скриптов - как формы backdoor под видом ошибок транслятора/JIT или библиотек, тем более если могут выполнять себя динамически(без компиляции/трансляции) вроде интернетовских
     

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



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

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