Долой backend! Все делаем на javascript в frontend.

[laimas]

Запросами должен управлять сервер, есть при этом права, нет ли таковых, это не важно. Клиент должен оперировать только данными, а не запросами. Хотите иметь дыру - пожалуйста, пишите SQL запросы непосредственно на клиенте и отдавайте их серверу на исполнение.

[ГеннадийС]

Вот об этом я и спросил в первом своём посте в эту тему. Чем опасно показывать структуру базы данных, хотя бы частично?

[laimas]

Чем опасно показывать структуру базы данных, хотя бы частично?

Код многих известных CMS (не берем Битрикс, он упакован) свободно доступен в сети. Естественно, что открытый код анализируется на уязвимости (это справедливо и к приложениям с открытым кодом) для дальнейшей их эксплуатации. Точно не помню, но вроде бы Джумлу взламывали "угадывая" префикс имен полей таблиц.

Вы владелец сайта, хост вам определил доступ к панели управления им - логин, пароль. Вы определяете пользователя FTP и БД, указывая логин и пароль. Именно по этому логину и паролю будет производится подключение к БД. Логин и пароль пользователя Федя, под которым он зарегистрировался SQL побоку. SQL также наплевать какие права вы определили для Феди, может к примеру только читать посты, или же удалять чужие.

Я атакующий, обычный пользователь, мне надо попотеть, чтобы в грамотно организованной безопасности пробить брешь. А тут такой подарок - мне разрешено на клиенте писать "SELECT ... FROM ...", не жизнь, а малина. Вы что думаете, что не определив мне права делать запрос к таблице Х обезопасили себя?

Я подставлю в запрос вывод представления БД, получу все что меня интересует, а пом уже нанесу удар. Если клиенту позволено делать все что ему вздумается, то о какой безопасности может идти речь?

Грамотно, это даже вывод SQL ошибок не делают, только в режиме отладки и кому эта отладка доступна. Если формы оперируют именами полей таблиц, то это только часть имени, другая часть известна только серверу. Любая информация по структурам таблиц, это пища для анализа атакуемому, и чем больше такой пищи, тем более обширна для него стратегия. А если еще код дырявый, то это вообще подарок.

Безопасность приложения, это долгий разговор, "спрятал от глаз структуру и все ОК" не есть защита. Ищите в сети и читайте, это очень обширный материал, ибо веб приложение, это клиент+сервер, и вопросы безопасности актуальны для обеих сторон.

[ГеннадийС]

Ладно. Остаюсь при своём мнении. Если в базе данных есть уязвимость, позволяющая хакеру получить ответ на select, то и на show он сможет получить ответ. Если доступ ограничен сервером, то знание структуры базы данных ничего не даст.

Разгрузка же серверов от лишней работы была бы полезной для владельцев сайтов. При этом улучшилась бы производительность серверов, можно было бы сэкономить на программистах, так как зарплаты у них высокие и лишние программисты это заметные затраты.

[laimas]

Ладно. Остаюсь при своём мнении.

Да на здоровье.

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

Вы просто не понимаете, что такое БД, отсюда у вас и "детские болезни".

[ГеннадийС]

Надеюсь меня не примут за троля.

Это правда, я не эксперт по базам данных. Но мне хватает знаний развернуть сервер базы данных, создать подходящую под задачу структуру базы данных, заполнить её данными. Хватает знаний написать интерфейс на javascript, с созданием, изменением, удалением и поиском.

Но имеются и пробелы в знаниях. Зашёл на форум и увидел эту тему. Она мне показалась интересной, поэтому я хотел обсудить её по существу.

[laimas]

Безопасность, это святая обязанность сервера. Что значит писать запросы на клиенте и с чего вдруг это разгрузит его? Это наоборот создает для него такие проблемы, что врагу не пожелаешь. Вы слишком поверхностно все это себе представляете, видимо отсюда такие неверные представления.

Выполнение того или иного средствами SQL зависит не от прав, а от привилегий. Нужно хорошо знать SQL язык, понимать последствия, чтобы даже добавлять пользователей БД с ограниченными привилегиями. Но давать клиенту писать запросы, тем самым лишая сервер выполнять обязанности "сторожевого пса", это смерти подобно.

А о "разгрузке сервера" в этом контексте можно не говорить, это просто глупости.

[ГеннадийС]

Мне уже приходится повторять. Я с самого начала упомянул, что кроме базы данных на сервере должен быть ограничитель доступа. Даже он может не иметь прав (привелегий) root. Ограничитель при поступлении запроса от клиентского javascript запрашивает из базы данных пароль пользователя и проверяет его. Если пароль совпадает, то ограничитель запрашивает права пользователя и ограничивает запрос в соответствие с правами. Дальше запрос выполняется, ответ базы данных отправляется клиенту.

[Nexus]

laimas,

Логин и пароль пользователя Федя, под которым он зарегистрировался SQL побоку.

SQL на привилегии Феди - пофиг, СУБД же не пофиг. Она не позволит Феде совершать действия, что ему не позволены.

Если sql будет выполняться от read-only пользователя, то что злоумышленник сможет сделать кроме сношения сервера БД?

[laimas]

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

А что такое "ограничитель доступа"? Нет привилегий root, это пользователь, а привилегия GRANT.

Причем тут вообще пользователи, если клиент формирует запрос?! Неужели не понятно, что именно это дыра?

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

Клиент, это терминал с монитором, а CPU, это как раз сервер. Не надо подменять понятие "производительность" глупостями. Пишут всякие валидаторы на клиенте, полагая что на этом все и заканчивается, и шлют мусор этот серверу, не делая на нем даже минимальной проверки.

Дожили, теперь клиент еще и запросы будет писать для сервера. Оказывается это такой тяжкий труд, что нужно это делать на клиенте, тем более, что это нисколечко не страшно. Кошмар, ей богу.

Делайте, что хотите. Трудно приводить доводу тому, кто не понимает. )