Взламывают, как защитить сайт?

Question

[UniCoom]

Здравствуйте! На сайте сделана функция, с помощью которой защищена админка. (Переадресация юзера, если права меньше требуемых)

function rights($rights){
global $http;
global $user;
if($user['rights'] < $rights) {
header('Location: '.$http.$_SERVER['SERVER_NAME']); exit;
}}

$user_id = isset($_COOKIE['uid']) ? fl($_COOKIE['uid']) : '';
$password = isset($_COOKIE['password']) ? fl($_COOKIE['password']) : '';

if($user_id && $password) {
$user = $base -> query('SELECT * FROM `users` WHERE `id` = "'.$user_id.'" AND `password` = "'.$password.'"') -> fetch_assoc();
} else {$user = false;}

Эту функцию каким-то образом обходят. Подскажите пути решения

Comments

[FanatPHP]

А где здесь функция? Я вижу два каких-то огрызка кода, которые непонятно как связаны друг с другом.

[Одиночка Айс]

id и пароль хранить в куках? Верх идиотизма...

[xfg]

Чтобы понять как защитить, нужно понять как взламывают. Чтобы понять как взламывают нужно смотреть логи веб-сервера так как точка входа в уязвимость вероятнее всего там. Если вы каким-то образом узнали, что кто-то гулял по вашей панели администратора, значит вам должны быть известны какие-то данные, например пользователь который гулял, дата когда гуляли, урл по которому гуляли. Этих данных достаточно, чтобы отфильтровать логи по дате, по пользователю, по урлу и проанализировать какие запросы были сделаны в это время, по такому-то урлу, таким-то пользователем. Как правило сразу всё станет очевидно и ясно где дыра, а сидеть и генерировать предположения дело довольно бесполезное.

Answer 1

[Марат Нагаев]

У вас в коде возможна sql инъекция.
'SELECT * FROM `users` WHERE `id` = "'.$user_id.'"
Инструкция как их избежать:
habr
php.net

Answer 2

[AUser0]

Ну тогда хотя-бы так:

function rights($rights){
global $http, $user;
if(!isset($user['rights']) OR empty($rights) OR $user['rights'] < $rights) {
header('Location: '.$http.$_SERVER['SERVER_NAME']); exit;
}
}

$user_id = isset($_COOKIE['uid']) ? fl($_COOKIE['uid']) : '';
$password = isset($_COOKIE['password']) ? fl($_COOKIE['password']) : '';

if(!empty($user_id) && !empty($password)) {
$user = $base->query('SELECT * FROM `users` WHERE `id` = "'.mysql_real_escape_string($user_id).'" AND `password` = "'.mysql_real_escape_string($password).'"')->fetch_assoc();
} else {$user = false;}

P.S. Но явно дыра где-то в другом месте.

Answer 3

[xmoonlight]

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

Comments

[Alex Wells]

Издеваешься? К говнокоду автора ты решил докинуть еще и свою говно-статью, в которой ты рекомендуешь фильтровать говно по хедерам, ограничивать доступ по айпишкам и бэкапится?

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

[xmoonlight]

Alex Wells, Слушаю твой говно-вариант.

[Alex Wells]

xmoonlight, как на счет обычной http basic авторизации? Как на счет выкинуть это гавно и сделать нормально? Как на счет поправить иньекции?

Не, лучше delete из хедеров профильтровать, ты чего)

[xmoonlight]

Alex Wells, ты прав: сразу после установки фильтрации хедеров, можно заняться рефакторингом как логики, так и как ты прально выразился:

выкинуть это гавно и сделать нормально

. Но как это сделать - автор пока не знает. А ты - знаешь?)

[Alex Wells]

xmoonlight, зачем фильтрировать хедеры то? Чем тебе это поможет? Если его кто-то ломает, то эту говно-защиту он в два клика обойдет, как бы ты не старался.

Начать с иньекции и basic авторизации. Это реально спасет на неопределенный термин. Если проект важен - нанять синиора, пусть все напишет с нуля. Если не важен - ну и шут с ним, хватит и basic'а.

[xmoonlight]

Alex Wells, В целом, согласен. Но чтобы полностью: надо поставить фильтры на запросы с моего сайта и этот код. Думаю, не реально подставить что-то в sql-запрос будет со стороны клиента. Надо тестить.

Answer 4

[Dimkin1447]

if($user['rights'] AND $user['rights'] < $rights OR !$user['rights'] )

Answer 5

[FanatPHP]

Вариант с SQL инъекцией выглядит конечно романтично, но я бы предположил, что в этом говнокоде всё ещё проще - $rights не определена, и следовательно при лобом значении $user проверка не срабаывает.

Comments

[UniCoom]

rights(число); используется значение

Answer 6

[SagePtr]

if ($user['rights'] < $rights)
Как это должно сработать в случае, если $user = false ?
Скорее всего, из-за ошибки это условие просто принимается как false, и проверка ваша проходит.
UPD: Всё-таки возвращает true, но я бы не рекомендовал полагаться на неявные преобразования типов, тем более, начиная с PHP 7.4 это генерирует Notice, а в будущих версиях однажды может быть убрано.

Comments

[UniCoom]

if(isset($user) && $user['rights'] < $rights) {
изменил

[SagePtr]

UniCoom, и чем ваше исправление поможет, если условие isset($user) всегда будет выполняться, т.к. вы присваиваете значение этой переменной в обоих случаях (при существовании юзера и при несуществовании).

[UniCoom]

SagePtr, так или это колхоз?

if($user !== 'false' && $user['rights'] < $rights) {

[FanatPHP]

Скорее всего, из-за ошибки это условие просто принимается как false

А проверить свои фантазии? Рук нету, клавиатура сломалась?

UniCoom, не надо слушать дядю, он не понимает, о чем говорит

[SagePtr]

UniCoom, вы определитесь, что вам нужно делать в случае false - выполнять редирект, или не выполнять его)

[Stalker_RED]

SagePtr, кстати, клиент может просто игнорировать редирект. Вся надежда на exit; :)

[SagePtr]

Stalker_RED, в коде автора exit есть, просто в одну строку зачем-то налеплен.
Очень воняет Поповым, скорее всего, автор обучался у него или у его адептов)

[SagePtr]

FanatPHP, лол, действительно, PHP позволяет невозбранно обратиться к несуществующему индексу переменной булевого типа, при этом для нормальных массивов он не позволяет)
Хорошо хотя бы от версии к версии разгребают бардак и периодически выкидывают подобный функционал, помечая как устаревший, а затем через несколько версий и целиком.

Answer 7

[flekst]

SQL-inj на виду
Простейшая cookie с
uid = "uid[админа]'; --"

Поломает проверку, закоментировав остаток запроса.

Решения уже отмечали - не используйте нефильтрованные данные, проверяйте их.