форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
Сообщение от opennews on 17-Фев-10, 23:13
Институт SANS (SysAdmin, Audit, Network, Security), совместно с организацией MITRE и ведущими экспертами по компьютерной безопасности, подготовил (http://cwe.mitre.org/top25/) новую редакцию рейтинга 25 самых опасных ошибок, приводящих к возникновению серьезных уязвимостей. Ошибки были отобраны с учетом их распространенности, трудоемкости обнаружения и простоты эксплуатации уязвимости. В опубликованном документе подробно разбирается каждый из 25 видов ошибок, приводятся примеры узявимостей и рекомендации для разработчиков по предотвращению появления подобных ошибок. Краткое содержание рейтинга (цифра вначале указывает на место в рейтинге): -   Небезопасное взаимодействие между компонентами , определяет проблемы, вызванные небезопасной отправкой или получением данных между  модулями, программами, процессами, нитями или системами. -  1 (http://cwe.mitre.org/top25/#CWE-79): Неспособность сохранения структуры web-страницы, что позволяет злоумышленнику внедрить на страницу с... URL: http://cwe.mitre.org/top25/ Новость: https://www.opennet.ru/opennews/art.shtml?num=25465
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	–4 +/–
Сообщение от Zenitur on 17-Фев-10, 23:13
Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от XoRe (ok) on 17-Фев-10, 23:22
	>Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7. Угу. А установка SElinux делает Windows намного безопаснее) Там немалая часть уязвимостей относится к безопасности в web. На основании каких данных был сделан вывод о Windows, если не секрет?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	–2 +/–
	Сообщение от Zenitur on 18-Фев-10, 00:56
	Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть от ужаса
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	18. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от XoRe (ok) on 18-Фев-10, 10:08
	>Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть >взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть >от ужаса С этим я не спорю) Я просто хочу указать ваше внимание, что все эти уязвимости не могут быть только на Windows. Так как там куча уязвимостей, относящихся к web (php, sql, алгоритмы обработки форм). Так же куча уязвимостей, относящихся к приемам программирования вообще. Ну и указание на то, что SElinux помогает, как-бы намекает на то, что это не только в Windows)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	64. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Трухин_Юрий_Владимирович (ok) on 20-Фев-10, 12:19
	И какие сотни обновлений была для поддерживаемых на сегодня ОС MS? В 2009 году Vista - 28 уязвимостей http://secunia.com/advisories/product/13223/?task=statistics... Windows 7 - 4 уязвимости! http://secunia.com/advisories/product/27467/?task=statistics... Red Hat Enterprise Linux 5 - 135 уязвимостей! http://secunia.com/advisories/product/13652/?task=statistics...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	65. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 20-Фев-10, 20:18
	>И какие сотни обновлений была для поддерживаемых на сегодня ОС MS? В >2009 году Vista - 28 уязвимостей http://secunia.com/advisories/product/13223/?task=statistics... > >Windows 7 - 4 уязвимости! http://secunia.com/advisories/product/27467/?task=statistics... > >Red Hat Enterprise Linux 5 - 135 уязвимостей! http://secunia.com/advisories/product/13652/?task=statistics... Вы тогда либо в поиске только ядро Linux выбирайте с минимальными GUI, либо все программы для Windows тоже захватите. 135 - это с учетом нескольких десятков тысяч программ в репозитории Red Hat. И еще, 28 уязвимостей для Windows как правило удаленные дыры, конликер еще у всех на устах. Незначительные уязвимости в MS без огласки правят, DoS или локальное повышение привилегий в Windows за уязвимость не считают.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	67. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Трухин_Юрий_Владимирович (ok) on 20-Фев-10, 22:09
	Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год. Это без всяких Xов, графической оболочки и др. А значит - присутствовали во всех! дистрибутивах Linux в 2009 году на ядре 2.6.... http://secunia.com/advisories/product/2719/?task=statistics_...
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	70. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от Глеб В on 20-Фев-10, 23:49
	>Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год. Посмотрите на усердно вами цитируемом secunia степень опасности этих уязвимостей - Less critical или  Not critical. Я ни одной даже со статусом Moderately critical (умеренная опасность) не смог найти. Теперь набираем в поиске http://secunia.com/advisories/search/ Windows и видим только за февраль 9 уязвимостей из которых половина имеет статус     Highly critical. Теперь я понимаю почему вас не любят на этом форуме, вы упорно подтасовывайте факты.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	66. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Глеб В on 20-Фев-10, 20:22
	28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр в web-приложениях это вы мощно сравнили.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	68. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Трухин_Юрий_Владимирович (ok) on 20-Фев-10, 22:10
	>28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр >в web-приложениях это вы мощно сравнили. какие веб-приложения в настольных системах... читайте внимательно
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	69. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Трухин_Юрий_Владимирович (ok) on 20-Фев-10, 22:11
	это все я пишу в ответ на заявления человека о многих сотнях дыр в виндах в 2009 году...
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	71. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Глеб В on 20-Фев-10, 23:52
	>это все я пишу в ответ на заявления человека о многих сотнях >дыр в виндах в 2009 году... Вы ссылались на статистику по числу дыр в Red Hat, а не только в настольных приложениях. То что в Rad Hat и Windows несколько разный объем приложений вас не смутило.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	14. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от polymorphm1 (ok) on 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) on 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 .  '</а>'; ?> не?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	25. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic on 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? ))
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	62. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от polymorphm1 (ok) on 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ообщить модератору

11. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
Сообщение от polymorphm1 (ok) on 18-Фев-10, 03:35
больше всего нанавижу что люди (разработчики функциональных 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] -- то ДЫРА СУЩЕСТВУЕТ какбы ПОУМОЛЧАНИЮ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay on 18-Фев-10, 12:15
	А чем перехват и подмена кук и ip отличается от подмены HTTP_REFERER ?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	31. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 12:35
	От подмены IP защитит протокол TCP/IP. (если вы не внедрились в канал связи) Перехват кук так же не возможен при тех же условиях. (нужно хотя бы чтение канала связи) А для действий от вашего имени на любом сайте, пусть даже защищённом https. Достаточно, чтобы вы перешли по ссылке. А там за вас будет сформирован и отправлен любой запрос, имитирующий любое ваше действие.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	36. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay on 18-Фев-10, 13:31
	В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ? И для этого даже не придется прослушивать канал связи ?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	46. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 16:36
	>В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ? Нет. Или это дыра в браузере. Может быть запрос любой страницы или любого действия на странице другого сайта. Вполне штатная функция. Блокируется лишь там где это явно необходимо. >И для этого даже не придется прослушивать канал связи ? Да. Не придется.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	48. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay on 18-Фев-10, 17:36
	Какая дыра в браузере ? Запрос отправляется не из браузера а с сайта злоумышленника. Я не понимаю почему человек считает что если у него перехватили куку то он сможет защититься реферером, он же в плане безопасности по сравнению с куками сопля полная, светиться всем.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	53. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 19:04
	>Запрос отправляется не из браузера а с сайта злоумышленника. Нет. Из браузера. Referer: сайт злоумышленника. Куку не перехватили. Всё работает и отправляется стандартно. Referer может подменить клиент, но не другой сайт. В плане безопасности проверка Referer необходима, чтобы удостовериться, что клиент сам выполняет действие.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	54. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay on 18-Фев-10, 19:33
	> Куку не перехватили Цитирую: > например напишут от твоего имени сообщение на форуме opennet.ru оскорбительного содержания, а ты потом доказывай кому хочешь что просто-навсего opennet.ru не проверяет испочник (HTTP_REFERER) POST-запроса, а следовательно запрос мог быть присланным с ЛЮБОГО другого подставного сайта, но с использованием МОИХ Cookie и моего ip Referer может подменить клиент, все правильно, но не клиент обычного пользователя а клиент установленный на сайте злоумышленника, когда пользователь попадет на злосайт он засветит там свой referer, да вобщем то его и так легко подставить, мы же знаем какой сайт атакуем, тогда referer ничего не даст, запрос от злоклиента придет с правильным реферером, а вот у честного пользователя он поменяется и его запросы будут отвергнуты. или чего я непонимаю ?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	55. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 19:57
	>клиент установленный на сайте злоумышленника Не нужен. >когда пользователь попадет на злосайт он засветит там свой referer Засветит откуда пришёл. Злосайту это не важно. >да вобщем то его и так легко подставить Referer может подменить клиент, но не другой сайт. >мы же знаем какой сайт атакуем Да. >тогда referer ничего не даст Нет. Даст. Он даст адрес страницы злосайта, на которой пользователю предложили/заставили совершить действие. >запрос от злоклиента придет с правильным реферером Нет. >а вот у честного пользователя он поменяется и его запросы будут отвергнуты. Нет. Пользователь всегда честный. Совершить действие с сайтом ему может предложить сам сайт или злосайт. В первом случае сработает, во втором не сработает. >чего я непонимаю ? Суть.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	56. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay on 18-Фев-10, 20:44
	> Referer может подменить клиент, но не другой сайт > клиент установленный на сайте злоумышленника Не нужен За тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным реферером > запрос от злоклиента придет с НЕ правильным реферером Почему ? мыж его ручками подправим > Реферер даст адрес страницы злосайта, на которой пользователю предложили/заставили совершить действие. Реферер пользователя после посещения злосайта да, но он нас уже не интересует, пользователь отработан, со злосайта из злоклиента уже ушел запрос на атакуемый сайт с "правильными" параметрами > Пользователь всегда честный Да, но его честь можно украсть Какой сути я не понимаю ? что именно не сработает в предложенной схеме ?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	57. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 21:17
	>За тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным реферером Отправлять запрос злосайт не будет. Он показывает страницу. >Почему ? мыж его ручками подправим Реферер формируется браузером пользователя, а не страницей и не скриптом на ней. >Реферер пользователя после посещения злосайта да, но он нас уже не интересует, пользователь отработан, со злосайта из злоклиента уже ушел запрос на атакуемый сайт с "правильными" параметрами Нет. Не имеет смысла. Злосайт не имеет такого же доступа на сайт, как пользователь. >Да, но его честь можно украсть Да. >Какой сути я не понимаю ? Cross-Site Request Forgery (CSRF) >что именно не сработает в предложенной схеме ? Нет доступа к сайту (логина/пароля), неизвестны куки, другой ip.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	58. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay on 18-Фев-10, 21:39
	>Отправлять запрос злосайт не будет. Он показывает страницу. >Реферер формируется браузером пользователя, а не страницей и не скриптом на ней. Да злосайт сайтом называется только ради красоты, обычная машинка с доступом к сети и "специализированными" скриптами, HTTP сервера там может и не быть, главное чтобы он слушал команды злоумышленника и мог формировать произвольные HTTP запросы, это не сложно, ну если уж совсем хочется то можно и HTTP сервер прикрутить и перехватывать рефереры пользователей, но это уже не суть. Вот я и предлагаю чтобы когда надо этот злоклиент отправил запрос с необходимыми параметрами на атакуемый сайт. >Злосайт не имеет такого же доступа на сайт, как пользователь >Нет доступа к сайту (логина/пароля), неизвестны куки, другой ip. В том то и дело что известны, цитирую автора еще раз: >с использованием МОИХ Cookie и моего ip Он предполагает что куки уже перехвачены, а также имеется возможность подставить ip, и после этого предлагает защищаться реферером, а вот этого я уже не понимаю. И вообще, ведь далеко не каждый сайт подразумевает авторизацию (куки) и уж тем более проверку ip.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	59. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 22:13
	>Да злосайт сайтом называется только ради красоты Нет. Ради определённости. Нужны термины для ведения дискуссии. >обычная машинка с доступом к сети и "специализированными" скриптами Да. >HTTP сервера там может и не быть Нет. >главное чтобы он слушал команды злоумышленника и мог формировать произвольные HTTP запросы И то и другое не нужно. >это не сложно Да. >ну если уж совсем хочется то можно и HTTP сервер прикрутить и перехватывать рефереры пользователей Не требуется. >но это уже не суть Да. >Вот я и предлагаю чтобы когда надо этот злоклиент отправил запрос с необходимыми параметрами на атакуемый сайт. Нет доступа к сайту (логина/пароля), неизвестны куки, другой ip. >В том то и дело что известны, цитирую автора еще раз: Автор пишет об использовании его Cookie и ip. Он не уточнил известны они злосайту или нет. >Он предполагает что куки уже перехвачены, а также имеется возможность подставить ip Нет. Он думает иначе. >и после этого предлагает защищаться реферером Да. >а вот этого я уже не понимаю Да. >И вообще, ведь далеко не каждый сайт подразумевает авторизацию (куки) и уж тем более проверку ip. Да. Доступ к ним злоумышленник может получить не применяя этот тип атаки. Она предназначена для сайтов, на которые необходимо так или иначе войти с авторизацией, прежде чем осуществлять какие-либо действия.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	60. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	–1 +/–
	Сообщение от thirteensmay on 18-Фев-10, 22:32
	Ооо ! кажись понял, автор имел ввиду использование его кук в рамках понятия CSRF, т.е. не их перехват и запрос с подставного сайта, а склонение пользовательского браузера к отправке запроса на оригинальный сайт но с измененными параметрами, не теми что ввел пользователь. Т.е. автор просто неверно сформулировал часть предложения, вместо: >запрос мог быть присланным с ЛЮБОГО другого подставного сайта, но с использованием МОИХ Cookie и моего ip следовало бы написать чтото типа: >запрос мог быть выполнен из моего браузера, но с подставными параметрами, и естественно с моими Cookie и ip так ???
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	61. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Аноним (??) on 18-Фев-10, 22:40
	>так ??? Да.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	63. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от polymorphm1 (ok) on 20-Фев-10, 03:37
	> так ??? да так :-) давно меня небыло на этом обсуждении, извеняюсь :-(.. просто когда я говорил что "запрос придёт с сайта" -- я не конкретизировал кто конкретно его будет посылать (www-browser или www-server) , ....потомучто сайт он же не только на сервере -- но и на моём  [клиентским]компьютере: javascript`ы сайта например обрабатываются моим [клиентским]процессором (чего кстате не делается на сервере) , HTML и CSS рисуются тоже моим [клиентским]процессором , ды даже сама картинка сайта -- показывается на моём [клиентским]мониторе :-) ..такчто неподумал что моя формулировка "отправить с сайта" может когото ввергнуть в смуту (что ктото подумает что сайт это ТОЛЬКО то что работает на www-server) простите :-(
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

37. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
Сообщение от luzers on 18-Фев-10, 14:14
Распечатать и большим плакатом в программерских развесить. для альтернативноодаренных - заставлять зубрить. потом спросить за отче наш, гимн СССР и гимн России)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

75. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
Сообщение от gHg on 04-Июл-11, 09:15
админам составьте пожалуйста ПОЛНЫЙ список из инета, обязательно по категорям (языки, назначение программ/алгоритмов,....). + >"Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде" - полуказанно, так даже шифруя их - они могут быть взломаны, или тупо проданы персоналом или владельцем. ---- + использование скриптов - как формы backdoor под видом ошибок транслятора/JIT или библиотек, тем более если могут выполнять себя динамически(без компиляции/трансляции) вроде интернетовских
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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