Skip to content

Безопасность единого кода для клиента и сервера

27/09/2010

Сегодня прочитал заметку Эрика Флоренцано о том что Node.js его разочаровывает. Вкратце: он надеялся что Node наконец позволит писать код на одном языке для клиента и для сервера, но на самом деле мы пишем два кода, причём на разных подмножествах языка JavaScript: обрезанная браузерно-совместимая версия для клиента и JavaScript с расширениями V8 для сервера. Эрик сокрушается что Node не стала (пока?) той революцией в веб-разработке, на которую он надеялся.

Что ж, в чём то я с ним согласен. Уже есть шаблонизаторы, работающие и на клиенте, и на сервере, их можно использовать. Построить сайт, отгружающий рендеринг на сервер, тоже теоретически можно. Но меня волнует другое. Всё, что выполняется на стороне пользователя — потенциально небезопасно. И если с шаблонизатором всё довольно просто (пользователь и так может изменять получающийся код с помощью хотя бы Firebug) то с валидацией и уж тем более с бизнес-логикой на стороне клиента ситуация не очень хорошая.

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

Проблема при отдаче кода шаблонизации: это может облегчить поиск XSS-уязвимостей, подобных той что недавно практиковалась на Твиттере. В классическом варианте этот поиск идёт практически вслепую (не считая открытых фреймворков и CMS).

Про перенос части бизнес-логики даже говорить не хочется. Эта опасность отличается от традиционной валидации/обработки части данных на JavaScript: одно дело если Вы знаете что код писался раздельно и на сервере скорее всего данные обработает другой валидатор, и другое дело когда Вы знаете что на сервере выполняется тот же самый код, который приходит в браузер. Конечно, security through obscurity не есть правильная модель безопасности, но иногда она лучше чем вообще ничего.

Основная проблема здесь, имхо, именно в частичном раскрытии исходного кода сайта, а не в том что пользователь сможет его как то менять (в консоли JavaScript и так можно выполнить что угодно). И получается, что мы встаём перед выбором. Либо мы используем единый код для сервера и клиента и открываем потенциальный вектор атаки на сайт/сервис, либо разделяем клиентскую и серверную часть и снова возвращаемся к «классической» модели, отгружая на клиент только самые простые и безопасные задачи. Я не утверждаю что надо отказаться от идеи единого кода — мне просто кажется что этот подход принесёт не меньше проблем, чем решений, причём проблем совершенно новых и незнакомых тем кто привык «делать сайты» по традиционной схеме.

4 комментария
  1. Сергей permalink

    > Основная проблема здесь, имхо, именно в частичном раскрытии
    > исходного кода сайта

    Сомнительная проблема, если честно. Устойчив к атакам не тот код, который скрывает свой алгоритм работы, а тот, кто использует надежные механизмы. Грубо говоря, если ты стесняешься своего кода, то это звоночек пересмотреть свой подход. Не зря ведь в опенсорс выкладывают исходники всяких монстров. И да, мы пишем разный код для клиента и сервера. А что тут такого? В первом случае мы используем браузерные функции, во втором — серверные. Меня это нисколько не смущает. Язык один и тот же. Не надо разводить философию! 🙂 Тем более, что код на сервере должен быть на ступеньку выше по количеству проверок и сложности. А Эрик Флоренцано пусть расстраивается дальше, не думаю, что он найдет что-то лучше 🙂

    • Понятно что надо писать надёжный код. Проблема в том что на каждые 10 строк такого кода можно найти 1000 строк написанных абы как. Если раньше их спасало хотя бы то что они были скрыты, то теперь это может измениться. А хорошим программистам по прежнему беспокоиться не о чем )

  2. Michel Beloshitsky permalink

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

    Вот тут можно поспорить. Security through obscurity конечно все ругают, но оно практично: если есть средней ценности ресурс, то этот защитный принцип вполне оправдает себя — ради средней ценности крякерам лень будет напрягать мозги. Не всегда же надо политические тайны от суперагентов защищать. Кроме того, к node.js это относится в кубе, потому что этот стандарты этого сервера отличаются тем, что отсутствуют и сильных компонентов, которые бы использовали поголовно нет, кроме самого node — на github кто во что горазд велосипеды делают.

    Вкратце: он надеялся что Node наконец позволит писать код на одном языке для клиента и для сервера, но на самом деле мы пишем два кода, причём на разных подмножествах языка JavaScript

    Ну так оно и есть такое, мой шаблонизатор, к примеру одинаково хорошо себя чувствует как в браузере, так и на сервере. Только нельзя же надеяться, что так будет всегда и со всем. Но code reuse есть.

    • Сергей permalink

      Code reuse в node.js больше, чем где-либо. Вот совсем недавно посмотрел видеозапись выступления Dav Glass (http://developer.yahoo.com/yui/theater/video.php?v=glass-node). Он показывает, как можно использовать YUI на сервере с такой же легкостью, как и на клиентской стороне. К тому же, особенность node.js позволяет использовать виджеты и примочки этой библиотеки даже в том случае, если у клиента отключен js и т.д. Да и вообще. За счет чего достигается безопасность? За счет использования надежных и проверенных временнем библиотек. YUI несомненно к таковым относится.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: