Как breeze.js обеспечивает безопасность и избегает раскрытия бизнес-логики

Мы рассматриваем возможность breeze js для создания корпоративных приложений.

Самое замечательное в том, что мы можем выполнять запросы прямо из клиентского браузера. Это позволяет создавать динамические запросы на основе ввода пользователя без загрузки ненужных данных. Я обнаружил, что с помощью Breeze мы можем создать бизнес-логику, которая сокращает перемещение / передачу данных на 1/10 или даже больше при использовании стратегии отложенной загрузки. используя такие запросы, как эти

Ура ветер !!!

Но как насчет безопасности Business Logic? Например, у нас может быть репозиторий, в котором мы можем скрывать, скрывать и скрывать нашу бизнес-логику; а затем используйте контроллеры веб-API MVC, чтобы просто выполнять вызовы этих классов C # репозитория. поэтому Breeze JavaScript общается с контроллером WebAPi, а контроллер WebApi обращается к репозиторию C #. Контроллеры всегда будут оставаться очень простыми и удобными для чтения, но в репозитории может быть много бизнес-логики для компании, использующей приложение. Так что, если хакер использует, например, консоль разработчика Google Chrome для проверки кода JavaScript, все, что он / она увидит, это такие вещи, как GetCustomers (), GetProductsForThisId (54). Там не так много информации, которую можно увидеть (или украсть). Потому что 90% бизнес-логики будет находиться в репозитории C # на сервере.

Как с этим справляется breeze.js?

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


breeze
person Oscar Agreda    schedule 01.12.2012    source источник

Ответы (3)


arrow_upward
44
arrow_downward

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

Ничто в Breeze не должно заставлять вас открывать бизнес-логику клиенту JavaScript. Вы можете (и должны) безопасно заблокировать такую ​​логику внутри своих репозиториев и / или методов контроллера.

Но мне сложно понять, как сами запросы клиентов являются той бизнес-логикой, которую нужно защищать. Чем опасен запрос для клиента, имя которого начинается с буквы «А»?

Вы можете справедливо побеспокоиться о запросе клиентов с чистой стоимостью> 100 000 долларов США. Но вина не в запросе. Ошибка будет заключаться в предоставлении такой информации о клиенте неавторизованным пользователям любыми средствами, будь то предложение Breeze where, добавленное к запросу, или вызов службы с именем GetCustomers ().

Место для блокировки неавторизованного доступа к клиентам находится на сервере, и вы можете сделать это так же легко внутри метода действия контроллера Breeze, возвращающего IQueryable, как и в вашем методе GetCustomer (). . В любом случае на вас ложится бремя по наложению необходимых ограничений безопасности на ваш контроллер и в методы, которые вы предоставляете.

Вы пишете контроллер. Вы пишете репозитории. У вас есть доступ к разрешениям пользователя. Вы полностью контролируете ситуацию с бескомпромиссной способностью раскрывать столько или меньше, сколько хотите.

FWIW, ваш Breeze EntityManager может вызывать методы обслуживания, которые не возвращают IQueryable<Customer>. Он может вызывать методы контроллера Web Api, такие как IEnumerable<Customer> GetCustomers() или Product GetProductForId(int id). На мой взгляд, вы потеряете гибкость средств запросов Breeze, не получив при этом никакой безопасности. Но это только мое мнение. Бриз поддержит ваш выбор, каким бы он ни был.

Я был бы счастлив попытаться ответить на более конкретный вопрос «как».

person Ward    schedule 03.12.2012
comment
Думаю, здесь стоит беспокоиться, если есть запросы, в которых строки не предназначены для пользователя. Он открывает банку с червями. Вероятно, больше проблем, если вы прикрепите это к существующему приложению. Но если вы разрабатываете свою систему с легкостью, я думаю, что запросы должны быть в порядке. - person Keith Nicholas; 05.09.2013
comment
Это может быть важным ограничением безопасности ... которое вы должны применять на сервере с полным и определенным знанием пользователя. Это работа, чтобы быть уверенным, независимо от того, как вы создаете свой серверный API. Breeze не особо помогает с такими вещами ... но и не мешает. - person Ward; 06.09.2013
comment
@ Уорд, я не понимаю твоего ответа. Я думаю, что средство запросов действительно подвергает риску, и я не вижу, как предотвратить этот риск. Допустим, сервер предоставляет точку входа для запроса неограниченного объекта, который связан с ограниченным объектом. Я напишу клиенту, чтобы он никогда не включал ограниченный объект, но злонамеренный клиент может запросить его. Как мне написать сервер, чтобы предотвратить это? Я полностью согласен с тем, что мне нужно наложить необходимые ограничения безопасности и обеспечить их соблюдение на сервере, но вопрос в том, как мне это сделать? Могу ли я анализировать запрос? Проверить каждую сущность результата запроса? - person steve; 15.09.2016

arrow_upward
2
arrow_downward

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

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

person user2968607    schedule 02.01.2014

arrow_upward
1
arrow_downward

Используя breeze.js, вы можете многое сделать. Прежде всего, проверьте мой ответ о безопасности здесь.

Как обрабатывать авторизацию с помощью Breeze JS?

Кроме того, хотя breeze.js можно использовать как обычный ORM на клиенте (что иногда может быть чрезвычайно полезно), вы должны сохранить свою бизнес-логику в контроллерах веб-API и предоставлять только необходимые данные с помощью запросов OData. Если вам нужна какая-либо логика манипулирования данными, вы должны сделать это на сервере, используя для этого специальный метод.

На клиенте должна присутствовать только логика пользовательского интерфейса, также учтите, что есть несколько последствий для производительности, если вы начнете выполнять несколько запросов непосредственно от клиента. Либо разверните граф сущности, чтобы загрузить больше результатов, либо используйте более специализированные методы, возвращающие объект. Бриз проанализирует результаты и с удовольствием поглотит сущности без каких-либо последствий.

person Chriss    schedule 02.06.2016