The OpenNET Project / Index page

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

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

"Рейтинг самых опасных ошибок, зафиксированных в 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 email 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 email 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 +/
Сообщение от Ян Злобин email 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 | Индекс форумов | Темы | Пред. тема | След. тема




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

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