Клиентские сайты, основанные на JavaScript
Можно ли создавать динамические веб-приложения, используя клиентский JavaScript в качестве ключевой точки? Я не говорю о javascript на стороне сервера (например, об узле), я имею в виду обработку большей части сайта с помощью javascript: шаблонизацию, обработку форм и т. Д.
Конечно, короткий ответ "да, это возможно". Но моя главная задача - манипулирование данными в базе данных и их безопасность, когда база данных традиционно располагается на сервере. Клиентское приложение, управляемое JavaScript, в идеале должно общаться почти напрямую с базой данных. Я знаю, что Couchdb позволяет это, но как запретить пользователям отправлять запросы, предназначенные для просмотра данных, которые им нельзя разрешать видеть? Как справиться с проверкой ввода, учитывая, что основная проверка должна быть также на стороне клиента и так легко подделана?
Это кажется мне очень интересным, но не совсем выполнимым, но, возможно, есть решения, о которых я не знаю, или крошечные слои безопасности, которые нужно обернуть вокруг какой-то базы данных, или проекты, которые я игнорирую и т. Д.
Я знаю о приложениях CouchDb Standalone ( couchapp), это технология, близкая к той, к которой я стремлюсь, но она обеспечивает открытый подход, который делает его не идеальным для каждого сценария, который я могу придумать.
Любые предложения на эту тему приветствуются.
РЕДАКТИРОВАТЬ: как примеры требуются, подумайте на простом блоге. Я хочу показать последние пять постов на первой странице. Если кто-то "взломает" страницу очень простым способом, он может получить старые сообщения. Все в порядке. Но что, когда я хочу вставить новый пост? Если у javascript есть открытый доступ к базе данных, любой может также писать посты в моем блоге - я этого не хочу. Кроме того, любой может удалить мои посты или комментарии других пользователей - привилегия, которую я хочу. А что если я хочу избежать комментариев длиннее 500 символов, содержащих плохие слова? Опять же, будучи проверкой на стороне клиента, пользователи могут обойти это.
3 ответа
Во-первых, запуск кода на ваших клиентах для прямого доступа к базе данных звучит как проблема; кажется, что это идет вразрез с самой идеей сокрытия информации, которая так способствовала созданию более сложных систем.
Итак, я предполагаю, что большая часть этого - академическое упражнение.:)
Большинство систем централизованных баз данных сами имеют несколько пользователей или ролей; Как правило, мы используем одну "учетную запись пользователя" для каждого приложения и позволяем приложениям определять пользователей по-своему. (Это всегда беспокоило меня, всегда казалось, что роли администратора и пользователя также должны быть разделены в базе данных. Но я, кажется, один на мой взгляд.:)
Тем не менее, вы можете определить admin роль и user роль в вашей базе данных, GRANT SELECT привилегии для вашего user роль и GRANT SELECT, UPDATE, INSERT привилегии для вашего admin роль.
PostgreSQL по крайней мере имеет предопределенный PUBLIC что может занять место user; следующий пример скопирован с http://www.postgresql.org/docs/9.0/static/sql-grant.html:
GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
Правильная конфигурация pg_hba.conf файл может позволить admin пользователи, чтобы войти с определенных IP-адресов, и user пользователи могут входить из других мест, чтобы вы могли ограничить UPDATE а также INSERT только конкретные IP-адреса.
Теперь сложность заключается в написании клиентской библиотеки PostgreSQL на JavaScript.:) Честно говоря, я понятия не имею, являются ли виртуальные машины JavaScript на основе браузера достаточно гибкими, чтобы разрешить произвольную связь сокетов с удаленным хостом. (Учитывая то, как WebSockets были приняты от всей души, я предполагаю, что JavaScript очень сильно застрял в мире HTTP.)
Конечно, вы должны каким-то образом предоставлять свои HTML-страницы веб-браузерам, а это означает наличие HTTP-сервера. Вы могли бы также попросить этот сервер сидеть между клиентами и базой данных. И вы могли бы также выполнить некоторые задачи обработки на сервере, чтобы избежать отправки избыточных / ненужных данных клиентам также... именно в такой ситуации мы имеем сегодня.:)
Да, возможно иметь веб-приложение, которое сильно зависит от JavaScript; однако, в большинстве случаев этот слой просто дополнительный; не замена. Большинство разработчиков считают, что JavaScript - это просто удобный уровень, который делает транзакции "проще" для конечного пользователя, и вы могли бы сказать, что это лучший подход с точки зрения безопасности. JavaScript как "окончательный" инструмент для очистки податливых данных в надежной базе данных просто неэффективен; если вы не хотите обрабатывать все ваши данные как небезопасные и очищать их каждый раз, когда вы отображаете их и обрабатываете их из самого JavaScript.
Причудливые анимации, AJAX, проверки, расчеты, как правило, предназначены только для удобства, полагая, что иногда лучше использовать клиентский процессор, чем серверный. И, конечно же, тот факт, что сделать вещи "быстрее" - это то, чего все хотели достичь с момента подключения к интернету 56k.
С точки зрения безопасности, наличие логики безопасности без какого-либо дополнительного уровня защиты, доступного для конечного пользователя, просто безумие. Думайте о JavaScript как о дополнительной руке. То, что может читать JavaScript, может читать пользователь. Вы не будете хранить учетные данные базы данных или ключи хеширования паролей, не так ли? Тем более, что JavaScript может быть изменен в процессе работы с помощью отладчика, и практически любой запутанный код может быть преобразован в нечто читаемое человеком.
Оставляя эту вставку и "защищенные" данные в стороне, у вас не должно быть особых проблем с получением общедоступной информации, если ваш источник защищен.
Для javascript-интерфейса я бы порекомендовал Backbone.js, который даст вам прочную основу для организации и взаимодействия:
Backbone предоставляет структуру для приложений, насыщенных JavaScript, предоставляя моделям привязку значения ключа и настраиваемые события, коллекции с богатым API перечислимых функций, представления с декларативной обработкой событий и соединяет все это с существующим приложением через интерфейс RESTful JSON.
Единственное, что останется, это иметь тонкий слой, который может лежать поверх вашей БД (или даже самой БД) для очистки данных при вставке и для хранения / вычисления конфиденциальной информации, которая не может быть раскрыта в ЛЮБОЙ ситуации. клиент.
ОБНОВИТЬ
Пример блога
3 реальных требования, чтобы делать то, что вы хотите.
- Аутентификация (бэкэнд): это потребуется для доступа к БД, для удаления комментариев и т. Д.
- Проверка и дезинфекция (бэкэнд): ограничение количества символов, экранирование вредоносного кода, запрет слов.
- Обработка конфиденциальных данных (серверная часть): использование хэша для паролей...
Примечание. Вы можете в значительной степени обойти "проверку и дезинфекцию", считая все свои данные небезопасными при их отображении; как я уже говорил, крайне неэффективно, поскольку вам нужно, чтобы клиент каким-то образом анализировал его, чтобы сделать его безопасным; и все еще очень вероятно, что это будет обойдено. Два других действительно требуют, чтобы у вас был безопасный способ взаимодействия с вашим ценным БД.
Обычно: если ваш сервер не работает, ваш сервер не работает. И наоборот. XSS может нанести большой ущерб сайту, управляемому JavaScript (например, Facebook).
Невозможно общаться с базой данных на стороне клиента. В целях безопасности и проверки вы должны сделать это дважды. Один раз на стороне клиента, один раз на стороне сервера.
Все, что вы можете сделать на стороне клиента, может быть подделано злоумышленником. Проверка на стороне клиента в основном делается для удобства пользователя. Это проверка на стороне сервера, которая обеспечивает безопасность базы данных.