Comments 25
Насчёт вот этого
Я правильно понимаю, что исполняется это на клиенте и пользователи могут увидеть. Что эта пара даёт?
Backendless.initApp(«PUT-YOUR-APP-ID-HERE», «PUT-YOUR-JS-SECRET-KEY-HERE», «v1»);
Я правильно понимаю, что исполняется это на клиенте и пользователи могут увидеть. Что эта пара даёт?
Поддерживаю вопрос, не получиться ли так, что любой пользователь сможет выгружать любые данные?
Эта пара дает то, что с других СДК нельзя получить доступ к приложению, так как Secret Key для каждого разный. Если кто-то получит app ID и Secret Key, то он сможет выгрузить любые данные. Мы сейчас готовим к выходу такую фичу, где можно будет указать чтобы сервис работал только с разрешеными доменами и это повысит уровень безопасности.
Интересно как вы собираетесь этого добиться? Домен какбэ не связан с клиентским IP.
Cуществуют стандартные средства по контролю доступа в кросс-доменных ситуациях. Мы работаем над внедрением одного из них.
Какие кросс-доменные ситуации? Злоумышленник выбирает View-Source, видит ключ, посылает запросы с помощью cURL, подделывая referrer…
На здоровье, пусть смотрит сорс до опупения. Если в Бэкендлессе прописаны домены с которых скрипт может выполнять вызовы, то только такому скрипту будет предоставлен доступ.
Так домены или клиентские IP?
cURL с поддельным referer может сделать запрос?
cURL с поддельным referer может сделать запрос?
— домены и клиентские IP
— с cURL можно сделать запрос вот таким образом:
stackoverflow.com/questions/12173990/how-can-you-debug-cors-request-with-curl
— если в приложении не настроена security, т.е. данные открыты не для авторизированных пользователей, до доступ может получить кто угодно имея APP ID и SECRET KEY
— то же самое относится к любому сервис провайдеру
— с cURL можно сделать запрос вот таким образом:
stackoverflow.com/questions/12173990/how-can-you-debug-cors-request-with-curl
— если в приложении не настроена security, т.е. данные открыты не для авторизированных пользователей, до доступ может получить кто угодно имея APP ID и SECRET KEY
— то же самое относится к любому сервис провайдеру
Т.е. без белого списка клиентских IP, к данным может получить доступ кто угодно, посмотрев javascript код приложения?
Бэкендлесс предоставляет полные средства защиты данных для разработчика приложения. Если разработчик не закрыл доступ к данным для авторизированных пользователей и открыл свои исходники, понятное дело, что доступ к данным становится открыт.
Понятно, и при этом исходники он не может закрыть — они же JavaScript (обфускация не в счёт), так?
Т.е. без белого списка клиентских IP, к данным может получить доступ кто угодно, посмотрев javascript код приложения, так?
Т.е. без белого списка клиентских IP, к данным может получить доступ кто угодно, посмотрев javascript код приложения, так?
Т.е. без белого списка клиентских IP
про клиентские IP никто ничего не упоминал. Разговор идет о IP адресах и доменных именах ОТКУДА загружается приложение. Если после этого все еще не понятно о чем идет речь, пожалуйста ознакомьтесь со следующей информацией: en.wikipedia.org/wiki/Cross-origin_resource_sharing
Ну вообще-то Вы упоминали при клиентские IP habrahabr.ru/company/backendless/blog/184598/#comment_6443074
То есть по сути защиты от НСД нет, она лишь на уровне HTTP-заголовков, которые легко узнать и эмулировать множеством способов?
Извините за поздний ответ. Трекер глючит.
«Множество способов» это явное преувеличение, но при желании возможно эмулировать. Для защиты от этого предоставляется возможность блокировать запросы от неавторизированных пользователей для каждого сервиса у которого есть список АПИ операций. Для детального ознакомления, читайте здесь (в частности обратите внимание на роль NotAuthenticatedUser):
«Множество способов» это явное преувеличение, но при желании возможно эмулировать. Для защиты от этого предоставляется возможность блокировать запросы от неавторизированных пользователей для каждого сервиса у которого есть список АПИ операций. Для детального ознакомления, читайте здесь (в частности обратите внимание на роль NotAuthenticatedUser):
Я думаю в вашем сервисе конкретная дыра на уровне дизайна. И вы уходите от конкретных ответов (и задерживаете ответ на месяц). Вам уже несколько человек написало что дыра. То что вы в ответ пишите — BS.
Чтобы не быть голословным, давайте мы зарегистрируем приложение у нас на сервере, и разместим там данные. Если Вы сможете взломать сервис и получить эти данные, мы Вам выплатим $1000. Если нет, то все что Вы написали будет считаться BS.
Сначала распишите по-подробнее, какие настройки будут у приложения, кто будет иметь к нему доступ, с каких клиентских IP?
Так же актуально ли счас _всё_ что описано в статье, или что-то поменяли?
Так же актуально ли счас _всё_ что описано в статье, или что-то поменяли?
Сначала распишите по-подробнее, какие настройки будут у приложения, кто будет иметь к нему доступ, с каких клиентских IP?
Будет пример написанный на JavaScript. Пример будет работать на нашем сервере, в конфигурацию войдет CORS разрешение на запросы с нашего домена. В приложении будет форма логина. Когда пользователь заходит в приложение, показываются данные которые забираются через АПИ Дата Сервиса. Ваша задача получить эти же данные не восспользовавшись логином, тем самым подтвердив, что все, что мы написали, это BS.
Так же актуально ли счас _всё_ что описано в статье, или что-то поменяли?
Да, все написанное в статье и доке по прежнему актуально.
Нет, не подходит. Как на счёт такого?
Есть приложение — БД сотрудников, юзер — сотрудник. Оно выдаёт имена и зарплаты всех сотрудников чья должность ниже
должности юзера.
Любой юзер, залогинившийся в приложение, может посмотреть app id и secret, и
получить имена и зарплаты всех сотрудников вообще (с помощью cURL).
Есть приложение — БД сотрудников, юзер — сотрудник. Оно выдаёт имена и зарплаты всех сотрудников чья должность ниже
должности юзера.
Любой юзер, залогинившийся в приложение, может посмотреть app id и secret, и
получить имена и зарплаты всех сотрудников вообще (с помощью cURL).
Этот юз кейс расходится с вашими утверждением о секьюрности системы в связи с тем что secret key открыт. Если хотите продемонстрировать что систему можно взломать и получить обещанный нами гонорар, наш пример и предложение в силе, иначе просто сделайте вывод что не следует бросаться словами.
По поводу примера который Вы привели, реализация ограничения просмотра записей возможна через добавление бизнес правила в сервером коде. Мы планируем добавить эту возможность в ближайшем будущем.
По поводу примера который Вы привели, реализация ограничения просмотра записей возможна через добавление бизнес правила в сервером коде. Мы планируем добавить эту возможность в ближайшем будущем.
1. С чего это он расходится? Secret key открыт, кто угодно может читать записи от имени приложения+юзера. И писать записи.
2. Приз не нужен.
3. чуть-чуть усложнить условие, и придётся изобретать новые бизнес-правила.
Так или иначе у приложения будут данные которые могут быть доступны для чтения всем юзерам при некоторых условиях, так вот в итоге они будут доступны всем юзерам не зависимо от условий. Права доступа на чтение к каждому возможному sql запросу не приделать.
2. Приз не нужен.
3. чуть-чуть усложнить условие, и придётся изобретать новые бизнес-правила.
Так или иначе у приложения будут данные которые могут быть доступны для чтения всем юзерам при некоторых условиях, так вот в итоге они будут доступны всем юзерам не зависимо от условий. Права доступа на чтение к каждому возможному sql запросу не приделать.
Если кто-то получит app ID и Secret Key
А получить его может любой, кто зайдёт на страницу и нажмёт Ctrl+U?
Sign up to leave a comment.
Работаем с реляционными данными используя Backend-as-a-Service