Уже не первый раз сталкиваюсь с тупостью ненавистников ЯП с динамической типизацией, утверждающих, что они небезопасные. Как пример приводят sql-инъекции.
как один из примеров небезопасности — динамически-типизированные языки обычно имеют всякий там eval, которого обычно не имеют статически-типизированные языки. И вот, этот eval таки опасен.
статически-типизированные заставляют решать задачи так, чтобы на этот eval не рассчитывать. А этот eval — весьма опасен бывает в плане доступа к имеющемуся окружению. А без расчёта на eval алгоритмы обычно гораздо более "минималистичны", о меньшем надо заботиться. Наверное, криво сформулировал. Но, как пример, если сделать вычислялку арифметических выражений через eval и через лексер+парсер+эвалуатор, то в последнем случае будет безопаснее. Нельзя будет вычислить '1 + 2 * system("rm -rf /")'.
Да ты поехавший совсем! Этот eval запрещается сразу и навсегда, если тебе надо сделать евал, то в том же пейтоне, для вас, Козлов, virtualenv придумали! Какой нахуй rm -rf /, что ты несешь, вообще?
что надо — то и несу. Есть разные люди, и кто-то таки использует этот eval "для простоты", чисто потому, что нет нормальных способов решения задачи, например, индуктивных типов данных для парсинга и вычисления выражения, подаваемого на вход извне. Я видел примеры подобного подхода, когда использовали eval. Авторы кода, конечно, дебилы, но в статически-типизированном такого не вышло бы.
дваждую, почти нигде eval и релейтед хрень не преподносится как что-то годное, это просто инструмент, который основывается на базовых возможностях — как изменение констов в крестах
ну, скажем так, пока у меня лично только наоборот ощущение, что джава-программист (я так понимаю, в обоих ЯП речь идет о людях не думающих, т.к. умный человек в любом ЯП позаботится о валидации и подстановке входных данных) будет делать eval и считать его "безопасным т.к. у меня типизация входных параметров".
дебилы кормят eval входящими данными. Это — аргумент против динамической типизации, где eval натурально появляется, и за статическую типизацию, где eval сделать == тащить компилятор.
Можно написать безопасный унитипизированный ЯП, но де факто ты просто заебошишь систему типов и по-другому её назовёшь (самый яркий пример — mixin modules)
мои фантазии закончились тем, что это (наименее уёбищно для меня) можно сделать так: 1. запретить выполнять в рантайме sql-запросы, собранные из строк (только запросы специального типа) 2. разрешить создавать элементы этого типа только макросом (или еще как), до выполнения самого приложения (точнее, самого куска кода).
в результате, получим единственный способ параметризировать запрос — засунув параметры в специальное место (которое "сделает хорошо"). и получим запрет делать "where id=" + foo + ";", т.к. создать из этой строки SQLбильный тип данных будет нельзя.
кстати, пропессор тот же, в том же жж (и ветви обсуждения), как раз сделал нечто на х-ле, что якобы проблему решало, но тогда я х-ль не мог даже минимально читать, потому ничего не понял. надо бы вернуться и перечитать.
38 comments
recommend
bookmark
subscribe
Только статика! Только выведение типов!
А где тебя так угнетают?
было у пропессора в ЖЖ когда-то, а теперь вот http://juick.com/ArtemZ/2130779
Расскажите ему про FORTH, который управляет всякими космическими аппаратами.
ну, как раз космический корабль взламывать хрен кто будет, как по мне.
А было бы неплохо. Центрифуги для урана взломали же
:) не слышал о таком
Ну stuxnet же, ну!
Говорят, ЦРУ нанимало специалистов.
как один из примеров небезопасности — динамически-типизированные языки обычно имеют всякий там eval, которого обычно не имеют статически-типизированные языки. И вот, этот eval таки опасен.
ну детский сад же какой-то (именно с т.з. безопасностей всяких там).
Ну, это уж совсем пиздец, а не аргумент.
статически-типизированные заставляют решать задачи так, чтобы на этот eval не рассчитывать. А этот eval — весьма опасен бывает в плане доступа к имеющемуся окружению. А без расчёта на eval алгоритмы обычно гораздо более "минималистичны", о меньшем надо заботиться.
Наверное, криво сформулировал. Но, как пример, если сделать вычислялку арифметических выражений через eval и через лексер+парсер+эвалуатор, то в последнем случае будет безопаснее. Нельзя будет вычислить '1 + 2 * system("rm -rf /")'.
Да ты поехавший совсем! Этот eval запрещается сразу и навсегда, если тебе надо сделать евал, то в том же пейтоне, для вас, Козлов, virtualenv придумали! Какой нахуй rm -rf /, что ты несешь, вообще?
что надо — то и несу.
Есть разные люди, и кто-то таки использует этот eval "для простоты", чисто потому, что нет нормальных способов решения задачи, например, индуктивных типов данных для парсинга и вычисления выражения, подаваемого на вход извне.
Я видел примеры подобного подхода, когда использовали eval. Авторы кода, конечно, дебилы, но в статически-типизированном такого не вышло бы.
Ну, блин, если брать в расчет дебилов, то и на plain c можно такой код написать, что всех читающих сойдут с ума.
дваждую, почти нигде eval и релейтед хрень не преподносится как что-то годное, это просто инструмент, который основывается на базовых возможностях — как изменение констов в крестах
ну, скажем так, пока у меня лично только наоборот ощущение, что джава-программист (я так понимаю, в обоих ЯП речь идет о людях не думающих, т.к. умный человек в любом ЯП позаботится о валидации и подстановке входных данных) будет делать eval и считать его "безопасным т.к. у меня типизация входных параметров".
речь не про код, от чтения которого сходят с ума, а про код, который небезопасен в зависимости от входящих данных.
strcpy очень небезопасен.
дебилы кормят eval входящими данными. Это — аргумент против динамической типизации, где eval натурально появляется, и за статическую типизацию, где eval сделать == тащить компилятор.
поэтому не нужно использовать C.
Ну-ка, тогда поведай мне, о великий мастер, на чём же надо писать?
в зависимости от задачи.
Микроконтроллер, управляющий климатической установкой. С telnet-интерфейсом.
1. мозг есть? Вот и думай, на чём писать.
2. подобная задача — редкость.
3. дсл себе напиши, пёс.
поцоны, чо лучше: бить каждый раз макаку по рукам или научить не делать тупости?
linusk + какойнить легковесный scheme.
Можно написать безопасный унитипизированный ЯП, но де факто ты просто заебошишь систему типов и по-другому её назовёшь (самый яркий пример — mixin modules)
мои фантазии закончились тем, что это (наименее уёбищно для меня) можно сделать так:
1. запретить выполнять в рантайме sql-запросы, собранные из строк (только запросы специального типа)
2. разрешить создавать элементы этого типа только макросом (или еще как), до выполнения самого приложения (точнее, самого куска кода).
в результате, получим единственный способ параметризировать запрос — засунув параметры в специальное место (которое "сделает хорошо"). и получим запрет делать "where id=" + foo + ";", т.к. создать из этой строки SQLбильный тип данных будет нельзя.
кстати, пропессор тот же, в том же жж (и ветви обсуждения), как раз сделал нечто на х-ле, что якобы проблему решало, но тогда я х-ль не мог даже минимально читать, потому ничего не понял. надо бы вернуться и перечитать.
(еще не читал) http://nponeccop.livejournal.com/261537....
ртфм уже про н и др.
обосрался
а теперь обоссысь!
сделать так чтобы макака не могла делать тупости, очевидно же
Отлично. Подвёл итог дискуссии.
Я-то знаю. Собственно, strncpy и прочие snprintf и использую.
Однако, вон, товарищ не верит.
ограничить макаку в возможностях для всех инструментов? ахаха, ох вов
> ограничить
> макаку
> в возможностях