The OpenNET Project / Index page

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



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

Оглавление

PHP-транслятор HipHop позволил Facebook использовать в разы ..., opennews (ok), 04-Апр-11, (0) [смотреть все]

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


30. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от croster (ok), 04-Апр-11, 15:52 
>в компилируемом быть не может в принципе "тот же eval"

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

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

32. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 04-Апр-11, 15:57 
> eval - это вообще штука опасная. Каждый eval в коде - это потенциально лазейка для хакеров, которые смогут с его помощью выполнить свой код.

Прямо таки каждый eval? Или все-таки то, что туда передается? И все или только некоторое?

Сразу видно, что вы в программировании не разбираетесь, а просто где-то что-то вычитали об этом и плохо поняли.

Ответить | Правка | Наверх | Cообщить модератору

37. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +1 +/
Сообщение от croster (ok), 04-Апр-11, 16:23 
Если есть eval, значит туда обязательно что-то передается.
Ответить | Правка | Наверх | Cообщить модератору

94. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от diff (??), 04-Апр-11, 19:01 
> Если есть eval, значит туда обязательно что-то передается.

В любую инструкцию или функцию с параметрами тоже что-то передается. И что?

Ответить | Правка | Наверх | Cообщить модератору

98. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Аноним (-), 04-Апр-11, 19:17 
>> Если есть eval, значит туда обязательно что-то передается.
> В любую инструкцию или функцию с параметрами тоже что-то передается. И что?

А то, что то что передается в eval выполняется, а то что передается в функцию обрабатывается кодом функции.

Ответить | Правка | Наверх | Cообщить модератору

102. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 04-Апр-11, 19:30 
> А то, что то что передается в eval выполняется, а то что передается в функцию обрабатывается кодом функции.

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

Что делает именно eval сам по себе "опасной штукой" без вариантов, как он утверждал?

Ответить | Правка | Наверх | Cообщить модератору

106. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +2 +/
Сообщение от anonym (?), 04-Апр-11, 19:51 
В том то и отличие, что передаётся ссылка на существующую функцию, и банальная подстановка кода здесь не проходит. Да и кто в здравом уме будет принимать внешние по отношению к приложению функции?
Ответить | Правка | Наверх | Cообщить модератору

109. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –2 +/
Сообщение от diff (??), 04-Апр-11, 19:54 
> В том то и отличие, что передаётся ссылка на существующую функцию, и банальная подстановка кода здесь не проходит. Да и кто в здравом уме будет принимать внешние по отношению к приложению функции?

Значит вы считаете, что в eval тоже по умолчанию проходит "банальная подстановка кода".
Или тоже где-то об этом прочитали?

Ответить | Правка | Наверх | Cообщить модератору

114. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от anonym (?), 04-Апр-11, 20:06 
> Значит вы считаете, что в eval тоже по умолчанию проходит "банальная подстановка
> кода".
> Или тоже где-то об этом прочитали?

PHP - исходно интерпретируемый язык, это уже подразумевает способ вычисления подобных выражений: втавка в текстовый код строки из eval. По-моему, очевидно, что в этом случае подставленная строка выполняется точно так же, как и её контекст. А прочитать можно например здесь: http://www.php.su/functions/?eval

Ответить | Правка | Наверх | Cообщить модератору

126. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от diff (??), 04-Апр-11, 20:43 
См ниже, здесь
https://www.opennet.ru/openforum/vsluhforumID3/76066.html#125
Ответить | Правка | Наверх | Cообщить модератору

112. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 04-Апр-11, 20:05 
> В том то и отличие, что передаётся ссылка на существующую функцию

То есть вы не знаете, как передавать ссылки на несуществующие на момент трансляции функции.

> Да и кто в здравом уме будет принимать внешние по отношению к приложению функции?

"Внешние по отношению к приложению функции" - это уже RPC.
А в eval по-вашему передается только "внешний по отношению к приложению код"?

Не знаете предмет.

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

119. "Re: про функции"  +/
Сообщение от anonym (?), 04-Апр-11, 20:16 
>> В том то и отличие, что передаётся ссылка на существующую функцию
> То есть вы не знаете, как передавать ссылки на несуществующие на момент
> трансляции функции.

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

>> Да и кто в здравом уме будет принимать внешние по отношению к приложению функции?
> "Внешние по отношению к приложению функции" - это уже RPC.

RPC - это remote call, выполняется он на другом хосте и, как правило, после авторизации

> А в eval по-вашему передается только "внешний по отношению к приложению код"?

Дыра в безопасности как раз в случае подстановок в строку евала внешних данных, как всегда.

> Не знаете предмет.

Ответить | Правка | Наверх | Cообщить модератору

125. "Re: про функции"  –4 +/
Сообщение от diff (??), 04-Апр-11, 20:41 
> А прочитать можно например здесь: http://www.php.su/functions/?eval

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

Кроме того речь зашла о том, что eval якобы "опасная штука". Может быть его реализация в PHP действительно какая-то угробищная. Только при чем здесь PHP, если речь шла об eval вообще.

Итак.

> PHP - исходно интерпретируемый язык, это уже подразумевает способ вычисления подобных выражений: втавка в текстовый код строки из eval.

Вообще-то существуют разные способы реализации "исходно интерпретируемых языков".
Значит в PHP это так? Он значит все в "текстовом коде" шурует. Может быть. Наверное это действительно очень опасно. )))

> По-моему, очевидно, что в этом случае подставленная строка выполняется точно так же, как и её контекст.

Вообще какой-то набор слов из желания казаться.
Что такое контекст строки? И как же выполняется ее контекст?

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

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

По крайней мере вы подтвердили, что можно, тогда при чем здесь "опасность eval"?

> RPC - это remote call, выполняется он на другом хосте и, как  правило, после авторизации

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

>> А в eval по-вашему передается только "внешний по отношению к приложению код"?
> Дыра в безопасности как раз в случае подстановок в строку евала внешних данных, как всегда.

Что значит как всегда? Может у вас действительно так всегда.

А если в eval подставляются не внешние данные? Ну в чем опасность именно самого eval? Ну не передавайте ему "внешние данные" без проверки. Или вообще внешних данных не передавайте ему. При чем здесь сам eval, как "опасная штука" по умолчанию?

Не знаете предмет.

Ответить | Правка | Наверх | Cообщить модератору

132. "Re: про функции"  +/
Сообщение от mahairod (?), 04-Апр-11, 21:17 
> Не надо мне всякие сомнительные ссылки подсовывать, если сами свои мысли сформулировать
> не можете. Кроме того, сайты сообщества PHP я за кладезь Ъ-знаний
> по программированию не считаю.
>> По-моему, очевидно, что в этом случае подставленная строка выполняется точно так же, как и её контекст.
> Вообще какой-то набор слов из желания казаться.
> Что такое контекст строки? И как же выполняется ее контекст?

Это была первая попавшаяся ссылка из гугла. Содержание соответствовало моим фундаментальным представлениям, потому посчитал инфу оттуда достаточно достоверной в первом приближениии и сослался. Я по-моему на русском языке излагаю: контекст для евала в данном случае - сам пхп-скрипт, если не понятно. параметр евала вставляется в этот контекст. По ссылке,что я дал, все понятно разъяснено.

> Кроме того речь зашла о том, что eval якобы "опасная штука". Может
> быть его реализация в PHP действительно какая-то угробищная. Только при чем
> здесь PHP, если речь шла об eval вообще.

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

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

Если функции на момент выполнения не было, логично что её нужно создать. Вы знаете способ выполнить её локально, не помещая в память?

> По крайней мере вы подтвердили, что можно, тогда при чем здесь "опасность
> eval"?

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

>> RPC - это remote call, выполняется он на другом хосте и, как  правило, после авторизации
> Купились на слово remote? Нет, это как раз то, что вы описали
> - из другого процесса. Хотя он может и на другом хосте
> быть, пожалуйста, но не обязательно.
> Не знаете предмет. Википедию для начала прочтите, что ли. Если ни одну
> книжку не открывали.

Важно, что косвенно через систему в другой процесс.
Это из википедии, и из того, что помню про java-RMI. А вы знаете предмет иначе?

>> Дыра в безопасности как раз в случае подстановок в строку евала внешних данных, как всегда.
> Что значит как всегда? Может у вас действительно так всегда.
> А если в eval подставляются не внешние данные? Ну в чем опасность
> именно самого eval? Ну не передавайте ему "внешние данные" без проверки.
> Или вообще внешних данных не передавайте ему. При чем здесь сам
> eval, как "опасная штука" по умолчанию?

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

Ответить | Правка | Наверх | Cообщить модератору

133. "Re: про функции"  +/
Сообщение от mahairod (?), 04-Апр-11, 21:19 
Кстати даже на случай загрузки левого кода существуют механизмы подписывания
Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

181. "Re: про функции"  –2 +/
Сообщение от diff (??), 05-Апр-11, 12:39 
>Я по-моему на русском языке излагаю: контекст для евала в данном случае - сам пхп-скрипт, если не понятно. параметр евала вставляется в этот контекст.

Просто излагать что-то на русском языке не достаточно.
Сначала вы говорили про "контекст строки", теперь про "контекст эвала".
Ну, у эвала есть контекст, и что?
В каком "данном" случае контекстом эвала будет "сам пхп-скрипт"?
Или по-вашему у эвала другого контекста быть не может?
И вообще, при к чему вы заговорили о контексте?

> По ссылке,что я дал, все понятно разъяснено.

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

> Ну так в том же яваскрипте точно примерно так же в теории, суть в том, что можно выполнить произвольный левый код.

Что значит "можно выполнить произвольный код"? Какой код вы туда засунете, такой и выполнит.
Ну так не засовывайте туда что попало.

> Если функции на момент выполнения не было, логично что её нужно создать. Вы знаете способ выполнить её локально, не помещая в память?

Что значит "выполнить её локально, не помещая в память"?
Я говорил про момент трансляции, а вы почему-то про момент выполнения. Не знаете между ними разницы?

> Ни при чём, в том то и отличие. Если вам не взбредёт в голову в качестве параметра загружать какую-нибудь длл (тот же плагин для браузера, к примеру), проблем с безопасным выполнением кода не будет - в отличие от евал.

То есть вы считаете, что загружать целую dll гораздо безопаснее, чем выполнять код в eval.

> Важно, что косвенно через систему в другой процесс.
> Это из википедии, и из того, что помню про java-RMI. А вы знаете предмет иначе?

Что значит "косвенно через систему в другой процесс"?
Нет таких слов в Википедии, специально даже посмотрел. Откуда вы их берете?
И при чем здесь java-RMI?

> Именно для обработки внешних данных имеет смысл использовать евал. Если данные внутренние, зачем от них делать евал, когда своим готовым кодом можно обработать.

Почему вы считаете, что для обработки внешних данных имеет смысл использовать именно eval?

А если есть готовый код, тогда, действительно, зачем нужен использовать eval.

Вы просто не знаете, для чего eval на самом деле предназначен.

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

То есть eval и механизмы подписывания вы ставите на один уровень.

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

141. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от croster (ok), 04-Апр-11, 22:36 
Вот почитайте, как быдлокодеры используют этот Ваш eval:
http://blog.kislenko.net/show.php?id=492&s=0
И еще статейка с заголовком "Eval considered mostly harmful" (http://www.saunalahti.fi/~s7l/blog/2005/09/06/Eval%20co...).  Можно сказать, что eval - это goto 21-го века.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

144. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –3 +/
Сообщение от diff (??), 04-Апр-11, 23:57 
Что вы мне все время какие-то ссылки подсовываете. Я без вас знаю, как eval работает, и как его правильно использовать, и в каких случаях. Это вы только сейчас начали лихорадочно гуглить на эту тему.

Вы этого не знаете, вот сами и читайте свои ссылки.

> Вот почитайте, как быдлокодеры используют этот Ваш eval:
> http://blog.kislenko.net/show.php?id=492&s=0

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

> И еще статейка с заголовком "Eval considered mostly harmful" (http://www.saunalahti.fi/~s7l/blog/2005/09/06/Eval considered harmful.html).

Это все что вам удалось нагуглить?
Какой-то блог за 2005г.? (Судя по самой строке гиперссылки)

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

Вот сами почитайте и объясните своими словами, что вам там удалось понять.

> Можно сказать, что eval - это goto 21-го века.

Понятно. Значит для вас eval это примерно то же, что и goto.

Ответить | Правка | Наверх | Cообщить модератору

166. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от croster (ok), 05-Апр-11, 08:54 
>Для любой вещи есть тысяча способов использовать ее неправильно и даже с риском для жизни.

Вы просто не понимаете, что опасность той или иной конструкции языка как раз и определяется порочной практикой ее применения (количеством лбов, побитых этими граблями).
>Какой-то блог за 2005г.?

И что? За это время что-то изменилось? Стало меньше уязвимостей?
Хорошо, если Вас не устраивает блог 2005 года, вот высказывания авторитетных гуру Javascript-программирования:
1. "eval is Evil: The eval function is the most misused feature of JavaScript. Avoid it" --Douglas Crockford, книга "JavaScript: The Good Parts"
2. "Overwhelmingly eval is trivailized, misused, and outright condemned by most JavaScript programmers but by looking at the work of some of the best coders you can see that, when used appropriately it allows for the creation of some fantastic pieces of code that wouldn’t be possible otherwise"
--John Resig, книга "Secrets of the JavaScript Ninja"

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

Ответить | Правка | Наверх | Cообщить модератору

170. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –2 +/
Сообщение от diff (??), 05-Апр-11, 10:45 
> Вы просто не понимаете, что опасность той или иной конструкции языка как раз и определяется порочной практикой ее применения (количеством лбов, побитых этими граблями).

Это вы не понимаете, что опасность, определяемая "порочной практикой" - это штука сугубо индивидуальная. Примерно как с электроприборами.

> И что? За это время что-то изменилось? Стало меньше уязвимостей?
> Хорошо, если Вас не устраивает блог 2005 года, вот высказывания авторитетных гуру Javascript-программирования:
> 1. "eval is Evil: The eval function is the most misused feature of JavaScript. Avoid it" --Douglas Crockford, книга "JavaScript: The Good Parts"
> 2. "Overwhelmingly eval is trivailized, misused, and outright condemned by most JavaScript programmers but by looking at the work of some of the best coders you can see that, when used appropriately it allows for the creation of some fantastic pieces of code that wouldn’t be possible otherwise" --John Resig, книга "Secrets of the JavaScript Ninja"

Вопрос стоял - в чем принципиальная опасность eval с точки зрения взлома? Как вы это утверждали. Самого по себе eval, а не "порочных практик" его применения.

Ну и где в приведенных вами цитатах об этом говорится?

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

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

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

Нет, это лишь подтверждает известную фразу - "заставь дурака молиться, он и лоб расшибет".

Ответить | Правка | Наверх | Cообщить модератору

214. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +2 +/
Сообщение от croster (ok), 05-Апр-11, 18:54 
>Самого по себе eval, а не "порочных практик" его применения.

Сам по себе существует только сферический конь в вакууме. Все, что касается кода, определяется только практикой его использования. И здесь приходится ориентироваться на усредненную массу пых-пых программистов, уровень которых, к сожалению, не очень высок. Приведенные цитаты - это всего лишь вывод из многочисленных публикаций по этой тематике. Достаточно только в гугле (если Вас там не забанили) набрать "avoid eval" и вы получите огромную массу публикаций и решений по избавлению от eval.

В обоих цитатах говорится о неправильном использовании eval в широких масштабах. Тут есть целый комплекс проблем с eval: 1) простота отладки кода; 2) простота поддержки кода; 3) производительность; 4) потребление памяти. И по всем этим параметрам применение eval не несет ничего хорошего, тем более в руках большинства быдлокодеров.

Больше спорить с Вами не хочу. У Вас в конторе ведь наверное все сотрудники уровня Джона Рейсига, и, наверное, каждый без проблем сможет написать свою jQuery. Сам Вы, насколько я понимаю, член по стандартизации какого-либо языка, раз считаете себя умнее всех и плюёте на все приводимые доказательства. Хотите быть миллион первым оленем, которому грабли eval'а разбили бошку, никто Вам в этом не мешает.

Ответить | Правка | Наверх | Cообщить модератору

222. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –2 +/
Сообщение от diff (??), 05-Апр-11, 19:46 
> Сам по себе существует только сферический конь в вакууме. Все, что касается кода, определяется только практикой его использования. И здесь приходится ориентироваться на усредненную массу пых-пых программистов, уровень которых, к сожалению, не очень высок.

Как интересно! Так это именно вы сферично в вакууме заявили о сферической опасности эвала в вакууме.
Вот ваши исходные слова:

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

Я вас только переспросил, почему вы так считаете.
Почему вы считате, что каждый сферический eval в коде в вакууме - это потенциальная сферическая лазейка для хакеров в вакууме?

А вы на меня стрелки теперь пытаетесь перевести.

> Приведенные цитаты - это всего лишь вывод из многочисленных публикаций по этой тематике. Достаточно только в гугле (если Вас там не забанили) набрать "avoid eval" и вы получите огромную массу публикаций и решений по избавлению от eval.
> В обоих цитатах говорится о неправильном использовании eval в широких масштабах. Тут есть целый комплекс проблем с eval: 1) простота отладки кода; 2) простота поддержки кода; 3) производительность; 4) потребление памяти. И по всем этим параметрам применение eval не несет ничего хорошего, тем более в руках большинства быдлокодеров.

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

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

Я вас спросил - почему вы считате - что непременно каждый eval (по вашим же словам) является "лазейкой для хакеров".

> Больше спорить с Вами не хочу. У Вас в конторе ведь наверное все сотрудники уровня Джона Рейсига, и, наверное, каждый без проблем сможет написать свою jQuery. Сам Вы, насколько я понимаю, член по стандартизации какого-либо языка, раз считаете себя умнее всех и плюёте на все приводимые доказательства. Хотите быть миллион первым оленем, которому грабли eval'а разбили бошку, никто Вам в этом не мешает.

Не спорьте, вас никто не заставляет.
Только вы и не спорили, и доказательств никаких не приводили.
Вы вместо этого упорно пытались перевести внимание с вашего высказывания о сферично-вакуумных "лазейках для хареков" на какие-либо другие недостатки eval, но только не на это.

Это говорит о том, что на момент вашего исходного высказывания, вы об этом просто ничего не знали, а сейчас просто лихорадочно гуглите.

Также, как вы ничего не знали по теме, когда заявляли про питон и руби в вашем посте №1.

Ответить | Правка | Наверх | Cообщить модератору

241. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от croster (ok), 06-Апр-11, 10:15 
>Я вас только переспросил, почему вы так считаете.

Никто не может гарантировать полное отсутствие ошибок в коде. Достаточно лишь небольшой невнимательности, одной какой-либо забытой проверки:
http://stackoverflow.com/questions/129677/whats-the-best-met...
А проверять всегда есть и много чего:
http://weblogs.java.net/blog/gmurray71/archive/2006/09/preve...
Учитывая, что в PHP выполнение eval равноценно подстановке исполняемого кода, передаваемого в качестве аргумента, в исходный код, а также не слишком высокий средний уровень php программистов (весь смысл низкого порога вхождения в php состоит в удешевлении рабочей силы), совершенно очевидно, что eval - это заряженное ружье, висящее на стене и способное выстрелить в своего владельца. В защищенные песочницы, создающие "изолированное безопасное окружение", веры нет никакой, в одной java сколько с этим проблем, почти каждый минорный релиз исправляют. Известно также и то, что динамический код сложнее в отладке и сопровождении (труднее понять порядок исполнения кода). Это также повышает вероятность возникновения ошибок, что самым непосредственным образом влияет на безопасность.  

>я также знаю, как eval работает.

Вот и объясните здесь, как работает eval, покажите глубину Ваших познаний в этом вопросе. А заодно приведите доказательства Ваших сомнений с прулинками. Пока пруфлинки привожу только я, от вас только пустая болтовня и переливание из пустого в порожнее.

Ответить | Правка | Наверх | Cообщить модератору

253. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 06-Апр-11, 14:53 
Итак еще раз. Данная дискуссия началась вот с этого вашего высказывания.

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

Которое я попросил вас обосновать. И которое позволило мне выразить сомнения в вашей компетентности.

Это было 4-го апреля, сегодня 6-е апреля, то есть вы гуглите уже 3-й день.
Ну и смотрим, что вы продолжаете отвечать.

Начнем для начала с ваших эпичных "пруфлинков", которые вы снова продолжаете мне подсовывать.

> А заодно приведите доказательства Ваших сомнений с прулинками. Пока пруфлинки привожу только я, от вас только пустая болтовня и переливание из пустого в порожнее.

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

А пока что вы мне приводите ссылки на всякие блоги и интернет-переписку. По-вашему любой блог и любая переписка в инете являются "пруфлинком"? Вот мы с вами тоже сейчас ведем переписку. Тогда следуя вашей же логике, я имел бы право указывать в качестве "пруфлинков" собственные посты. Абсурд.

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

Вот если вы их нашли - тогда прочитайте, разберитесь, и хотя бы с-копи-пастите высказывания, которые по-вашему могли бы являться ответом на поставленный вопрос.
Хотя вы уже попробовали с-копи-пастить, в одном из предыдущих ваших постов, и у вас это получилось не в тему, поскольку именно про "хакерские лазейки" там ничего нет. Там говорится про другое. И теперь уже видимо боитесь.

А еще лучше, вместо копи-паста, постараться объяснить это своими словами.
Помните, как в школе? "Прочитал - перескажи своими словами."
Кому-то технологии идут на пользу, а некоторых копи-паст отучает думать.

> Никто не может гарантировать полное отсутствие ошибок в коде. Достаточно лишь небольшой невнимательности, одной какой-либо забытой проверки
> А проверять всегда есть и много чего

Ну везде есть много чего проверять. Это относится абсолютно ко всему.
Ну проверяйте, блин, кто вам мешает проверять?
При чем здесь, спрашивается, Лу^W eval?

> Учитывая, что в PHP выполнение eval равноценно подстановке исполняемого кода, передаваемого в качестве аргумента, в исходный код, а также не слишком высокий средний уровень php программистов (весь смысл низкого порога вхождения в php состоит в удешевлении рабочей силы), совершенно очевидно, что eval - это заряженное ружье, висящее на стене и способное выстрелить в своего владельца.

Вы говорите про eval именно в PHP? Я уже сказал - может быть в PHP он действительно "является лазейкой для хакеров".

То есть по-вашему eval просто тупо эквивалентен копи-пасту кода из одного места в другое?
Тогда зачем eval нужен, если и так можно скопипастить.
Что именно вы называете "подстановкой кода"?
Каша.

> В защищенные песочницы, создающие "изолированное безопасное окружение", веры нет никакой, в одной java сколько с этим проблем, почти каждый минорный релиз исправляют. Известно также и то, что динамический код сложнее в отладке и сопровождении (труднее понять порядок исполнения кода). Это также повышает вероятность возникновения ошибок, что самым непосредственным образом влияет на безопасность.

При чем здесь опять "песочницы", "минорные релизы"?
Значит по-вашему динамический код сложнее. Так вы вообще призываете отказаться от динамического кода, или только от eval?
Опять каша.

>>я также знаю, как eval работает.
>
> Вот и объясните здесь, как работает eval, покажите глубину Ваших познаний в этом вопросе.

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

Почему это я вам должен объяснять. Я всего лишь высказал сомнение в ваших познаниях. А если вы сомневаетесь в моих - пожалуйста, это ваше право.

Вы просто хотите, чтобы я вас чему-то стал учить. А зачем мне это надо?

P.S. Еще раз, вопрос стоял о "хакерских лазейках" в eval, о которых вы сказали в начале, а не о каких-то других проблемах eval.

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

261. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от croster (ok), 06-Апр-11, 16:39 
>Так вы вообще призываете отказаться от динамического кода

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

Максимум, чего я смогу от Вас научиться - тупо троллить и выливать тонны грязи. На большее, увы, Вы не способны.
>Я уже сказал - может быть в PHP он действительно "является лазейкой для хакеров".

Слив защитан.

Ответить | Правка | К родителю #253 | Наверх | Cообщить модератору

262. "PHP-транслятор HipHop позволил Facebook использовать в..."  –2 +/
Сообщение от anonymous (??), 06-Апр-11, 17:06 
вообще-то diff блистательно повозил тебя мордой об навоз. и ты теперь стоишь весь в навозе и не можешь понять, откуда ж запах такой. а от тебя запах.
Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

314. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 07-Апр-11, 15:40 
Значит вы не просили, что бы я вас учил? Какое облегчение!

Только почему вы все время настаиваете, чтобы я вам разжевывал те материалы, которые вы находите, и ссылки на которые вы все время пытаетесь подсунуть?

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

Я нигде не говорил, что вы так говорили, я лишь предположил, что вы за это призываете, поскольку это следует из логики ваших высказываний.

> Известно также и то, что динамический код сложнее в отладке и сопровождении (труднее понять порядок исполнения кода). Это также повышает вероятность возникновения ошибок, что самым непосредственным образом влияет на безопасность.

Кому это известно, интересно? Что "динамический код сложнее в отладке и сопровождении", только вам? То есть вам "труднее понять порядок исполнения кода".

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

Ну вы сами все сказали про себя. А еще на меня обижаетесь.

Конечно, неудивительно, что в вашем исполнении каждое применение eval будет представлять "лазейку для хакеров".
(Я при этом по-прежнему ничего не заявляю об эффективности eval, и о том если ему какие-то альтернативы, но "лазейки для хакеров" в каждом его вызове - это очень эпично с вашей стороны.)

Кроме того. Вы намеренно оборвали мои слова в цитате, исказив тем самым смысл. Было так.

>> Значит по-вашему динамический код сложнее. Так вы вообще призываете отказаться от динамического кода, или только от eval?

Как видите смысл совсем другой.

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

Итак, ваше исходное заявление было следующим (дословно).

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

Уже четвертый день идет. Ну как? Вам удалось хотя бы с чем-то разобраться?

Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

101. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Аноним (-), 04-Апр-11, 19:29 
В MyCoolDatabaseClass->query () тоже много чего передается ). Методы борьбы, как и с SQL-инъекциями, те же: экранирование строк да placeholders
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

260. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 06-Апр-11, 16:36 
> eval — это вообще штука опасная. Каждый eval в коде — это
> потенциально лазейка для хакеров, которые смогут с его помощью выполнить свой
> код.

вот видно, что человек слышал о том, что «eval — это плохо», но почему именно плохо — не знает, увы.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

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

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




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

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