Как получить доступ к базе данных сайта
Содержание
- Что такое MySQL?
- Как узнать имя сервера, имя пользователя и пароль для подключения к базе данных MySQL?
- Логин и пароль
- Имя сервера
- Как изменить пароль базы данных?
- Полные подробные советы по оптимизации сайта и способах заработка на нем.
- Предотвращение SQL инъекций
- Как узнать возможна ли mysql инъекция на вашем сайте
- Как защищаться от mysql инъекций
- Защита файловой системы веб сервера
- Выводы
Что такое MySQL?
MySQL — одна из наиболее используемых систем управления базами данных: Что такое СУБД? MySQL применяется для хранения данных в Facebook, Youtube, Twitter, Wikipedia. А также базы данных используются популярными CMS.
Как это следует из названия, в данной библиотеке используется формальный язык SQL (Structured Query Language), на котором создаются запросы к базам данных. Основной инструмент для работы с базами данных MySQL — phpMyAdmin. Подробнее о работе в phpMyAdmin читайте в статье.
- полностью бесплатная СУБД;
- поддерживается большинством CMS;
- неограниченный многопользовательский режим;
- множество плагинов, облегчающих работу с данной СУБД;
- поддерживает различные типы таблиц (MyISAM, InnoDB, HEAP, MERGE);
- позволяет добавлять до 50 миллионов строк в таблицы.
- ограниченный функционал (не реализованы все возможности SQL);
- не подходит для масштабных проектов.
Базы данных на хостинге REG.RU доступны на всех тарифах, кроме Host-Lite и Win-Lite. Если у вас один из этих тарифов, для использования баз данных повысьте тариф.
Как узнать имя сервера, имя пользователя и пароль для подключения к базе данных MySQL?
Для подключения к базе данных MySQL и для входа в phpMyAdmin необходимо указывать логин и пароль пользователя базы данных.
Логин и пароль
После заказа услуги хостинга в панели управления уже присутствует база данных «u1234567_default» (u1234567 — ваш логин хостинга). Вы можете воспользоваться этой базой данных. Реквизиты доступа к ней приведены в информационном письме и в Личном кабинете в карточке услуги.
Логин и пароль услуги хостинга указаны в информационном письме, отправленном на контактный e-mail после заказа хостинга. Также данная информация продублирована в Личном кабинете. Авторизуйтесь на сайте REG.RU и кликните по нужной услуге хостинга. Логин и пароль указаны на вкладке «Доступы»:
Или вы можете создать новую базу данных. В этом случае имя базы, имя пользователя и пароль вы зададите самостоятельно. Если у вас уже есть созданный сайт на CMS, узнать пароль базы данных можно в конфигурационном файле сайта: Где CMS хранит настройки подключения к базе данных.
Имя сервера
В качестве сервера базы данных необходимо указывать «localhost».
Как изменить пароль базы данных?
Чтобы изменить пароль базы данных, войдите в вашу панель управления хостингом и следуйте соответствующей инструкции ниже:
Полные подробные советы по оптимизации сайта и способах заработка на нем.
Большинство систему управления сайтом таких как друпал, вордпресс, джумла, опен карт и другие по умолчанию защищены от большинства видов атак, но и в них время от времени находят дыры. Такие дыры надо латать и как можно быстрее. Про большинство самописных скриптов, написанных на коленках, вообще не хочется говорить. Наверняка там есть дыры, просто о них еще никто не знает…
Важная проблема взлома сайта — проседание сайта в поисковой выдаче, т.е. все ваши старания по продвижению сайта в поисковых системах могут оказаться бесполезными. Сайт вернется в топ только через некоторое время после возвращения сайта к нормальной работе.
В прошлый раз мы рассмотрели XSS и CSRF атаки на сайт и способы их предотвращения. Сегодня рассмотрим взлом сайта с помощью SQL инъекций и файловой системы, а так же методы защиты от таких посягательств на сайт.
Предотвращение SQL инъекций
Очень часто в адресной строке сайта размещаются параметры, влияющие тем или иным образом на содержание страницы. Например эти параметры могут быть значением, подставляемым в mysql запрос.
Например, ссылка вида: site.ru/index.php?page >
Злоумышленник, же как всегда может что-то подправить в адресной строке и получить дополнительные плюшки вплоть до логинов/паролей, удаления все базы данных или получения полного управления вашим сайтом.
Как узнать возможна ли mysql инъекция на вашем сайте
Самый простой вариант проверки – написать вместо site.ru/index.php?page >
Если параметр page >
Если вам показывается страница отличная от страницы с параметром page >
Как защищаться от mysql инъекций
Защита от sql инъекций – это фильтрация используемых в mysql запросе параметров и приведение их к необходимому виду. В нашем случае мы знаем, что параметр pageid должен быть числом, т.е. должен содержать только цифры. Значит перед выполнением mysql запроса мы должны проверить является ли параметр числом и если не является, то выдать ошибку или привести значение в число.
Только методичная и тщательная проверка вводимых данных и их фильтрация защитят от mysql инъекций. В помощь могут прийти уже разработанные классы для работы с базами данных.
Защита файловой системы веб сервера
Все скрипты, располагаемые на стороне веб сервера могу выполнять произвольные действия с файлами и папками. В результате потенциальный взломщик может попытаться либо использовать уже существующие скрипты, либо загрузить свои скрипты и выполнить их.
Основной способ защиты – ограничение прав доступа к папкам и файлам. Для папок по умолчанию в линукс системах ставятся стандартные права доступа (CHMOD) 644, для файлов – 755.
Если ваш скрипт в зависимости от параметра выполняет подключение или получение данных от различных файлов, то этот параметр обязательно нужно фильтровать. В противном случае злоумышленник (хакер) может получить полный или частичный доступ к файловой системе вашего сайта.
Выводы
Как вы уже удостоверились — защита от хакерских атак заключается в проверке (валидации) всех вводимых параметров.
Спецвыпуск: Хакер, номер #052, стр. 052-084-1
Что может сделать взломщик используя SQL injection
С каждым днем все больше скриптов используют базы данных, все больше хостингов доверяют пароли своих клиентов SQL-базам, все больше популярных сайтов переходит на публичные форумы и движки, работающие с MySQL. Но далеко не все ясно представляют себе, насколько опасным может быть непродуманное использование MySQL в скриптах.
Без знаний основ языка SQL трудно что-либо понять. Прежде всего разберемся, в чем заключается суть атаки типа SQL injection. К примеру, на атакуемом сервере стоит следующий PHP-скрипт, который на основе поля category_id делает выборку заголовков статей из таблицы articles и выводит их пользователю:
//подключаемся к MySQL
mysql_connect($dbhost, $dbuname, $dbpass) or die(mysql_error());
mysql_select_db($dbname) or die(mysql_error());
$result=mysql_query("SELECT article_ >
while( $out = mysql_fetch_array( $result)):
echo "Статья: ".$out[‘article_id’]." ".$out[‘article_title’]."
";
//выводим результат в виде списка
В переводе с языка MySQL запрос звучит так: "ВЫБРАТЬ ид_статей, заголовки_статей ИЗ таблицы_статей ГДЕ ид_категории равно $c >
Но что если пользователь — никакой не пользователь, а обыкновенный хакер? Тогда он сделает запрос http://serv.com/read.php?c >
Почему ошибка? Посмотрим, что запросил PHP у MySQL. Переменная $c (без кавычек в начале и в конце), то MySQL выдаст все записи, независимо от category_ >
Только что описанные действия как раз и называются SQL Injection — иньекция SQL-кода в запрос скрипта к MySQL. С помощью SQL Injection злоумышленник может получить доступ к тем данным, к которым имеет доступ уязвимый скрипт: пароли к закрытой части сайта, информация о кредитных картах, пароль к админке и т.д. Хакер при удачном для него стечении обстоятельств получит возможность выполнять команды на сервере.
Классический пример уязвимости типа SQL Injection — следующий запрос: SELECT * FROM admins WHERE login=’$login’ AND password=MD5(‘$password’).
Допустим, он будет проверять подлинность введенных реквизитов для входа в админскую часть какого-нибудь форума. Переменные $login и $password являются логином и паролем соответственно, и пользователь вводит их в HTML-форму. PHP посылает рассматриваемый запрос и проверяет: если количество возвращенных от MySQL записей больше нуля, то админ с такими реквизитами существует, а пользователь авторизуется, если иначе (таких записей нет и логин/пароль неверные) — пользователя направят на fsb.ru.
Как взломщик использует SQL Injection в этом случае? Все элементарно. Злоумышленнику требуется, чтобы MySQL вернул PHP-скрипту хотя бы одну запись. Значит, необходимо модифицировать запрос так, чтобы выбирались все записи таблицы независимо от правильности введенных реквизитов. Вспоминаем фишку с "OR 1". Кроме того, в MySQL, как и в любом языке, существуют комментарии. Комментарии обозначаются либо —комментарий (комментарий в конце строки), либо /*комментарий*/ (комментарий где угодно). Причем если второй тип комментария стоит в конце строки, закрывающий знак ‘*/’ необязателен. Итак, взломщик введет в качестве логина строку anyword’ OR 1/*, а в качестве пароля — anyword2. Тогда запрос принимает такой вид: SELECT * FROM admins WHERE login=’anyword’ OR 1/* AND password=MD5(‘anyword2’). А в переводе на человеческий язык: ВЫБРАТЬ все ИЗ таблицы_admins ГДЕ логин равен ‘anyword’ ИЛИ 1, а остальное воспринимается как комментарий, что позволяет отсечь ненужную часть запроса. В результате MySQL вернет все записи из таблицы admins даже независимо от того, существует админ с логином anyword или нет, и скрипт пропустит хакера в админку. Такая уязвимость была обнаружена, например, в Advanced Guestbook. Она позволяла войти в администраторскую часть не зная пароля и внутри нее читать файлы. Но SQL Injection этого типа обычно не позволяют злоумышленнику получить данные из таблицы.
Union и MySQL версии 4
Вернемся к скрипту получения заголовков статей. На самом деле он позволяет взломщику получить гораздо больше, чем список всех статей. Дело в том, что в MySQL версии 4 добавлен новый оператор — UNION, который используется для объединения результатов работы нескольких команд SELECT в один набор результатов. Например: SELECT article_id, article_title FROM articles UNION SELECT id, title FROM polls. В результате MySQL возвращает N записей, где N — количество записей из результата запроса слева плюс количество записей из результата запроса справа. И все это в том порядке, в каком идут запросы, отделяемые UNION.
Но существуют некоторые ограничения по использованию UNION:
1. число указываемых столбцов во всех запросах должно быть одинаковым: недопутимо, чтобы первый запрос выбирал, например, id, name, title, а второй только article_title;
2. типы указываемых столбцов одного запроса должны соответствовать типам указываемых столбцов остальных запросов: если в одном запросе выбираются столбцы типа INT, TEXT, TEXT, TINYTEXT, то и в остальных запросах должны выбираться столбцы такого же типа и в таком же порядке;
3. UNION не может идти после операторов LIMIT и ORDER.
Так как же UNION может стать пособником злоумышленника? В нашем скрипте присутствует запрос "SELECT article_ >
Допустим, цель хакера — получить логины и пароли всех авторов, которые могут добавлять статьи. Есть скрипт чтения списка статей http://serv.com/read.php?c >= 4. Почему именно так? Число 40000 — версия MySQL, записанная без точек. Если версия, которая стоит на сервере, больше или равна этому числу, то заключенный в /**/ код выполнится как часть запроса. В результате ни одна запись не подойдет под запрос и скрипт не вернет ничего. Зная версию MySQL, хакер сделает вывод о том, сработает фишка с UNION или нет. В случае если MySQL третьей версии, фишка работать не будет. В нашем случае MySQL >= 4 и злоумышленник все-таки воспользуется UNION.
Для начала взломщик составит верный UNION-запрос, то есть подберет действительное количество указываемых столбцов, которое бы совпало с количеством указываемых столбцов левого запроса (вспоминай правила работы с UNION). Хакер не имеет в распоряжении исходников скрипта (если, конечно, скрипт не публичный) и поэтому не знает, какой именно запрос шлет скрипт к MySQL. Придется подбирать вручную — модифицировать запрос вот таким образом: http://serv.com/read.php?c >
Посмотрим на модифицированный запрос от PHP к MySQL: SELECT article_ во втором столбце (SELECT+1,2). Другими словами, теперь, подставляя вместо ‘1’ и ‘2’ реальные имена столбцов из любой таблицы, можно будет заполучить их значения.
Составив верный SELECT+UNION запрос, хакер постарается подобрать название таблицы с нужными ему данными. Например, таблица с данными пользователей будет, скорее всего, называться users, Users, accounts, members, admins, а таблица с данными о кредитных картах — cc, orders, customers, orderlog и т.д. Для этого злоумышленник сделает следующий запрос: http://serv.com/read.php?c , иначе — выдаст ошибку. Так можно подбирать имена таблиц до тех пор, пока не будет найдена нужная.
В нашем случае "нужная" таблица – это authors, в которой хранятся данные об авторе: имя автора, его логин и пароль. Теперь задача хакера — подобрать правильные имена столбцов с нужными ему данными, чаще всего с логином и паролем. Имена столбцов он станет подбирать по аналогии с именем таблицы, то есть для логина столбец, скорее всего, будет называться login или username, а для пароля — password, passw и т.д. Запрос будет выглядеть так: http://serv.com/read.php?c >
Почему хакер не стал вставлять имя столбца вместо единицы? Ему нужна текстовая информация (логин, пароль), а в нашем случае в левом запросе SELECT на первом месте идет article_id, имеющий тип INT. Следовательно, в правом запросе хакер не может ставить на первое место имя столбца с текстовой информацией (правила UNION).
Итак, выполнив запрос http://serv.com/read.php?c >
UNION и нюансы
Теперь рассмотрим некоторые ситуации, в которых использование UNION затруднено по тем или иным причинам.
Левый запрос возвращает лишь числовое значение. Что-то вроде SELECT code FROM artciles WHERE >
Ситуация 2
SQL Injection находится в середине SQL-запроса. Например: SELECT code FROM artciles WHERE LIMIT 10. Для правильной эксплуатации хакер просто откомментирует идущий следом за Injection код, то есть к вставляемому коду добавит /* или —. Пробелы в запросе взломщик может заменить на /**/, что полезно в случае если скрипт фильтрует пробелы.
Случается и такое, что в PHP-коде подряд идет несколько SQL-запросов, подверженных Injection. И все они используют переменную, в которую злоумышленник вставляет SQL-код. Например (опускаю PHP):
$result=mysql_query("SELECT article_ >
//php code here
$result=mysql_query("SELECT article_name FROM articles where category_ >
//тут вывод результата
Это довольно неприятно для хакера, так как для первого запроса SQL Injection пройдет нормально, а для второго UNION — уже нет, так как количество запрашиваемых столбцов отличается. И если программист, писавший код, предусмотрел остановку скрипта в случае ошибки типа ". or die("Database error!")", то эксплуатация обычными методами невозможна, так как скрипт остановится раньше, чем будет выведет результат.
Скрипт выводит не весь результат запроса, а, например, только первую запись. И если хакер будет прямо пользоваться UNION, то скрипт выдаст только первую запись из ответа MySQL, а остальное отбросит, в том числе результат SQL Injection. Для того чтоб преодолеть все препятствия и на этом этапе, хакер передаст левому запросу такой параметр для WHERE, чтобы в ответ на него MySQL не вернул ни одной записи.
Например, есть такой запрос: SELECT name FROM authors WHERE >
Ситуация 5
Скрипт не выводит результат запроса. Например, есть скрипт, который выводит какие-либо статистические данные, например, количество авторов, принадлежащих к определенной группе. Причем количество записей он считает не с помощью MySQL-функции COUNT, а в самом скрипте. Скрипт шлет MySQL такой запрос: SELECT >
Допустим, скрипт возвращает что-то вроде "Найдено десять авторов в данной категории". В этом случае злоумышленник будет эксплуатировать SQL injection, конечно же, методом перебора символов! Например, хакеру надо получить пароль автора с >
Рассмотрим такой запрос: SELECT >109. Результатом запроса будет одна запись, если ASCII-код первого символа пароля больше 109, и ноль записей, если больше, либо равна. Итак, методом бинарного поиска нетрудно найти нужный символ. Почему хакер использует знаки "больше/меньше", а не "равно"? Если взломщику надо получить 32-символьный хэш пароля, ему придется делать примерно 32*25 запросов! Метод бинарного поиска позволяет сократить это число в два раза. Само собой, делать запросы хакер будет уже не руками, а с помощью скрипта, автоматизирующего перебор.
Несмотря на отсутствие в третьей версии оператора UNION, и из нее хакер сможет вытащить то, чем интересуется. В осуществлении этого замысла помогут подзапросы и перебор символов, но описание этого метода займет еще пару листов (которых мне не дали). Поэтому ищи статьи на эту тему на www.rst.void.ru (автор 1dt.w0lf) и www.securitylab.ru (автор Phoenix).
Правило №1. Фильтруй входные данные. Кавычку заменяй на слеш-кавычку(‘), слеш — на слеш-слеш. В PHP это делается или включением magic_quotes_gpc в php.ini, или функцией addslashes(). В Perl: $ >
Правило №2. Не дай кому не надо внедрить SQL-код! Заключай в кавычки все переменные в запросе. Например, SELECT * FROM users WHERE .
Правило №3. Отключи вывод сообщений об ошибках. Некоторые программисты, наоборот, делают так, что при ошибке скрипт выводит сообщение самого MySQL, или, еще ужасней, — ВЕСЬ SQL-запрос. Это предоставляет злодею дополнительную информацию о структуре базы и существенно облегчает эксплуатацию.
Правило №4. Никогда не разрешай скриптам работать с MySQL от root. Ничего хорошего не выйдет, если хакер получит доступ ко всей базе.
Правило №5. Запускай публичные скрипты от отдельного пользователя с отдельной базой. Неприятно будет, если какой-нибудь кидди, воспользовавшись 0day-дырой в форуме, получит доступ к базе с СС твоих клиентов.
Правило №6. Отключи MySQL-пользователю привилегию FILE — не дай хакеру записать в файл что-то вроде через MySQL.
Правило №7. Не называй таблицы и базы данных в соответствии с их назначением, чтоб утаить от чужих глаз настоящие названия. В публичных скриптах часто предоставляют возможность установить prefix для названия таблиц — устанавливай самый сложный. Если кто-нибудь и найдет SQL injection, то не сможет ее эксплуатировать.
Чаще всего уязвимости оставляют в тех запросах, параметры которых передаются через hidden формы в HTML и через cookies, видимо, из-за того, что они не видны пользователю и не так привлекают внимание злодеев.
Часто забывают про SQL Injection в функции Reply, о поиске сообщений пользователя в форумах, в репортах различных сервисов. В 80% WAP-сервисов SQL injection находят по десять штук в каждом скрипте (наверное, админы думают, что туда только через сотовые ходят). На самом деле многие недооценивают SQL Injection. Известен случай, когда обычная SQL injection в скрипте репорта привела к реальному руту на трех серверах и дампу гиговой базы. А всего-то SQL Injection…
inattack.ru/group_article/34.html
www.rst.void.ru/papers/sql-inj.txt
www.securitylab.ru/49424.html
www.securitylab.ru/49660.html
Все чаще администраторы получают возможности убедиться в том, что знания по безопасности запросов к MySQL не менее важны, чем эффективное использование этих запросов.
Защитить свою базу от хакеров можно – нужно только грамотно следовать определенным правилам по нейтрализации подобных атак.
С помощью UNION хакер может легко узнать пользователя, базу данных и версию MySQL, для чего используются функции user(), database() и version() соответственно. Взломщик просто сделает запрос типа SELECT user().
Даже если в обороне есть брешь, можно дезинформировать противника присваивая переменным нелогичные названия. Тогда их будет просто невозможно подобрать.
Чем ты больше знаешь о том, как ломают, тем проще предотвратить взлом.
Регулярно просматривай новостные сайты по безопасности, чтобы быть в курсе вновь изобретенных способов взлома и не допускать утечек ценной информации.