Институт 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/
Новость: http://www.opennet.me/opennews/art.shtml?num=25465
Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.
>Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.Угу.
А установка SElinux делает Windows намного безопаснее)
Там немалая часть уязвимостей относится к безопасности в web.
На основании каких данных был сделан вывод о Windows, если не секрет?
Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть от ужаса
>Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть
>взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть
>от ужасаС этим я не спорю)
Я просто хочу указать ваше внимание, что все эти уязвимости не могут быть только на Windows.
Так как там куча уязвимостей, относящихся к web (php, sql, алгоритмы обработки форм).
Так же куча уязвимостей, относящихся к приемам программирования вообще.
Ну и указание на то, что SElinux помогает, как-бы намекает на то, что это не только в Windows)
И какие сотни обновлений была для поддерживаемых на сегодня ОС 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...
>И какие сотни обновлений была для поддерживаемых на сегодня ОС 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 за уязвимость не считают.
Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год. Это без всяких Xов, графической оболочки и др. А значит - присутствовали во всех! дистрибутивах Linux в 2009 году на ядре 2.6.... http://secunia.com/advisories/product/2719/?task=statistics_...
>Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год.Посмотрите на усердно вами цитируемом secunia степень опасности этих уязвимостей - Less critical или Not critical. Я ни одной даже со статусом Moderately critical (умеренная опасность) не смог найти. Теперь набираем в поиске http://secunia.com/advisories/search/ Windows и видим только за февраль 9 уязвимостей из которых половина имеет статус Highly critical. Теперь я понимаю почему вас не любят на этом форуме, вы упорно подтасовывайте факты.
28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр в web-приложениях это вы мощно сравнили.
>28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр
>в web-приложениях это вы мощно сравнили.какие веб-приложения в настольных системах... читайте внимательно
это все я пишу в ответ на заявления человека о многих сотнях дыр в виндах в 2009 году...
>это все я пишу в ответ на заявления человека о многих сотнях
>дыр в виндах в 2009 году...Вы ссылались на статистику по числу дыр в Red Hat, а не только в настольных приложениях. То что в Rad Hat и Windows несколько разный объем приложений вас не смутило.
Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка PHP: построение SQL-запросов путем конкатенации, смешивание html-кода и программной логики, скрипты и файлы с данными вперемешку, изначальное отсутствие пространств имен, "magic quotes hell" (убрали, но каким местом раньше думали), register_globals (понятно, что обычно выключено, но как вообще можно было в здравом уме до такого додуматься).
хорошо сказано :)
А Oracle не хочет приобрести php???
"..которая связанна с использованием непоследовательного и непродуманного языка PHP.."
Если в Вашем тексте PHP заменить на SQL, то смысл не измениться. Всякие там иньекции и т.п.
Но на SQL ни кто не гонит.
На PHP есть масса очень грамотных проектов.
Возможно, всё-таки проблема с руками.
самая больная проблема в PHP -- это mod_php , который ПООЩРЯЕТ помещщение (и выполнение) php-файлов в тойже самой директории что и статические media-файлы..
Проблема не в SQL. Все нормальные API для работы с SQL работают так: запрос с параметрами (например "SELECT * FROM table WHERE id = ?") сначала компилируется, а значения параметров подставляются уже при выполнении запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL и делает инъекции невозможными.Для PHP тоже есть такие API, но в PHP построение запросов путем подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные функции предполагают именно такой способ.
эта норма пришла скорее от mysql, потому что там изначально небыло компиляции запросов, и любая прослойка позволявшая пользоваться переменными по сути ничего кроме конкатенации не делала. А ещё php во все времена имел очень низенькую планочку для IQ разработчика, поэтому им пользуются столько людей которые даже слова "фреймворк" не знают. В принципе, как windows - своей убогостью создал себе огромный рынок.
>Проблема не в SQL. Все нормальные API для работы с SQL работают
>так: запрос с параметрами (например "SELECT * FROM table WHERE id
>= ?") сначала компилируется, а значения параметров подставляются уже при выполнении
>запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL
>и делает инъекции невозможными.А если логика запроса посложнее и состоит из 100 вложений ("инъекций")
и поведение следующего вложения завязано на результате предыдущего (или нескольких)?
Пелёнки всё вырежут?>
>Для PHP тоже есть такие API, но в PHP построение запросов путем
>подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные
>функции предполагают именно такой способ.Разговор был о языках а не о API.
При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются в бомбу.
>А если логика запроса посложнее и состоит из 100 вложений ("инъекций")
>и поведение следующего вложения завязано на результате предыдущего (или нескольких)?Это значит, что вам следует пересмотреть модель данных. Если подобные запросы все-таки необходимы в порядке исключения, то и строить их придется аккуратно другим способом, на то оно и исключение. Нормой это быть не может.
>Разговор был о языках а не о API.
Вместе с языком предоставляется стандартный API.
>При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются
>в бомбу.Как будто не бывает плохих языков программирования. Понятно, что можно писать надежный код даже на PHP. Проблема в том, что PHP провоцирует порочную практику программирования, как я уже писал выше. Это как Бейсик: студенты изучавшие его, по словам Дейкстры, "подверглись необратимой умственной деградации".
>Проблема не в SQL. Все нормальные API для работы с SQL работают
>так: запрос с параметрами (например "SELECT * FROM table WHERE id
>= ?") сначала компилируется, а значения параметров подставляются уже при выполнении
>запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL
>и делает инъекции невозможными.
>
>Для PHP тоже есть такие API, но в PHP построение запросов путем
>подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные
>функции предполагают именно такой способ.Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно.
Проблема безопасности заключается в первую очередь не в языках или технологиях, а в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во, специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости.
> Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно.Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных.
> Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости.
Говорит, как минимум, о разгильдяйстве.
> Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных.Нет никаких проблем с моделью данных, есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Кроме разных таблиц там еще куча динамически изменяющихся условий, т.е. and, or, between, case и т.п., ну не реализуется такое плейсхолдерами никак, и модель тут не причем.
> Говорит, как минимум, о разгильдяйстве.
В некотором плане говорит, не спорю, но смотрите на мир реально, у меня срок реализации фичи - неделя, да я за это время еле-еле только самую основу успею, ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть.Это все-таки не обычное использование БД, исключение, а не норма. Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев.
> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли все сложно?
> Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаевВот с этим не могу не согласится. Моя же речь про то что эти исключительные случае весьма бывают, тут один, там другой, вот уже и набралось, приложения нонче весьма не маленькие, особенно если умник какой попадется, ООП, MVC, ORM и пр. на ровном месте городить начнет, вообще туши свет
> веб-приложение, так ли все сложно?
Не только web. А вообще ведь дело не в том что сложно, а в том что сложнее
>> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть.
>
>Это все-таки не обычное использование БД, исключение, а не норма. Речь о
>том, что использование запросов с параметрами — норма, а манипуляции со
>строками — для исключительных случаев.
>
>> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
>
>Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли
>все сложно?Позвольте не согласиться - это как раз НОРМА.
Если у Вас база нормализована, то по другому просто не сделать (или у Вас всё в одной таблице?).
Не, ну конечно можно сделать кучу запросов к разным таблицам, потом переварить это перлом или пхп и сделать ещё кучу запросов, и ещё, и ещё...
А можно просто написать сложный SELECT и предоставить базе оптимизировать этот SELECT.
>> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть.
>
>Это все-таки не обычное использование БД, исключение, а не норма. Речь о
>том, что использование запросов с параметрами — норма, а манипуляции со
>строками — для исключительных случаев.
>
>> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
>
>Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли
>все сложно?Ошибаетесь. Это давно уже норма. Время, когда все можно было сделать запросами вида SELECT * FROM x WHERE y - прошло. Множество запросов строится "на лету", исходя из разношерстных пожеланий пользователя.
>Проблема безопасности заключается в первую очередь не в языках или технологиях, а
>в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во,
>специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость
>тоже конечно имеет место быть, но вот я лично прекрасно знаю
>кучу уязвимостей в своих поделках, но не исправляю их ибо не
>до того, не интересно, есть др. задачи, лень, за это не
>заплатят, и т.п. что в общем то заметьте не говорит о
>моей криворукости.А вот смотрите, не в защиту перла а просто как сравнение: на перле с базой работают через DBI, весь её интерфейс и документация изначально подразумевают компиляцию запросов и исполльзование переменных, и никому не приходится тратить какие-то дополнительные усилия чтобы узнать как работать с ней безопасно (разве что этот кто-то из php пришёл). Почему? - потому что перл не имеет нативных функций для sql , там изначально работают с фреймворками и к этому привыкли, а этот фреймворк был написан не как api wrapper для mysql а как универсальный инструмент для профессиональной работы с базами. И что получается? PHP для той-же самой функциональности требует от разработчика более низкого интеллекта чем перл, в результате новичёк работая с перлом подтянется, а хороший специалист работая с php расслабится и будет писать плохой код, потому что "и так работает". При том что качественный код каких-то дополнительных трудозатрат особо и не требует, это только следствие определённой культуры. Культурному человеку ведь не приходится тратить время чтобы им оставаться?
И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполнять, тыщу раз такое видел и сам делал, говорю вам не в инструменте дело, точнее не в первую очередь в инструменте. Качественный продукт к сожалению таки требует дополнительных трудозатрат. А вот про культуру вы хорошо заметили, все прекрасно, но это только в идеальном сферическом мире, а на практике все под елочку ходят когда приспичит.Если тему развивать я вам даже больше скажу, проблема безопасности через деньги вытекает вообще к нашему социально-экономическому строю, с одной стороны производителям зачастую не особо выгодно производить высококачественный продукт, с другой - нанимать на его реализацию "культурных" исполнителей, ибо качество дорого, а культура капризна. Основной принцип - руби бабло, промышленный подход, так что качество (безопасность) второстепенны, если конечно вы не рубите бабло на безопасности ;)
я не о том что на перле это невозможно, я о том что там в отличии от php при работе с базой наиболее лёгкий и удобный способ одновременно является и более безопасным, и при этом приучает делать более качественный код. Может быть в этом главная слабость php - он реализует очень много функциональности на уровне языка вместо того чтобы стимулировать развитие более качественных фреймворков, а все эти стандартные расширения практически монополизируют свою функцию, какому-то конкурирующему решению очень сложно пробиться.P.S. ещё раз, я здесь имею в виду только DBI и отдельные особенности перла, не говорю про весь язык и всё что на нём написанно.
а я вам про то что я например, при освоении DBI был весьма озадачен таким подходом, особенно когда узнал что mysql не поддерживал хранимых запросов, и в результате чтобы не выписывать каждый раз такие кренделя написал функцию execute_query() в которую передавал динамически собираемую строку запроса. Даже если бы mysql поддерживал то всеравно бы написал, ибо в результате проще, кода меньше, на тот момент я был таков, писал кода в день в три раза больше чем сейчас и просил за это крохи, а теперь что, пока доку три раза прочтешь, пока подумаешь, спланируешь, ошибки обработаешь и т.п. пацан молодой какой нить уже 10 раз все сделает за в три раза меньшие деньги, вот и подумайте кого выберет современный массовый работодатель производитель всякого ширпотреба ? Незнаю, возможно я и не прав, можете убеждать меня дальше, но считаю что инструменты тут дело далеко десятое.
а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых местах водятся очень даже культурные клиенты которые готовы доплатить небольшой бонус за качество чтобы потом не потерять бóльшие деньги
это всеже не мэйнстрим, в основном то ПО впаривается, посмотрите на туже винду или офис, куча красочных перделок, мало кому нужных и зачастую даже бесплатных.
"..смешивание html-кода и программной логики.."
Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
>"..смешивание html-кода и программной логики.."
>Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?Ну ведь действительно так и есть. Смешивание неправильно по сути.
>>"..смешивание html-кода и программной логики.."
>>Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
>
>Ну ведь действительно так и есть. Смешивание неправильно по сути.Неправильно - смешивание данных и кода.
А смешивание кода и кода - это вопрос вкуса.
> Неправильно - смешивание данных и кода.
> А смешивание кода и кода - это вопрос вкуса.код коду рознь...
txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером -- в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно какую), где дожен перейти на следущую строчку, где поставить пробел, или серию пробелов (\t)...
html-код -- чуть сложнее txt-кода ..
...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...
>> Неправильно - смешивание данных и кода.
>> А смешивание кода и кода - это вопрос вкуса.
>
>код коду рознь...
>
>txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером --
>в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно
>какую), где дожен перейти на следущую строчку, где поставить пробел, или
>серию пробелов (\t)...Текстовый файл не содержит инструкций, которые нужно выполнить (в идеале).
(\t \n и др. это не код, а просто невидимые символы)>
>html-код -- чуть сложнее txt-кода ..Дело не в сложности.
>
>...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять
>от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ
>кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...
>IMHO это не нужно рассматривать как правило.
В некоторых случаях проще и эффективнее вставить html в лигику.
Очень, ОЧЕНЬ зависит от задач проекта.
> \t \n и др. это не код, а просто невидимые символыhttp://ru.wikipedia.org/wiki/Управляющий_символ
сюрприз? :)
>> \t \n и др. это не код, а просто невидимые символы
>
>http://ru.wikipedia.org/wiki/Управляющий_символ
>
>сюрприз? :)Специалисты меня порвали. ))
>IMHO это не нужно рассматривать как правило.
>В некоторых случаях проще и эффективнее вставить html в лигику.
>Очень, ОЧЕНЬ зависит от задач проекта.Ваше imho нам понятно)
В качестве точки зрения могу указать на темы (skins), шаблоны (templates).
При разделении выполняемой и показываемой частей, впендюрить новый шаблон или новую тему куда проще.
А при смешивании - это такой гемморой...
Для примера могу указать на скрипты для web-магазина oscommerce.
Там изначально все в перемешку.
И поменять скин там - задачка ещё та.Так же при этом разделении куда проще сделать переход на другой язык программирования (или на более новую версию текущего языка).
Есть мнение что впендюривание новых шаблонов и тем - туфта гламурных домохозяек, плюсы конечно есть, но это не общеупотребимо, а вот сложность при этом увеличивается, само понятие шаблона, их язык, производительность опять таки. А чем сложнее система тем больше в ней уязвимостей ;) Нет, я не хочу сказать что рассматриваемый подход зло, всему свое место, зачастую простейший вариант с формированием ответа в одном скрипте оптимален, как уже сказали выше все зависит от задачи.
Это противоречит архитектурному шаблону Model–View–Controller, затрудняет модификацию кода и контроль его корректности.
а сколько господ даже здесь рассуждают о языке без намёка на MVC в своих текстах?
>а сколько господ даже здесь рассуждают о языке без намёка на MVC
>в своих текстах?MVC никто не отменял.
НеMVC тоже ;)
>НеMVC тоже ;)Согласен.
Фанатизм - Зло!
> MVC никто не отменял.я скорее о том что очень многие php программисты или о нём совсем не знают, или не понимают зачем он им нужен (или не нужен). В большинстве дискуссий это заметно.
>> MVC никто не отменял.
>
>я скорее о том что очень многие php программисты или о нём
>совсем не знают, или не понимают зачем он им нужен (или
>не нужен). В большинстве дискуссий это заметно.А вы даже для HelloWorld готовы юзать MVC?
> Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка 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.... охохохохооо... :-(
>[оверквотинг удален]
>
>$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 . '</а>';
?>не?
>[оверквотинг удален]
>>
>
><?php
>$name_arg = stripslashes($_GET['name']);
>$href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
>$prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
>echo '<а href="' . $href . '">' . $prof . '</а>';
>?>
>
>не?Смешиваем код с html? ))
>
> <?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;-и-&-мусор
больше всего нанавижу что люди (разработчики функциональных 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] -- то ДЫРА СУЩЕСТВУЕТ какбы ПОУМОЛЧАНИЮ...
А чем перехват и подмена кук и ip отличается от подмены HTTP_REFERER ?
От подмены IP защитит протокол TCP/IP. (если вы не внедрились в канал связи)
Перехват кук так же не возможен при тех же условиях. (нужно хотя бы чтение канала связи)А для действий от вашего имени на любом сайте, пусть даже защищённом https. Достаточно, чтобы вы перешли по ссылке. А там за вас будет сформирован и отправлен любой запрос, имитирующий любое ваше действие.
В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ? И для этого даже не придется прослушивать канал связи ?
>В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ?Нет. Или это дыра в браузере. Может быть запрос любой страницы или любого действия на странице другого сайта. Вполне штатная функция. Блокируется лишь там где это явно необходимо.
>И для этого даже не придется прослушивать канал связи ?
Да. Не придется.
Какая дыра в браузере ? Запрос отправляется не из браузера а с сайта злоумышленника. Я не понимаю почему человек считает что если у него перехватили куку то он сможет защититься реферером, он же в плане безопасности по сравнению с куками сопля полная, светиться всем.
>Запрос отправляется не из браузера а с сайта злоумышленника.Нет. Из браузера. Referer: сайт злоумышленника.
Куку не перехватили. Всё работает и отправляется стандартно.Referer может подменить клиент, но не другой сайт. В плане безопасности проверка Referer необходима, чтобы удостовериться, что клиент сам выполняет действие.
> Куку не перехватилиЦитирую:
> например напишут от твоего имени сообщение на форуме opennet.ru оскорбительного содержания, а ты потом доказывай кому хочешь что просто-навсего opennet.ru не проверяет испочник (HTTP_REFERER) POST-запроса, а следовательно запрос мог быть присланным с ЛЮБОГО другого подставного сайта, но с использованием МОИХ Cookie и моего ipReferer может подменить клиент, все правильно, но не клиент обычного пользователя а клиент установленный на сайте злоумышленника, когда пользователь попадет на злосайт он засветит там свой referer, да вобщем то его и так легко подставить, мы же знаем какой сайт атакуем, тогда referer ничего не даст, запрос от злоклиента придет с правильным реферером, а вот у честного пользователя он поменяется и его запросы будут отвергнуты.
или чего я непонимаю ?
>клиент установленный на сайте злоумышленникаНе нужен.
>когда пользователь попадет на злосайт он засветит там свой referer
Засветит откуда пришёл. Злосайту это не важно.
>да вобщем то его и так легко подставить
Referer может подменить клиент, но не другой сайт.
>мы же знаем какой сайт атакуем
Да.
>тогда referer ничего не даст
Нет. Даст. Он даст адрес страницы злосайта, на которой пользователю предложили/заставили совершить действие.
>запрос от злоклиента придет с правильным реферером
Нет.
>а вот у честного пользователя он поменяется и его запросы будут отвергнуты.
Нет. Пользователь всегда честный. Совершить действие с сайтом ему может предложить сам сайт или злосайт. В первом случае сработает, во втором не сработает.
>чего я непонимаю ?
Суть.
> Referer может подменить клиент, но не другой сайт
> клиент установленный на сайте злоумышленника Не нуженЗа тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным реферером
> запрос от злоклиента придет с НЕ правильным рефереромПочему ? мыж его ручками подправим
> Реферер даст адрес страницы злосайта, на которой пользователю предложили/заставили совершить действие.Реферер пользователя после посещения злосайта да, но он нас уже не интересует, пользователь отработан, со злосайта из злоклиента уже ушел запрос на атакуемый сайт с "правильными" параметрами
> Пользователь всегда честныйДа, но его честь можно украсть
Какой сути я не понимаю ? что именно не сработает в предложенной схеме ?
>За тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным рефереромОтправлять запрос злосайт не будет. Он показывает страницу.
>Почему ? мыж его ручками подправим
Реферер формируется браузером пользователя, а не страницей и не скриптом на ней.
>Реферер пользователя после посещения злосайта да, но он нас уже не интересует, пользователь отработан, со злосайта из злоклиента уже ушел запрос на атакуемый сайт с "правильными" параметрами
Нет. Не имеет смысла. Злосайт не имеет такого же доступа на сайт, как пользователь.
>Да, но его честь можно украсть
Да.
>Какой сути я не понимаю ?
Cross-Site Request Forgery (CSRF)
>что именно не сработает в предложенной схеме ?
Нет доступа к сайту (логина/пароля), неизвестны куки, другой ip.
>Отправлять запрос злосайт не будет. Он показывает страницу.
>Реферер формируется браузером пользователя, а не страницей и не скриптом на ней.Да злосайт сайтом называется только ради красоты, обычная машинка с доступом к сети и "специализированными" скриптами, HTTP сервера там может и не быть, главное чтобы он слушал команды злоумышленника и мог формировать произвольные HTTP запросы, это не сложно, ну если уж совсем хочется то можно и HTTP сервер прикрутить и перехватывать рефереры пользователей, но это уже не суть. Вот я и предлагаю чтобы когда надо этот злоклиент отправил запрос с необходимыми параметрами на атакуемый сайт.
>Злосайт не имеет такого же доступа на сайт, как пользователь
>Нет доступа к сайту (логина/пароля), неизвестны куки, другой ip.В том то и дело что известны, цитирую автора еще раз:
>с использованием МОИХ Cookie и моего ip
Он предполагает что куки уже перехвачены, а также имеется возможность подставить ip, и после этого предлагает защищаться реферером, а вот этого я уже не понимаю. И вообще, ведь далеко не каждый сайт подразумевает авторизацию (куки) и уж тем более проверку ip.
>Да злосайт сайтом называется только ради красотыНет. Ради определённости. Нужны термины для ведения дискуссии.
>обычная машинка с доступом к сети и "специализированными" скриптами
Да.
>HTTP сервера там может и не быть
Нет.
>главное чтобы он слушал команды злоумышленника и мог формировать произвольные HTTP запросы
И то и другое не нужно.
>это не сложно
Да.
>ну если уж совсем хочется то можно и HTTP сервер прикрутить и перехватывать рефереры пользователей
Не требуется.
>но это уже не суть
Да.
>Вот я и предлагаю чтобы когда надо этот злоклиент отправил запрос с необходимыми параметрами на атакуемый сайт.
Нет доступа к сайту (логина/пароля), неизвестны куки, другой ip.
>В том то и дело что известны, цитирую автора еще раз:
Автор пишет об использовании его Cookie и ip. Он не уточнил известны они злосайту или нет.
>Он предполагает что куки уже перехвачены, а также имеется возможность подставить ip
Нет. Он думает иначе.
>и после этого предлагает защищаться реферером
Да.
>а вот этого я уже не понимаю
Да.
>И вообще, ведь далеко не каждый сайт подразумевает авторизацию (куки) и уж тем более проверку ip.
Да. Доступ к ним злоумышленник может получить не применяя этот тип атаки. Она предназначена для сайтов, на которые необходимо так или иначе войти с авторизацией, прежде чем осуществлять какие-либо действия.
Ооо ! кажись понял, автор имел ввиду использование его кук в рамках понятия CSRF, т.е. не их перехват и запрос с подставного сайта, а склонение пользовательского браузера к отправке запроса на оригинальный сайт но с измененными параметрами, не теми что ввел пользователь. Т.е. автор просто неверно сформулировал часть предложения, вместо:>запрос мог быть присланным с ЛЮБОГО другого подставного сайта, но с использованием МОИХ Cookie и моего ip
следовало бы написать чтото типа:
>запрос мог быть выполнен из моего браузера, но с подставными параметрами, и естественно с моими Cookie и ip
так ???
>так ???Да.
> так ???да так :-)
давно меня небыло на этом обсуждении, извеняюсь :-(..
просто когда я говорил что "запрос придёт с сайта" -- я не конкретизировал кто конкретно его будет посылать (www-browser или www-server) ,....потомучто сайт он же не только на сервере -- но и на моём [клиентским]компьютере: javascript`ы сайта например обрабатываются моим [клиентским]процессором (чего кстате не делается на сервере) , HTML и CSS рисуются тоже моим [клиентским]процессором , ды даже сама картинка сайта -- показывается на моём [клиентским]мониторе :-)
..такчто неподумал что моя формулировка "отправить с сайта" может когото ввергнуть в смуту (что ктото подумает что сайт это ТОЛЬКО то что работает на www-server)
простите :-(
Распечатать и большим плакатом в программерских развесить.
для альтернативноодаренных - заставлять зубрить.
потом спросить за отче наш, гимн СССР и гимн России)
админам составьте пожалуйста ПОЛНЫЙ список из инета, обязательно по категорям (языки, назначение программ/алгоритмов,....).
+ >"Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде"
- полуказанно, так даже шифруя их - они могут быть взломаны, или тупо проданы персоналом или владельцем.
----
+ использование скриптов - как формы backdoor под видом ошибок транслятора/JIT или библиотек, тем более если могут выполнять себя динамически(без компиляции/трансляции) вроде интернетовских