Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Рейтинг самых опасных ошибок, зафиксированных в 2009 году, opennews (?), 17-Фев-10, (0) [смотреть все] Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-, Zenitur (?), 23:13 , 17-Фев-10, (1) –4 // Угу А установка SElinux делает Windows намного безопаснее Там немалая часть уязв, XoRe (ok), 23:22 , 17-Фев-10, (2) // Вы забыли про сотни обновлений для IE, WMP и NET Достаточно окинуть взглядом с, Zenitur (?), 00:56 , 18-Фев-10, (5) –2 // С этим я не спорю Я просто хочу указать ваше внимание, что все эти уязвимости не, XoRe (ok), 10:08 , 18-Фев-10, (18) И какие сотни обновлений была для поддерживаемых на сегодня ОС MS В 2009 году V, Трухин_Юрий_Владимирович (ok), 12:19 , 20-Фев-10, (64) Вы тогда либо в поиске только ядро Linux выбирайте с минимальными GUI, либо все , Аноним (-), 20:18 , 20-Фев-10, (65) Только по ядру Linux 38 уязвимостей только в ядре за 2009 год Это без всяк, Трухин_Юрий_Владимирович (ok), 22:09 , 20-Фев-10, (67) Посмотрите на усердно вами цитируемом secunia степень опасности этих уязвимостей, Глеб В (?), 23:49 , 20-Фев-10, (70) +1 28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр в we, Глеб В (?), 20:22 , 20-Фев-10, (66) какие веб-приложения в настольных системах читайте внимательно, Трухин_Юрий_Владимирович (ok), 22:10 , 20-Фев-10, (68) это все я пишу в ответ на заявления человека о многих сотнях дыр в виндах в 2009, Трухин_Юрий_Владимирович (ok), 22:11 , 20-Фев-10, (69) Вы ссылались на статистику по числу дыр в Red Hat, а не только в настольных прил, Глеб В (?), 23:52 , 20-Фев-10, (71) Часть из этих ошибок 8212 причина порочной практики программирования, которая, Tav (ok), 23:39 , 17-Фев-10, (3) +6   // хорошо сказано , Cobold (??), 00:51 , 18-Фев-10, (4)   // А Oracle не хочет приобрести php , vbv (ok), 02:49 , 18-Фев-10, (8)   которая связанна с использованием непоследовательного и непродуманного языка , Deffic (?), 02:48 , 18-Фев-10, (7) +1   // самая больная проблема в PHP -- это mod_php , который ПООЩРЯЕТ помещщение и вып, polymorphm1 (ok), 03:40 , 18-Фев-10, (12) +1   Проблема не в SQL Все нормальные API для работы с SQL работают так запрос с па, Tav (ok), 10:42 , 18-Фев-10, (22)   // эта норма пришла скорее от mysql, потому что там изначально небыло компиляции за, Cobold (??), 11:50 , 18-Фев-10, (26)   А если логика запроса посложнее и состоит из 100 вложений инъекций и поведени, Deffic (?), 12:19 , 18-Фев-10, (29)   Это значит, что вам следует пересмотреть модель данных Если подобные запросы вс, Tav (ok), 14:22 , 18-Фев-10, (38)   Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запро, thirteensmay (?), 13:25 , 18-Фев-10, (35)   Имя таблицы 8212 это данные пришедшие из вне Если такое часто нужно, у вас к, Tav (ok), 14:27 , 18-Фев-10, (39)   Нет никаких проблем с моделью данных, есть необходимость динамического построени, thirteensmay (?), 14:50 , 18-Фев-10, (41)   Это все-таки не обычное использование БД, исключение, а не норма Речь о том, чт, Tav (ok), 15:34 , 18-Фев-10, (43) +1   Вот с этим не могу не согласится Моя же речь про то что эти исключительные случ, thirteensmay (?), 16:03 , 18-Фев-10, (45)   Позвольте не согласиться - это как раз НОРМА Если у Вас база нормализована, то п, Deffic (?), 18:25 , 18-Фев-10, (51)   Ошибаетесь Это давно уже норма Время, когда все можно было сделать запросами в, AlexAT (ok), 13:47 , 12-Май-10, (73)   А вот смотрите, не в защиту перла а просто как сравнение на перле с базой работ, Cobold (??), 14:57 , 18-Фев-10, (42)   И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполня, thirteensmay (?), 15:40 , 18-Фев-10, (44)   я не о том что на перле это невозможно, я о том что там в отличии от php при раб, Cobold (??), 17:29 , 18-Фев-10, (47)   а я вам про то что я например, при освоении DBI был весьма озадачен таким подход, thirteensmay (?), 18:35 , 18-Фев-10, (52)   а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых м, Cobold (??), 17:39 , 18-Фев-10, (49)   это всеже не мэйнстрим, в основном то ПО впаривается, посмотрите на туже винду и, thirteensmay (?), 18:04 , 18-Фев-10, (50)   смешивание html-кода и программной логики Можете это хот как-то обосновать,, Deffic (?), 02:51 , 18-Фев-10, (9)   // Ну ведь действительно так и есть Смешивание неправильно по сути , Ян Злобин (?), 03:34 , 18-Фев-10, (10) +1   // Неправильно - смешивание данных и кода А смешивание кода и кода - это вопрос вку, Deffic (?), 03:50 , 18-Фев-10, (13) –2   код коду рознь txt-файл это тоже своего рода КОД программа например при печа, polymorphm1 (ok), 04:06 , 18-Фев-10, (15) +3   Текстовый файл не содержит инструкций, которые нужно выполнить в идеале t n, Deffic (?), 04:35 , 18-Фев-10, (16) –1   http ru wikipedia org wiki Управляющий_символсюрприз , Аноним (-), 09:30 , 18-Фев-10, (17) +1   Специалисты меня порвали , Deffic (?), 11:25 , 18-Фев-10, (24)   Ваше imho нам понятно В качестве точки зрения могу указать на темы skins , шабл, XoRe (ok), 10:26 , 18-Фев-10, (20)   Есть мнение что впендюривание новых шаблонов и тем - туфта гламурных домохозяек,, thirteensmay (?), 12:42 , 18-Фев-10, (32) –2   Это противоречит архитектурному шаблону Model 8211 View 8211 Controller, затру, Tav (ok), 11:00 , 18-Фев-10, (23)   // а сколько господ даже здесь рассуждают о языке без намёка на MVC в своих текстах, Cobold (??), 12:03 , 18-Фев-10, (27)   MVC никто не отменял , Deffic (?), 12:23 , 18-Фев-10, (30)   НеMVC тоже , thirteensmay (?), 12:51 , 18-Фев-10, (33)   Согласен Фанатизм - Зло , Deffic (?), 12:57 , 18-Фев-10, (34)   я скорее о том что очень многие php программисты или о нём совсем не знают, или , Cobold (??), 14:29 , 18-Фев-10, (40)   А вы даже для HelloWorld готовы юзать MVC , AlexAT (ok), 13:50 , 12-Май-10, (74)   это верно причём код на PHP можно писать довольно надёжно, но выглядеть такой, polymorphm1 (ok), 03:57 , 18-Фев-10, (14) +1   // gt оверквотинг удален php name_arg stripslashes _GET name href htm, XoRe (ok), 10:34 , 18-Фев-10, (21)   // gt оверквотинг удален Смешиваем код с html , Deffic (?), 11:47 , 18-Фев-10, (25)   не потомучто смотрите как вы называете свои переменные href -- это например h, polymorphm1 (ok), 03:20 , 20-Фев-10, (62)   больше всего нанавижу что люди разработчики функциональных web-страниц -- недо, polymorphm1 (ok), 03:35 , 18-Фев-10, (11) // А чем перехват и подмена кук и ip отличается от подмены HTTP_REFERER , thirteensmay (?), 12:15 , 18-Фев-10, (28) // От подмены IP защитит протокол TCP IP если вы не внедрились в канал связи Пере, Аноним (-), 12:35 , 18-Фев-10, (31) // В т ч может быть сформирован запрос с необходимым HTTP_REFERER И для этого да, thirteensmay (?), 13:31 , 18-Фев-10, (36) Нет Или это дыра в браузере Может быть запрос любой страницы или любого действ, Аноним (-), 16:36 , 18-Фев-10, (46) Какая дыра в браузере Запрос отправляется не из браузера а с сайта злоумышленн, thirteensmay (?), 17:36 , 18-Фев-10, (48) Нет Из браузера Referer сайт злоумышленника Куку не перехватили Всё работает, Аноним (-), 19:04 , 18-Фев-10, (53) Цитирую Referer может подменить клиент, все правильно, но не клиент обычного пол, thirteensmay (?), 19:33 , 18-Фев-10, (54) Не нужен Засветит откуда пришёл Злосайту это не важно Referer может подменить к, Аноним (-), 19:57 , 18-Фев-10, (55) За тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным рефере, thirteensmay (?), 20:44 , 18-Фев-10, (56) Отправлять запрос злосайт не будет Он показывает страницу Реферер формируется б, Аноним (-), 21:17 , 18-Фев-10, (57) Да злосайт сайтом называется только ради красоты, обычная машинка с доступом к с, thirteensmay (?), 21:39 , 18-Фев-10, (58) Нет Ради определённости Нужны термины для ведения дискуссии Да Нет И то и друг, Аноним (-), 22:13 , 18-Фев-10, (59) Ооо кажись понял, автор имел ввиду использование его кук в рамках понятия CSRF, thirteensmay (?), 22:32 , 18-Фев-10, (60) –1 Да , Аноним (-), 22:40 , 18-Фев-10, (61) да так - давно меня небыло на этом обсуждении, извеняюсь - просто когда я го, polymorphm1 (ok), 03:37 , 20-Фев-10, (63) Распечатать и большим плакатом в программерских развесить для альтернативноодаре, luzers (?), 14:14 , 18-Фев-10, (37) админам составьте пожалуйста ПОЛНЫЙ список из инета, обязательно по категорям я, gHg (?), 09:15 , 04-Июл-11, (75) 1,3,11,37,75

Сообщения

[Сортировка по времени | RSS]

3. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+6 +/–
Сообщение от Tav (ok), 17-Фев-10, 23:39
Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка PHP: построение SQL-запросов путем конкатенации, смешивание html-кода и программной логики, скрипты и файлы с данными вперемешку, изначальное отсутствие пространств имен, "magic quotes hell" (убрали, но каким местом раньше думали), register_globals (понятно, что обычно выключено, но как вообще можно было в здравом уме до такого додуматься).
Ответить | Правка | Наверх | Cообщить модератору

	4. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 00:51
	хорошо сказано :)
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от vbv (ok), 18-Фев-10, 02:49
	А Oracle не хочет приобрести php???
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от Deffic (?), 18-Фев-10, 02:48
	"..которая связанна с использованием непоследовательного и непродуманного языка PHP.." Если в Вашем тексте PHP заменить на SQL, то смысл не измениться. Всякие там иньекции и т.п. Но на SQL ни кто не гонит. На PHP есть масса очень грамотных проектов. Возможно, всё-таки проблема с руками.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	12. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от polymorphm1 (ok), 18-Фев-10, 03:40
	самая больная проблема в PHP -- это mod_php , который ПООЩРЯЕТ помещщение (и выполнение) php-файлов в тойже самой директории что и статические media-файлы..
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 10:42
	Проблема не в SQL. Все нормальные API для работы с SQL работают так: запрос с параметрами (например "SELECT * FROM table WHERE id = ?") сначала компилируется, а значения параметров подставляются уже при выполнении запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL и делает инъекции невозможными. Для PHP тоже есть такие API, но в PHP построение запросов путем подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные функции предполагают именно такой способ.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	26. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 11:50
	эта норма пришла скорее от mysql, потому что там изначально небыло компиляции запросов, и любая прослойка позволявшая пользоваться переменными по сути ничего кроме конкатенации не делала. А ещё php во все времена имел очень низенькую планочку для IQ разработчика, поэтому им пользуются столько людей которые даже слова "фреймворк" не знают. В принципе, как windows - своей убогостью создал себе огромный рынок.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 12:19
	>Проблема не в SQL. Все нормальные API для работы с SQL работают >так: запрос с параметрами (например "SELECT * FROM table WHERE id >= ?") сначала компилируется, а значения параметров подставляются уже при выполнении >запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL >и делает инъекции невозможными. А если логика запроса посложнее и состоит из 100 вложений ("инъекций") и поведение следующего вложения завязано на результате предыдущего (или нескольких)? Пелёнки всё вырежут? > >Для PHP тоже есть такие API, но в PHP построение запросов путем >подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные >функции предполагают именно такой способ. Разговор был о языках а не о API. При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются в бомбу.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	38. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 14:22
	>А если логика запроса посложнее и состоит из 100 вложений ("инъекций") >и поведение следующего вложения завязано на результате предыдущего (или нескольких)? Это значит, что вам следует пересмотреть модель данных. Если подобные запросы все-таки необходимы в порядке исключения, то и строить их придется аккуратно другим способом, на то оно и исключение. Нормой это быть не может. >Разговор был о языках а не о API. Вместе с языком предоставляется стандартный API. >При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются >в бомбу. Как будто не бывает плохих языков программирования. Понятно, что можно писать надежный код даже на PHP. Проблема в том, что PHP провоцирует порочную практику программирования, как я уже писал выше. Это как Бейсик: студенты изучавшие его, по словам Дейкстры, "подверглись необратимой умственной деградации".
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 13:25
	>Проблема не в SQL. Все нормальные API для работы с SQL работают >так: запрос с параметрами (например "SELECT * FROM table WHERE id >= ?") сначала компилируется, а значения параметров подставляются уже при выполнении >запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL >и делает инъекции невозможными. > >Для PHP тоже есть такие API, но в PHP построение запросов путем >подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные >функции предполагают именно такой способ. Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно. Проблема безопасности заключается в первую очередь не в языках или технологиях, а в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во, специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	39. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 14:27
	> Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно. Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных. > Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости. Говорит, как минимум, о разгильдяйстве.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 14:50
	> Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных. Нет никаких проблем с моделью данных, есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Кроме разных таблиц там еще куча динамически изменяющихся условий, т.е. and, or, between, case и т.п., ну не реализуется такое плейсхолдерами никак, и модель тут не причем. > Говорит, как минимум, о разгильдяйстве. В некотором плане говорит, не спорю, но смотрите на мир реально, у меня срок реализации фичи - неделя, да я за это время еле-еле только самую основу успею, ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от Tav (ok), 18-Фев-10, 15:34
	> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Это все-таки не обычное использование БД, исключение, а не норма. Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев. > ни о каком всестороннем анализе безопасности речи сами понимаете быть не может. Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли все сложно?
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 16:03
	>  Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев Вот с этим не могу не согласится. Моя же речь про то что эти исключительные случае весьма бывают, тут один, там другой, вот уже и набралось, приложения нонче весьма не маленькие, особенно если умник какой попадется, ООП, MVC, ORM и пр. на ровном месте городить начнет, вообще туши свет > веб-приложение, так ли все сложно? Не только web. А вообще ведь дело не в том что сложно, а в том что сложнее
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 18:25
	>> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. > >Это все-таки не обычное использование БД, исключение, а не норма. Речь о >том, что использование запросов с параметрами — норма, а манипуляции со >строками — для исключительных случаев. > >> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может. > >Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли >все сложно? Позвольте не согласиться - это как раз НОРМА. Если у Вас база нормализована, то по другому просто не сделать (или у Вас всё в одной таблице?). Не, ну конечно можно сделать кучу запросов к разным таблицам, потом переварить это перлом или пхп и сделать ещё кучу запросов, и ещё, и ещё... А можно просто написать сложный SELECT и предоставить базе оптимизировать этот SELECT.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	73. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от AlexAT (ok), 12-Май-10, 13:47
	>> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. > >Это все-таки не обычное использование БД, исключение, а не норма. Речь о >том, что использование запросов с параметрами — норма, а манипуляции со >строками — для исключительных случаев. > >> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может. > >Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли >все сложно? Ошибаетесь. Это давно уже норма. Время, когда все можно было сделать запросами вида SELECT * FROM x WHERE y - прошло. Множество запросов строится "на лету", исходя из разношерстных пожеланий пользователя.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	42. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 14:57
	>Проблема безопасности заключается в первую очередь не в языках или технологиях, а >в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во, >специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость >тоже конечно имеет место быть, но вот я лично прекрасно знаю >кучу уязвимостей в своих поделках, но не исправляю их ибо не >до того, не интересно, есть др. задачи, лень, за это не >заплатят, и т.п. что в общем то заметьте не говорит о >моей криворукости. А вот смотрите, не в защиту перла а просто как сравнение: на перле с базой работают через DBI, весь её интерфейс и документация изначально подразумевают компиляцию запросов и исполльзование переменных, и никому не приходится тратить какие-то дополнительные усилия чтобы узнать как работать с ней безопасно (разве что этот кто-то из php пришёл). Почему? - потому что перл не имеет нативных функций для sql , там изначально работают с фреймворками и к этому привыкли, а этот фреймворк был написан не как api wrapper для mysql а как универсальный инструмент для профессиональной работы с базами. И что получается? PHP для той-же самой функциональности требует от разработчика более низкого интеллекта чем перл, в результате новичёк работая с перлом подтянется, а хороший специалист работая с php расслабится и будет писать плохой код, потому что "и так работает". При том что качественный код каких-то дополнительных трудозатрат особо и не требует, это только следствие определённой культуры. Культурному человеку ведь не приходится тратить время чтобы им оставаться?
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	44. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 15:40
	И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполнять, тыщу раз такое видел и сам делал, говорю вам не в инструменте дело, точнее не в первую очередь в инструменте. Качественный продукт к сожалению таки требует дополнительных трудозатрат. А вот про культуру вы хорошо заметили, все прекрасно, но это только в идеальном сферическом мире, а на практике все под елочку ходят когда приспичит. Если тему развивать я вам даже больше скажу, проблема безопасности через деньги вытекает вообще к нашему социально-экономическому строю, с одной стороны производителям зачастую не особо выгодно производить высококачественный продукт, с другой - нанимать на его реализацию "культурных" исполнителей, ибо качество дорого, а культура капризна. Основной принцип - руби бабло, промышленный подход, так что качество (безопасность) второстепенны, если конечно вы не рубите бабло на безопасности ;)
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 17:29
	я не о том что на перле это невозможно, я о том что там в отличии от php при работе с базой наиболее лёгкий и удобный способ одновременно является и более безопасным, и при этом приучает делать более качественный код. Может быть в этом главная слабость php - он реализует очень много функциональности на уровне языка вместо того чтобы стимулировать развитие более качественных фреймворков, а все эти стандартные расширения практически монополизируют свою функцию, какому-то конкурирующему решению очень сложно пробиться. P.S. ещё раз, я здесь имею в виду только DBI и отдельные особенности перла, не говорю про весь язык и всё что на нём написанно.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 18:35
	а я вам про то что я например, при освоении DBI был весьма озадачен таким подходом, особенно когда узнал что mysql не поддерживал хранимых запросов, и в результате чтобы не выписывать каждый раз такие кренделя написал функцию execute_query() в которую передавал динамически собираемую строку запроса. Даже если бы mysql поддерживал то всеравно бы написал, ибо в результате проще, кода меньше, на тот момент я был таков, писал кода в день в три раза больше чем сейчас и просил за это крохи, а теперь что, пока доку три раза прочтешь, пока подумаешь, спланируешь, ошибки обработаешь и т.п. пацан молодой какой нить уже 10 раз все сделает за в три раза меньшие деньги, вот и подумайте кого выберет современный массовый работодатель производитель всякого ширпотреба ? Незнаю, возможно я и не прав, можете убеждать меня дальше, но считаю что инструменты тут дело далеко десятое.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 17:39
	а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых местах водятся очень даже культурные клиенты которые готовы доплатить небольшой бонус за качество чтобы потом не потерять бóльшие деньги
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	50. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 18:04
	это всеже не мэйнстрим, в основном то ПО впаривается, посмотрите на туже винду или офис, куча красочных перделок, мало кому нужных и зачастую даже бесплатных.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 02:51
	"..смешивание html-кода и программной логики.." Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	10. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от Ян Злобин (?), 18-Фев-10, 03:34
	>"..смешивание html-кода и программной логики.." >Можете это хот как-то обосновать, кроме того, что так удобнее для CMS? Ну ведь действительно так и есть.  Смешивание неправильно по сути.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	–2 +/–
	Сообщение от Deffic (?), 18-Фев-10, 03:50
	>>"..смешивание html-кода и программной логики.." >>Можете это хот как-то обосновать, кроме того, что так удобнее для CMS? > >Ну ведь действительно так и есть.  Смешивание неправильно по сути. Неправильно - смешивание данных и кода. А смешивание кода и кода - это вопрос вкуса.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+3 +/–
	Сообщение от polymorphm1 (ok), 18-Фев-10, 04:06
	> Неправильно - смешивание данных и кода. > А смешивание кода и кода - это вопрос вкуса. код коду рознь... txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером -- в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно какую), где дожен перейти на следущую строчку, где поставить пробел, или серию пробелов (\t)... html-код -- чуть сложнее txt-кода .. ...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	–1 +/–
	Сообщение от Deffic (?), 18-Фев-10, 04:35
	>> Неправильно - смешивание данных и кода. >> А смешивание кода и кода - это вопрос вкуса. > >код коду рознь... > >txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером -- >в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно >какую), где дожен перейти на следущую строчку, где поставить пробел, или >серию пробелов (\t)... Текстовый файл не содержит инструкций, которые нужно выполнить (в идеале). (\t \n и др. это не код, а просто невидимые символы) > >html-код -- чуть сложнее txt-кода .. Дело не в сложности. > >...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять >от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ >кодом (html?) , как и "поведение" и "модель" тоже задаются кодами... > IMHO это не нужно рассматривать как правило. В некоторых случаях проще и эффективнее вставить html в лигику. Очень, ОЧЕНЬ зависит от задач проекта.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от Аноним (-), 18-Фев-10, 09:30
	> \t \n и др. это не код, а просто невидимые символы http://ru.wikipedia.org/wiki/Управляющий_символ сюрприз? :)
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 11:25
	>> \t \n и др. это не код, а просто невидимые символы > >http://ru.wikipedia.org/wiki/Управляющий_символ > >сюрприз? :) Специалисты меня порвали. ))
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от XoRe (ok), 18-Фев-10, 10:26
	>IMHO это не нужно рассматривать как правило. >В некоторых случаях проще и эффективнее вставить html в лигику. >Очень, ОЧЕНЬ зависит от задач проекта. Ваше imho нам понятно) В качестве точки зрения могу указать на темы (skins), шаблоны (templates). При разделении выполняемой и показываемой частей, впендюрить новый шаблон или новую тему куда проще. А при смешивании - это такой гемморой... Для примера могу указать на скрипты для web-магазина oscommerce. Там изначально все в перемешку. И поменять скин там - задачка ещё та. Так же при этом разделении куда проще сделать переход на другой язык программирования (или на более новую версию текущего языка).
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	32. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	–2 +/–
	Сообщение от thirteensmay (?), 18-Фев-10, 12:42
	Есть мнение что впендюривание новых шаблонов и тем - туфта гламурных домохозяек, плюсы конечно есть, но это не общеупотребимо, а вот сложность при этом увеличивается, само понятие шаблона, их язык, производительность опять таки. А чем сложнее система тем больше в ней уязвимостей ;) Нет, я не хочу сказать что рассматриваемый подход зло, всему свое место, зачастую простейший вариант с формированием ответа в одном скрипте оптимален, как уже сказали выше все зависит от задачи.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 11:00
	Это противоречит архитектурному шаблону Model–View–Controller, затрудняет модификацию кода и контроль его корректности.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	27. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 12:03
	а сколько господ даже здесь рассуждают о языке без намёка на MVC в своих текстах?
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 12:23
	>а сколько господ даже здесь рассуждают о языке без намёка на MVC >в своих текстах? MVC никто не отменял.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 12:51
	НеMVC тоже ;)
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 12:57
	>НеMVC тоже ;) Согласен. Фанатизм - Зло!
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 14:29
	> MVC никто не отменял. я скорее о том что очень многие php программисты или о нём совсем не знают, или не понимают зачем он им нужен (или не нужен). В большинстве дискуссий это заметно.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	74. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от AlexAT (ok), 12-Май-10, 13:50
	>> MVC никто не отменял. > >я скорее о том что очень многие php программисты или о нём >совсем не знают, или не понимают зачем он им нужен (или >не нужен). В большинстве дискуссий это заметно. А вы даже для HelloWorld готовы юзать MVC?
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от polymorphm1 (ok), 18-Фев-10, 03:57
	> Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка 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 | Наверх | Cообщить модератору

	21. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от XoRe (ok), 18-Фев-10, 10:34
	>[оверквотинг удален] > >$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 .  '</а>'; ?> не?
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 11:47
	>[оверквотинг удален] >> > ><?php >$name_arg = stripslashes($_GET['name']); >$href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg)); >$prof = htmlspecialchars('Перейти к профилю: ' . $name_arg); >echo '<а href="' . $href . '">' . $prof .  '</а>'; >?> > >не? Смешиваем код с html? ))
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от polymorphm1 (ok), 20-Фев-10, 03:20
	> > <?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;-и-&-мусор
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема