1

Как в MySQL запретить все команды, кроме заранее перечисленных? Если команды нету в списке, то MySQL её обрабатывать не будет.

  • 1
    вы, возможно, спрашивали про это? Т.е. при создании пользователя задаете ему какие привилегии ему доступны (либо указываете это уже после его создания) – BOPOH Dec 20 '15 at 16:38
  • 1
    Для этих целей, мне кажется, придумано ограничение прав пользователей на таблицы. – Владимир Мартьянов Dec 20 '15 at 16:38
  • Интересно. Но я спрашиваю с той целью, что бы было невозможно, провести SQL инъекцию. –  Dec 20 '15 at 16:40
  • 3
    @semiromid: Чтобы невозможно было провести SQL-инъекцию, нужно просто не склеивать строки от пользователя в команды SQL. Никогда. Читали: http://bobby-tables.com/ ? – VladD Dec 20 '15 at 16:41
  • VladD - можете показать пример как делать не надо, что бы я точно был уверен что понял Вас правильно? Читал похожее но не это. Почитаю , спасибо. –  Dec 20 '15 at 16:43
  • 3
    @semiromid, вы не понимаете ее суть. Если вы разрешите select (а он нужен, чтоыб данные выбирать) - инъекция уже возможна. Да, пользователь не сможет так грохнуть всю базу, либо изменить данные, но, например, залогиниться под чужим ником, либо получить нужные ему данные - он сможет. Если разрешите только обновление - инъекция уже возможна. Т.е. чтобы исключить инъекцию - надо выключить комп, спрятать его в каком-нибудь сейфе и забыть код доступа к нему, либо фильтровать пользовательськие данные и корректно их вставлять в sql – BOPOH Dec 20 '15 at 16:43
  • BOPOH - Вы правы, я суть очень слабо понимаю SQL инъекции. Только сегодня прочитал об этом, что её проводят методом склейки, или модификации, подставления своих данных в запрос. –  Dec 20 '15 at 16:46
  • BOPOH - а может быть если в SQL сделать свои процедуры и проверять на входные и выходные данные, было бы хорошо, как Вы считаете? –  Dec 20 '15 at 16:50
  • 1
    @semiromid: Ну почитайте же сайт! Там примеры на всех возможных языках. Или начните хотя бы отсюда: http://explainxkcd.com/327/ – VladD Dec 20 '15 at 16:51
  • VladD там русский язык для галочки –  Dec 20 '15 at 16:56
  • 1
    @semiromid, посмотрите примеры здесь: через bindParam вы корректно вставляете значение в ваш запрос, так что никакие инъекции не страшны. Дополнительно почитайте owasp и статью там же по предотвращению инъекции – BOPOH Dec 20 '15 at 16:57
  • BOPOH - а не корректно вставлять значения в SQL запрос, это как? –  Dec 20 '15 at 16:59
  • 1
    @semiromid, на русском можно почитать хотя бы документацию по php, например, это, там и описано что это, и приведены ссылки на возможные инструменты (например, это или это). не корректно вставлять значения - это так: $sql = "SELECT * FROM users WHERE login = $login AND password = $password" - т.е. как вы и сказали - простой склейкой без какой-либо обработки – BOPOH Dec 20 '15 at 17:02
  • Я читал как раз там на русском.Я первый день с инъекциями связан, просто. –  Dec 20 '15 at 17:03
  • BOPOH - Вы мне показали обычный SQL запрос, чем он не обычный? $sql = "SELECT * FROM users WHERE login = $login AND password = $password" . То что он в переменную $sql вставлен? –  Dec 20 '15 at 17:07
  • 2
    @semiromid, а тем, что его легко сломать, передав в $login значение 1' OR login = 'admin'; -- - и у меня в итоге sql будет вида SELECT * FROM users WHERE login = '1' OR login = 'admin'; -- AND password = '...'. Т.е. логиниться я буду либо как юзер с login = 1 (которого нет), либо (что вероятнее) как админ (-- - все что после него это комментарий). Т.е. на лицо инъекция. Если же через биндинг это делать, то все входные параметры будут экранированы, а значит будет поиск логина вида 1' OR login = 'admin'; -- – BOPOH Dec 20 '15 at 17:13
  • BOPOH - ППЦ, я ранее именно так и писал API. Тогда вообще ничего не понимаю как правильно. –  Dec 20 '15 at 17:16
  • BOPOH - использовать подготовленные выражения - выход? Ведь как без переменных данные в БД заносить когда данные все разные. –  Dec 20 '15 at 17:26
  • 3
    @semiromid, вы ссылки читали? там про это прямо написано: Параметры подготовленного запроса не требуется экранировать кавычками; драйвер это делает автоматически. Если в приложении используются исключительно подготовленные запросы, разработчик может быть уверен, что никаких SQL инъекций случиться не может (однако, если другие части текста запроса записаны с неэкранированными символами, SQL инъекции все же возможны; здесь речь идет именно о параметрах) – BOPOH Dec 20 '15 at 17:30
  • BOPOH - Я читал, и еще буде читать пока все не попробую и не пойму досконально. Но я подготовленные запросы еще не делал. Вот мой код: $result = mysqli_query($mys, "SELECT userid FROM users WHERE login='".$Login."' AND password='".$Password."'"); Но он расположен в функции, и глобальных переменных не имеет. Я так понимаю что он не правильный . Верно? Кстати, с наступающим Новым Годом Вас!) –  Dec 20 '15 at 17:37
  • 1
    @semiromid: Вы в принципе никогда не должны сами клеить SQL из строк. Разве что вы очень хорошо понимаете, что делаете. Если не совсем, то лучше не надо. – VladD Dec 20 '15 at 17:40
  • VladD - я не могу к сожалению понять что значит клеить (как можно без конкатенации), а как можно по другому это делать, если там именно переменные нужны, потому что данные все разные в БД нужно загружать. Разве что можно процедуры в самой MySQL написать, тогда клеить не придется, а использовать в PHP только процедуры для БД, которые написаны в самой MySQL. Так не, все равно переменные нужно будет использовать, но правда без конкатенации. –  Dec 20 '15 at 17:43
  • 2
    @semiromid: Клеить — это конкатенация. Вот именно конкатенация и есть причина SQL-инъекций. А как правильно делать, мы вам пытаемся втолковать в комментариях. – VladD Dec 20 '15 at 17:49
  • VladD - а как правильно такой запрос написать ? - $result = mysqli_query($mys, "SELECT userid FROM users WHERE login='".$Login."' AND password='".$Password."'"); –  Dec 20 '15 at 18:04
  • Параметры подготовленного запроса не требуется экранировать кавычками; драйвер это делает автоматически. Если в приложении используются исключительно подготовленные запросы, разработчик может быть уверен, что никаких SQL инъекций случиться не может (однако, если другие части текста запроса записаны с неэкранированными символами, SQL инъекции все же возможны; здесь речь идет именно о параметрах). –  Dec 20 '15 at 18:04
  • Скажите пожалуйста, правильно ли я понимаю, "Подготовленный запрос" - это и есть процедура в MySQL, написанная с самим запросом. А в PHP,например, только вызываем как бы шаблон, этой процедуры? –  Dec 20 '15 at 18:06
  • @semiromid: Вот тут есть примеры кода. Один из них: $stmt = $db->prepare('select userid from users where login = ? and password = ?'); Но я не спец, спросите лучше у спецов. – VladD Dec 20 '15 at 18:19
  • $stmt = $db->prepare('update people set name = ? where id = ?'); $stmt->bind_param('si',$name,$id); $stmt->execute(); - Это интересно. Ну что же, хех( Что бы быть хорошем веб-программистом, нужно быть хорошем хакером. Придется им стать . Я так не могу больше писать код, кода его можно взломать. –  Dec 20 '15 at 18:25
  • Я понял как 'это' делать. Хех( Плохо что это все есть. Неужели никого в этом мире не найдется что бы разработали нормальную систему без подобных дыр. –  Dec 20 '15 at 20:40

3 Answers3

3

В MySQL есть оператор GRANT. Нужно создать нового пользователя (не использовать root) и дать ему права на исполнения некоторых операторов.

Пример синтаксиса:

GRANT SELECT, INSERT ON *.* TO 'someuser'@'somehost';

в этом примере мы даём пользователю someuser права на исполнение операторов SELECT и INSERT во всех БД их таблицах, процедурах и функциях.

Так же существует оператор для того, чтобы забирать права у пользователя.

Пример синтаксиса:

REVOKE INSERT ON *.* FROM 'someuser'@'somehost';

в этом примере мы забираем право пользователя someuser на использование оператора INSERT во всех БД их таблицах, процедурах и функциях.

Подробнее о синтаксисе команд можете прочитать на официальном сайте MySQL:

  1. GRANT Syntax
  2. REVOKE Syntax
LEQADA
  • 5,185
2

Почитайте про prepared statements - отсылают в mysql отдельно запрос с плейсхолдерами, затем сами переменные. Грамотная защита от SQL-Injection Также советую http://habrahabr.ru/post/137664/ про pdo в частности.

Дух сообщества
  • 1
endless
  • 99
  • Если кажется, что на вопрос уже есть ответ, надо голосовать за закрытие, а не ставить ссылку – Ипатьев Dec 20 '15 at 18:15
  • Не вижу кнопки голосования за закрытие. Подскажите, где она. – endless Dec 20 '15 at 18:16
  • @endless: Около вопроса ссылка «закрыть» -> выбрать «этот вопрос уже был задан и имеет решение» – VladD Dec 20 '15 at 18:17
  • @VladD вероятно, мне она недоступна из-за недостаточной репутации. – endless Dec 20 '15 at 18:20
  • @endless: Окей, проголосовал за вас. – VladD Dec 20 '15 at 18:22
  • Можно нажать "тревога" -> "должен быть закрыт...", тогда вопрос попадет в очередь закрытия с нулем голосов. – zRrr Dec 20 '15 at 18:27
  • Это не отвечает на заданный вопрос! – LEQADA Dec 20 '15 at 23:46
1

Как запретить все команды, кроме заранее перечисленных?

Думаю, для этого надо руками парсить sql-запрос.
Вряд ли подобная функциональность существует сама по себе.
Впрочем, можно похимичить с правами - это не уровень команд, но идея похожа.

Но я спрашиваю с той целью, что бы было невозможно, провести SQL инъекцию.

А для этого просто не надо совать неэкранированные данные в запрос.
Команды тут не при чём.

Qwertiy
  • 123,725
  • экранирование спасение от конкатенации запросов (инъекций) отдельных видов. Интересно, а как долго этот баг уже в сети? Кто-то сильно веселился с этим в своё время. –  Dec 20 '15 at 22:06
  • @semiromid, кажется, я не понял мысль из комментария. Или есть разные виды экранирования? – Qwertiy Dec 20 '15 at 22:09
  • Можно не только экранировать как обычно, а еще и убирать вредные спец. символы. Или например, разрешить только определённые символы и уже проверять их на стороне MySQL в процедуре. Вообще я имел в виду, защита именно от этого вида атаки. –  Dec 20 '15 at 22:24
  • 2
    @semiromid: А чем экранирование обычных спецсимволов отличается от экранирования вредных спецсимволов? (И какие это — вредные?) – VladD Dec 20 '15 at 23:40
  • @semiromid нельзя – Ипатьев Dec 21 '15 at 05:09
  • VladD Я имел в виду. экранирование обычных спецсимволов - очистка мусора. Экранировать вредные спецсимволов - эти те символы которые могут нанести непосредственно вред кто их использует без экранирования. Или можно экранировать не только построчно, но и по символьно или некоторые символы вовсе убирать если они содержаться в сообщении. –  Dec 21 '15 at 09:59
  • 1
    @VladD, очень хочется дать ссылку, но не могу её найти... Про выкидывание символов. – Qwertiy Dec 21 '15 at 10:11