Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > PHP: Общие вопросы > Вопрос безопасности при авторизации


Автор: yngwie19 4.2.2010, 00:00
Здравствуйте, у меня вот какой вопрос. На своем сайте Я пытаюсь реализовать систему регистрации пользователей по которой у меня есть несколько вопросов касающихся безопасности. Я использую такую систему:
1) на главной странице index.php в самом начале Я запускаю session_start()
2) далее проверяю следующее:
Код

if(!isset($_POST['enter']))
            {
                echo "<form method='post' action=$_SERVER[SCRIPT_NAME]>
                        Логин:<input class='input' name='user' type='text'><br>
                        Пароль:<input class='input 'name='password' type='password'><br>
                        <input name='enter' type='submit' value='Войти'/>
                    </form>";
            }
else
      {
               // Здесь проверяю веденные пользователем данные
               $db=mysql_connect('host', login', 'password');
           mysql_select_db('db_name', $db);

               $res=mysql_query("SELECT * FROM users WHERE login='".$_POST['login']."'AND pass='".$_POST['pass']."'", $db);
           if(mysql_num_rows($res)!=1)//такого пользователя нет
         exit("Введены не верные логин или пароль");
               else{    //пользователь найден
        $_SESSION['login']=$_POST['login'];    //устанавливаем login & pass
        $_SESSION['pass']=$_POST['pass'];
              }


mysql_close();
       }


Подскажите есть ли в моем примере дыры с помощью которых хакер сможет взломать его. И вообще целесообразно ли использовать в работе сессии или их тоже можно легко обойти. Буду признателен за любую помощь!

Автор: Ипатьев 4.2.2010, 00:11
как минимум, SQL инъекция

Автор: nerezus 4.2.2010, 03:06
1) SQL-inj. У специалиста их не может быть впринципе. Стремись.
2) Не в том месте подключается СУБД.
3) Сессии хранятся на сервере.

Автор: yngwie19 4.2.2010, 08:19
Цитата(nerezus @  4.2.2010,  03:06 Найти цитируемый пост)
2) Не в том месте подключается СУБД.

подскажите пожалуйста где нужно соединяться с базой?

Цитата(nerezus @  4.2.2010,  03:06 Найти цитируемый пост)
3) Сессии хранятся на сервере. 

т.е мне нужно самому генерить хеш сессии и хранить в БД? а чем вариант session_start() не подходит? 

Автор: MoLeX 4.2.2010, 10:04
пароль в md5()
логин пропускаем через mysql_real_escape_string

Добавлено через 21 секунду
в запросе лучше указать LIMIT 1

Добавлено через 53 секунды
с СУБД надо подключаться в самом начале

Автор: Ипатьев 4.2.2010, 10:55
по поводу места подключения к бд я не понял. 
про сессии на сервере - это, как я понимаю, был туманный ответ на вопрос "можно ли обойти сессии". 
вопрос, впрочем, не менее туманный, и звучит как "можно ли обойти трамвай". 
что значит - "обойти"? что значит "тоже"? теоретически обойти можно все что угодно. 
что значит "можно обойти" - синоним "никто не использует сессии для авторизации"? а сами как думаете?

по поводу кода
1. большая просьба исправить синтаксис. смотреть на подсветку невозможно.
2. нет собственно работы с сессией. для чего в нее записываются логин и пароль?

Автор: yngwie19 4.2.2010, 18:24
нашел пример регистрации от Mal Halk http://forum.vingrad.ru/faq/topic-158301.html
посмотрите пожалуйста, есть ли у Вас замечания? это действительно безопасный подход или его следует усложнить (ну кроме пункта 8. где он сам объясняет как можно улучшить). Большое спасибо!

Автор: Ипатьев 4.2.2010, 19:40
код нужно не усложнять, а понимать

Автор: yngwie19 4.2.2010, 19:45
Ипатьев, Я имею в виду улучшить защиту. Ну а вообще подход правильный?

Автор: nginx 4.2.2010, 20:05
Цитата(MoLeX @  4.2.2010,  10:04 Найти цитируемый пост)
пароль в md5()

ЩИТО? Геноцид SHA1()  smile ?

Цитата(MoLeX @  4.2.2010,  10:04 Найти цитируемый пост)
в запросе лучше указать LIMIT 1

зачем? у него, как будто, результат другой будет?

Цитата(yngwie19 @  4.2.2010,  19:45 Найти цитируемый пост)
Ипатьев, Я имею в виду улучшить защиту. Ну а вообще подход правильный? 

нет, у тебя совершенно безграмотный код

см. мою тему:
http://forum.vingrad.ru/topic-283105/view-all.html

Автор: Simpliest 4.2.2010, 20:34
Цитата(nginx @  4.2.2010,  19:05 Найти цитируемый пост)
у тебя совершенно безграмотный код

см. мою тему:
http://forum.vingrad.ru/topic-283105/view-all.html

Бгг...
Во-первых, тема там не твоя.
Во-вторых, твой код в той теме от вышеприведеного отличается наличием mysql_real_escape_string в лучшую сторону, но при этом имеет абсолютно тупые проверки

Если был запрос такой
Код

WHERE login = '%s'", mysql_real_escape_string($_POST['login'])));

Код

elseif($res['login'] != $_POST['login'] 

Это еще зачем? Или это из серии 
Код

$flag = true;
if ($flag == true) // контрольный в голову

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

Автор: yngwie19 4.2.2010, 21:10
Simpliest, Подскажите пожалуйста не могли бы Вы дать ссылку на статью, где будет описан правильный(с точки зрения безопасности) подход к регистрации пользователей на сайте. А то в инете много разных подходов, а какой лучше выбрать и дальше не знаю.

Автор: nerezus 4.2.2010, 22:48
Давай ты лучше будешь писать свой алгоритм общими словами, а мы ответим.

Автор: nginx 4.2.2010, 22:54
Цитата(Simpliest @  4.2.2010,  20:34 Найти цитируемый пост)
Во-вторых, твой код в той теме от вышеприведеного отличается наличием mysql_real_escape_string в лучшую сторону, но при этом имеет абсолютно тупые проверки

пруф ор die();

Автор: yngwie19 5.2.2010, 00:01
nerezus, Мне пока сложно описать последовательность реализации данной задачи. На текущий момент Я ищу в инете различные варианты и пытаюсь разобраться какой наиболее безопаснее. Посматрите пожалуйста вот эту ссылку http://www.itseazy.ru/post46
как Вы считаете можно ли создать безопасную регистрацию используя его. Большое спасибо!

Автор: NLspieler 5.2.2010, 00:02
Цитата(yngwie19 @  4.2.2010,  21:10 Найти цитируемый пост)
Simpliest, Подскажите пожалуйста не могли бы Вы дать ссылку на статью, где будет описан правильный(с точки зрения безопасности) подход к регистрации пользователей на сайте. А то в инете много разных подходов, а какой лучше выбрать и дальше не знаю. 


Правильный подход постараюсь описать несколькими тезисами,
кто не согласен, высказать свои возмущения.

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

Иначе, нужно включить мозг и подумать.

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

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

3) Не хранить важной информации в куках, которые хранятся на машине пользователя и передаются с каждым запросом серверу.
Единственное, что позволяется хранить в куках - это идентификатор сессии.
Под каждый номер (идентификатор) сессии, на самом сервере сохраняется файл - сериализованный массив.
И именно в этом файле записан пароль пользователя (или хешь) и конечно же имя пользователя.

Но этого нам конечно же не достаточно для более менее серьёзной безопасности. 
Ведь злоумышленник может украсть куку с идентификатором сессии жертвы и войти на сервер под его именем.

Для этого нам нужен пункт 4, а именно дополнительная защита, путем проверки ip и браузера, с которого входит потенциальный пользователь.


4) При успешной авторизации пользователя. Рассчитать переменную хэшь и поместить ее в массив $_SESSION
Код

$hesh = md5 ( ИП_клиента . информация_о_браузере клиента . специальное_кодовое_слово_которое_ придумал_автор_программы ) ;
$_SESSION['hesh'] = $hesh ;


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

Для этого мы опять вычисляем хешь, и если он не совпадает с тем, который записан в $_SESSION['hesh'], то просим его ввести пароль и имя пользователя еще раз. 
Код

$hesh = md5 ( ИП_клиента . информация_о_браузере клиента . специальное_кодовое_слово_которое_ придумал_автор_программы ) ;
if ($_SESSION['hesh'] != $hesh)
{
    //Просим авторизоватся еще раз.
}


Это очень сильно повысит безопасность, по сравнению с обычный авторизацией через сессию, 
но тем не менее не обеспечит 100% безопасности, т.к. информацию, которая лётает по проводам, можно при очень огромном
желении перехватить.

5) Для этого остаётся последний метод борьбы - шифрование. Т.е. нужно организовать шифрование информации между браузером и сервером. Все серьёзные организации, связанные с деньгами делают это в обязательном порядке. Втроенный в браузеры алгоритм ширования называется SSL.


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

Автор: Simpliest 5.2.2010, 00:07
Цитата(yngwie19 @  4.2.2010,  20:10 Найти цитируемый пост)
Подскажите пожалуйста не могли бы Вы дать ссылку на статью, где будет описан правильный

К сожалению не могу, поскольку никогда не занимался поиском таких статей.

В целом подход верный. Нужно просто не упускать таких казалось бы мелочей как:
mysql_real_escape_string()
хранение пароля в виде хеша md5, sha1, а не в открытом виде.
обязательной проверки логина на допустимые символы 
обязательной проверки, что мы таки получили все необходимые параметры, а не только была ли нажата кнопка.
и т.д.

Цитата(nginx @  4.2.2010,  21:54 Найти цитируемый пост)
пруф ор die();

пруф чего? smile примера выше недостаточно?
Ты только что получил значение из базы где логин был условием.
Ты надеешься что полученное значение будет отличаться от логина в условии запроса? smile Или как?
Пароль у тебя хранится в открытом виде что тоже не есть хорошо.
Абсолютно не проверяется, а есть ли что-то вообще в $_POST - что неправильно, в отличии кода того же топикстартера. 

Автор: NLspieler 5.2.2010, 00:12
Прошу проверить мою писанину о безапасности на полноту и на дыры. 
Ведь тема действительно серьёзная и
не допускающая никаких холиваров, т.е. религиозных войн. 

Автор: Vasay 5.2.2010, 00:30
NLspieler, 

Цитата

Под каждый номер (идентификатор) сессии, на самом сервере сохраняется файл - сериализованный массив.
И именно в этом файле записан пароль пользователя (или хешь) и конечно же имя пользователя.


Зачем куда либо писать пароль (или его хешь) ?

Цитата

Для этого нам нужен пункт 4, а именно дополнительная защита, путем проверки ip и браузера, с которого входит потенциальный пользователь.


ip может быть динамическим, идентификатор браузера подделать очень просто.   Так что ИМХО пункт 4 бессмысленный. 




А вообще - желательно не забывать про существование ООП и MVC. Ни того ни другого нет ни в одном примере упомянутом в этой теме.

Автор: Simpliest 5.2.2010, 00:36
Цитата(Vasay @  4.2.2010,  23:30 Найти цитируемый пост)
ip может быть динамическим, идентификатор браузера подделать очень просто.   Так что ИМХО пункт 4 бессмысленный

Смысл таки определенный есть. Это еще одна дополнительная помеха взломщику.

Цитата(Vasay @  4.2.2010,  23:30 Найти цитируемый пост)
А вообще - желательно не забывать про существование ООП и MVC. Ни того ни другого нет ни в одном примере упомянутом в этой теме. 

Эм?
Каким образом это относится к безопасности авторизации? smile

Автор: Vasay 5.2.2010, 00:55
Цитата

Смысл таки определенный есть. Это еще одна дополнительная помеха взломщику.


При динамическом ip пользователя будет периодически выкидывать . Оно надо? 

Ну а информация о браузере не дает никакой доп защиты.


Цитата

Эм?
Каким образом это относится к безопасности авторизации? 

Разделяй и властвуй.  smile 

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

Как следствие, меньше ошибок - меньше уязвимостей.

Автор: Simpliest 5.2.2010, 01:22
Цитата(Vasay @  4.2.2010,  23:55 Найти цитируемый пост)
При динамическом ip пользователя будет периодически выкидывать . Оно надо? 

Это зависит от требований задачи.


Цитата(Vasay @  4.2.2010,  23:55 Найти цитируемый пост)
Разделяй и властвуй.   
....
Как следствие, меньше ошибок - меньше уязвимостей. 

Аааа, ну тогда могу порекомендовать еще подбирать хороших программистов smile они тоже делают меньше ошибок и меньше уязвимостей.
А так же не кодить с похмелья и т.д. smile

Но к теме топика это относится опосредованно.

Автор: Spiker 5.2.2010, 02:05
Лучше что-бы выкидывало, чем пользователя взломали.))
______________

У меня следующий подход, как вам?
Код

function checkUser()
{
    if (!isset($_SESSION['user_id'])) {
        header('Location: ' . WEB_ROOT . 'index.php?view=singin');
        exit;
    }
    
    if (isset($_GET['logout'])) {
        doLogout();
    }
}


Код

function doLogin()
{

    $errorMessage = '';
    
    $userName = $_POST['txtUserName'];
    $password = $_POST['txtPassword'];
    
    if ($userName == '') {
        $errorMessage = 'You must enter your username';
    } else if ($password == '') {
        $errorMessage = 'You must enter the password';
    } else {
        $sql = "SELECT user_id
                FROM users 
                WHERE user_login = '$userName' AND user_password = PASSWORD('$password')"; 
        $result = mysql_query("SET NAMES cp1251") or die(mysql_error());
        $result = mysql_query("SET CHARACTER SET cp1251") or die(mysql_error());
        $result = dbQuery($sql);
    
        if (dbNumRows($result) == 1) {
            $row = dbFetchAssoc($result);
            $_SESSION['user_id'] = $row['user_id'];
            
            $sql = "INSERT INTO last_log (date, user_id) VALUES(NOW(), '{$row['user_id']}')";
            dbQuery($sql);
        
            if (isset($_SESSION['login_return_url'])) {
                echo "<script>document.location='". $_SESSION['login_return_url'] ."'</script>";
                exit;
            } else {
                echo "<script>document.location='". WEB_ROOT ."admin/index.php'</script>";
                exit;
            }
        } else {
            $errorMessage = 'Wrong username or password';
        }        
            
    }
    
    return $errorMessage;
}


Код

function doLogout()
{
    if (isset($_SESSION['user_id'])) {
        unset($_SESSION['user_id']);
        session_unregister('user_id');
    }
        
    header('Location:' . WEB_ROOT . 'index.php?view=signin');
    exit;
}

Автор: Vasay 5.2.2010, 02:13
Simpliest, 

Цитата

Аааа, ну тогда могу порекомендовать еще подбирать хороших программистов smile они тоже делают меньше ошибок и меньше уязвимостей.
А так же не кодить с похмелья и т.д. smile

Но к теме топика это относится опосредованно.


Да нет - напрямую.  Человек учится, так пускай учится мыслить объектно, пускай учится разбивать приложение на слои.

Идеология должна быть примерно такой:

Есть сущность пользователя. Класс UserEntity cо свойствами id, userName, userHashPasswd, userEMail.....
Есть DAO в котором осуществляется вся работа с БД связанная с юзером. Класс UserDao с методами saveUser(), getUserById, getUserByName, getUserByNameAndPasswd.....

Есть классы контроллеров (контроллер для регистрации пользователя, контроллер для логина).

Могут быть командные объекты для представления POST запросов в виде объектов. Вспомогательные классы (валидаторы и тд....)

Могут быть менеджеры, но для начала можно и без них.

Добавлено через 7 минут и 14 секунд
Цитата

Лучше что-бы выкидывало, чем пользователя взломали.))


Ок. Давай посмотрим когда человек может получить id сессии. Тогда когда он либо имеет доступ к компьютеру, а соответственно и к его браузеру и к его ip.

Или когда он мониторит трафик. А соответственно в данном случае он может спокойно отмониторить и пароль. Особенно, если его придется вводить часто.

Защита тут только шифрование канала.

Автор: Spiker 5.2.2010, 02:22
а что же тогда делать? надо все на сервере хранить.
Весь канал что-ли шифровать?

Автор: Simpliest 5.2.2010, 03:22
Цитата(Vasay @  5.2.2010,  01:13 Найти цитируемый пост)
Да нет - напрямую.  Человек учится, так пускай учится мыслить объектно, пускай учится разбивать приложение на слои.

Я тебя понимаю, но так же понимаю, что все это скопом сразу не влазит в одну голову smile
Поэтому постепенность и последовательность.

Spiker, 
Уже писали, для особо тяжелых случаев используется SSL

Но в особо тяжелых случаях и это не панацея smile

Автор: NLspieler 5.2.2010, 03:33
Spiker,
покажи или расскажи, что у тебя за сайт.
Скорее всего, твоего подхода к безопасности будет полностью достаточно. 

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

Цитата

ip может быть динамическим, идентификатор браузера подделать очень просто.   Так что ИМХО пункт 4 бессмысленный


Ну слава богу, что только 4 пункт бессмысленный, 
хотя на самом деле он не такой и беесмысленный.

Проведем такой мысленный эксперимент.

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


Допустим, что взломщик удалось встроится в провод и он теперь может видеть, какой трафик проходит между сервером и потенцильаной жертвой.
Он обнаруживает, что жертва передаёт определенный id-сессии. 
Наш взломщик пытается авторизоватся на сайте при помощи этого идентификатора, 

но
сервер, обнаружив, что у него другой ip и даже другой браузер, и что хеши не сходятся, мирно просит его ввести логин и пароль.
короче, такой метод не взлома не действует. Пусть user_agent и можно подобрать, но как подобрать нужный ip?
Я, если честно, не знаю. И мне кажется, что это не возможно, кроме нескольких редких исключений.

Кроме того, взломщик же не знает, что ему нужно отослать одновременно правильный user_agent и правильный ip? 
Он же не знает исходный код.


Но конечно, же отсутствие пятого пункта (шифрования) практически полностью убивает пользу от описанного четвертого.


Но даже если есть даже шифрование, то дыры все равно остаются. 

Ведь если злоумышленник мониторит трафик, то он спокойно сможет подменить публичные пароли на свои. Если интересно, опишу этот процесс более подробнее.


Короче, делаю вывод, что никакой абсолютной безопасности не существует. Можно только достигнуть безопасность порядка 99,99%, но
стопроцентая не возможна впринципе. 

Автор: MoLeX 5.2.2010, 07:12
Цитата(nginx @  4.2.2010,  20:05 Найти цитируемый пост)
ЩИТО? Геноцид SHA1()

каждый использует то что ему роднее и привычные, разницы так таковой нету!


Цитата(nginx @  4.2.2010,  20:05 Найти цитируемый пост)
зачем? у него, как будто, результат другой будет?

хотя бы для того чтобы:
1. БД не продолжала искать по таблице, после того как нашла уже одну запись
2. при безграмотном кодинге бывает что на один и тот же логин принадлежит N пользователям, в этом случае его конструкция не пройдет
Код

if(mysql_num_rows($res)!=1)



Цитата(nginx @  4.2.2010,  20:05 Найти цитируемый пост)
см. мою тему:
http://forum.vingrad.ru/topic-283105/view-all.html

 smile  smile  smile 
два запроса!!!


yngwie19 если тебе не важна красота формы авторизации то можешь использовать вот это
Код

header('WWW-Authenticate: Basic realm="Auth"');
header('HTTP/1.0 401 Unauthorized');
// $_SERVER['PHP_AUTH_PW']
// $_SERVER['PHP_AUTH_USER']

Автор: yngwie19 5.2.2010, 08:29
Ребят спасибо Вам всем большое за то что столько времени уделили моему вопросу. Я думаю, что Я найду для себя правильный путь решения моей задачи. Единственное что бы Я хотел у Вас спросить это про использование SSL. Подскажите толковое руководство по нему. И вообще человек, который создал эту тему (т.е Я) сможет это реализовать? или тут нужны серьезные знания? Поскольку Я смотрю что все крупные сайты используют SSL.

Автор: Ипатьев 5.2.2010, 11:41
Вообще, я бы начинал не с авторизации.
Ведь дыра в работе с SQL к собственно авторизации не относится. 
Сначала надо осваивать элементарные вещи, "кирпичики", из которых строится веб-приложение. Работа с базой, куками. Строкамии, почтой.
Авторизация - это уже здание, которое строится из этих кирпичиков. Если их не знать, ксли они будут пустые внутри - здание развалится. Даже если на форуме покажут чертежи супер-проекта.

Автор: Vasay 5.2.2010, 12:58
Цитата(Simpliest @  5.2.2010,  03:22 Найти цитируемый пост)

Я тебя понимаю, но так же понимаю, что все это скопом сразу не влазит в одну голову smile
Поэтому постепенность и последовательность.



Согласен, потому,  прежде чем что-то писать, надо выучить язык, неотъемлемой  частью которого  является ООП.

Надо знать что такое http, как строятся запросы и ответы, что такое GET, POST, сессия, куки....

Надо разобраться с подходом к построению web приложений (основным, на данный момент является MVC).

Потом, решив написать что-то для web, не изобретать велосипед, а воспользоваться web-фрэймворком, но понимая, как он работает.

Автор: MoLeX 5.2.2010, 13:27
Цитата(Vasay @  5.2.2010,  12:58 Найти цитируемый пост)
надо выучить язык, неотъемлемой  частью которого  является ООП.

неужели?!


Цитата(Vasay @  5.2.2010,  12:58 Найти цитируемый пост)
Потом, решив написать что-то для web, не изобретать велосипед, а воспользоваться web-фрэймворком, но понимая, как он работает.

 smile 
они не всегда хороши

Автор: Vasay 5.2.2010, 13:55
Цитата(MoLeX @  5.2.2010,  13:27 Найти цитируемый пост)
неужели?!


Вы считаете, что человек не знающий ООП в php может называться php программистом? 
Интересно, найдет ли он нормальную работу, или сможет разобраться в коде какого-нибудь современного продукта (большинство из которых используют ООП и MVC )
К тому же рано или поздно ему все равно придется работать с библиотеками написанными в объектном стиле. 

Цитата

они не всегда хороши 

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

Автор: nerezus 5.2.2010, 14:11
Цитата

неужели?!
 Представьте проект на пару сотен килобайт(хотя бы) без ООП. Я уж не говорю о чем-то крупном.

Автор: MoLeX 5.2.2010, 14:19
представил и?!...

Добавлено @ 14:20
могу даже пару ссылок привести крупных проектов (не свои)

Автор: Spiker 5.2.2010, 19:25
я эту авторизацию везде пихаю, либо это коммерческих проект или что то похожее на сайт "анекдотов"... 

я могу проект показать, весит за 10-20мб без никакого ООП))

Автор: Vasay 5.2.2010, 20:02
Spiker, 


Цитата

я эту авторизацию везде пихаю, либо это коммерческих проект или что то похожее на сайт "анекдотов"... 


У тебя возможна инъекция SQL в doLogin()

Автор: Spiker 5.2.2010, 20:08
все данные тогда надо через mysql_real_escape_string пропускать
Код

    $userName = mysql_real_escape_string($_POST['txtUserName']);
    $password = mysql_real_escape_string($_POST['txtPassword']);


Добавлено через 13 секунд
все данные тогда надо через mysql_real_escape_string пропускать
Код

    $userName = mysql_real_escape_string($_POST['txtUserName']);
    $password = mysql_real_escape_string($_POST['txtPassword']);

Автор: NLspieler 5.2.2010, 20:38
Для пропуска всех нужных переменных из пост через mysql_real_escape_string, я использую слудующий код.

Код


$felder = 'name login pass' ; //Тут список всех ключей post через пробел, которые нужно принять, обработать и записать в соответствующие по названию переменные.

$felder = explode (' ' , $felder) ; //Превращаем список в массив, хотя можно сразу пропустить первый шаг и задать на этом месте массив из названий полей

foreach ($felder as $feld)
{
    $$feld = mysql_real_escape_string($_POST[$feld]) ; //Можно пропустить и через другие необходимые функции
}

/*
На выходе получаем переменные

$name , $login , $pass уже пропущенные через mysql_real_escape_string и готовые к применению
*/

Автор: Spiker 5.2.2010, 20:44
по-моему еще кроме кодировки сессии больше не чего нельзя добавить?

Автор: yngwie19 5.2.2010, 22:23
Цитата(Spiker @  5.2.2010,  20:08 Найти цитируемый пост)
все данные тогда надо через mysql_real_escape_string пропускать

а htmlspecialchars() не подходит?

Автор: bars80080 5.2.2010, 23:25
Цитата(yngwie19 @  5.2.2010,  21:23 Найти цитируемый пост)
а htmlspecialchars() не подходит? 

а что по вашему делает эта функция? каково её назначение?

Автор: yngwie19 6.2.2010, 00:22
Преобразует специальные символы в HTML сущности

Автор: Spiker 6.2.2010, 00:33
зачем это для авторизации?
это для других вещей, к примеру для проверки - что написал пользователь в гостевой книге.
логин и пароль в мд5 закатал и проверяй))

Автор: Sentox 6.2.2010, 10:19
NLspieler, 
Цитата

Допустим, что взломщик удалось встроится в провод и он теперь может видеть, какой трафик проходит между сервером и потенцильаной жертвой.
Он обнаруживает, что жертва передаёт определенный id-сессии. 
Наш взломщик пытается авторизоватся на сайте при помощи этого идентификатора, 

но
сервер, обнаружив, что у него другой ip и даже другой браузер, и что хеши не сходятся, мирно просит его ввести логин и пароль.
короче, такой метод не взлома не действует. Пусть user_agent и можно подобрать, но как подобрать нужный ip?
Я, если честно, не знаю. И мне кажется, что это не возможно, кроме нескольких редких исключений.


Ну и что ... большинство путей проходят через прокси сервера!!!
И твоя система хватает IP именно прокси через который работает и хацкер, ну а агента это уже понятно ....
Всё каюк ... 
Это проблема много сложнее.

Добавлено @ 10:24
Vasay, 
Цитата

Идеология должна быть примерно такой:

Есть сущность пользователя. Класс UserEntity cо свойствами id, userName, userHashPasswd, userEMail.....
Есть DAO в котором осуществляется вся работа с БД связанная с юзером. Класс UserDao с методами saveUser(), getUserById, getUserByName, getUserByNameAndPasswd.....

Есть классы контроллеров (контроллер для регистрации пользователя, контроллер для логина).

Могут быть командные объекты для представления POST запросов в виде объектов. Вспомогательные классы (валидаторы и тд....)


Угу, а потом появляются системы с классами в 20 -30 методов с кучей свойств, не соблюдая основные правила ООА/П.
И думаешь а где здесь всё таки ООП  smile 

Это я к тому , что прав  Simpliest, всему своё время.

Добавлено @ 10:32
yngwie19, 
Цитата

Мне пока сложно описать последовательность реализации данной задачи.


Основная проблема новичков, начни с анализа требований и последовательности, в особенности начни с карандаша и листа бумаги.
"Форест Гамп прекрасно выразил эту идею, когда сказал: 
    Если вы не знаете куда идете, то вы вряд ли туда дойдете." (Разработка и управление требованиями Практическое руководство пользователя )

Автор: nerezus 6.2.2010, 11:50
Цитата

могу даже пару ссылок привести крупных проектов (не свои)
 Лучше на код.
Тут один из наших постоянных посетителей занимался рефакторингом переписыванием одного из ссамых популярных сайтов рунета.  Который был структурным.

Автор: Vasay 6.2.2010, 18:16
Цитата

Угу, а потом появляются системы с классами в 20 -30 методов с кучей свойств, не соблюдая основные правила ООА/П.
И думаешь а где здесь всё таки ООП  smile 

Это я к тому , что прав  Simpliest, всему своё время.


По-моему, прежде чем крыть крышу, нужно построить фундамент.  

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

Автор: yngwie19 6.2.2010, 19:06
подскажите мне пожалуйста вот на таком примере. У меня есть форма: 
Код

<form name="addNewUser" action="addNewUser.php" method="POST" enctype="multipart/form-data">
<input type="text" name="name" maxlength="30"/>
<input type="password" name="passw" maxlength="30"/>
<input type="password" name="confirm" maxlength="30"/>
<input type="text" name="email" maxlength="60"/>
<input type="text" name="icq" maxlength="9"/>
<input type="text" name="url" maxlength="60"/>
<input type="file" name="avatar"/> 
<input type="submit" name="submitForm" value="Зарегестрировать"/>'; 


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

Автор: Spiker 6.2.2010, 23:56
preg_match, htmlspecialchar и mysql_real_escape_string

Автор: yngwie19 7.2.2010, 08:30
Spiker, этого достаточно?

Автор: NLspieler 7.2.2010, 09:12
yngwie19,
рассказываю по шагам.
Во-первых, на многих хостингах включены волшебные слэши.
Т.е. строка "привет" превращается в \"привет\"
что бы избежать этого, нужно либо отключить эту опцию, либо пропускать все принимаемые данные, через функцию 
Код

$_POST['passw'] = stripslashes ($_POST['passw']) ;
 
Кроме того, некоторые поля нужно пропускать при приеме через функцию trim, которая удаляет пробелы в начале и в конце.

preg_match позволяет проверить на правильность емейл, url, да и любые другие поля на соответствие правильному шаблону.


Через mysql_real_escape_string обязательно нужно пропустить все данные (ну почти все), которые попадут потом в sql запрос.

Пароль в БД лучше вообще не писать, а записать md5-hesh.

Насчет htmlspecialchar не знаю. По-моему, ее нужно применять, когда в БД вносятся текстовые комментарии.
Впринципе и другие данные можно через нее пропустить. Но вопрос это спорный.


К безопасности из приведенного списка относится только mysql_real_escape_string и в некоторой степени md5-хешь для пароля
 

Автор: bars80080 7.2.2010, 13:27
Цитата(NLspieler @  7.2.2010,  08:12 Найти цитируемый пост)
Насчет htmlspecialchar не знаю. По-моему, ее нужно применять, когда в БД вносятся текстовые комментарии.

нет, назначение функции - форматировать специальные символы, применяемые в хтмл в соответствующие сущности. то есть её надо применять для вывода текста в браузер. к БД она никакого отношения не имеет

Автор: Spiker 7.2.2010, 14:38
я лично ereg использую, у меня проверка на любой тип поля есть... как то не охота все переписовать))

Автор: yngwie19 7.2.2010, 17:08
Цитата(NLspieler @  7.2.2010,  09:12 Найти цитируемый пост)
Пароль в БД лучше вообще не писать, а записать md5-hesh.

т.е так:
Код

$passw =  md5($_POST['passw']);

и все?

Добавлено через 5 минут и 15 секунд
Цитата(NLspieler @  7.2.2010,  09:12 Найти цитируемый пост)
Т.е. строка "привет" превращается в \"привет\"

а если проверять вводимые данные по такому шаблону:
Код

preg_match("/^\w{3,}$/",$_POST['login'])

то тогда Вам вариант можно пропустить?

Автор: NLspieler 7.2.2010, 20:17
Цитата(yngwie19 @  7.2.2010,  17:08 Найти цитируемый пост)
Код

$passw =  md5($_POST['passw']);

и все?

Да, этого достаточно. 
Но нужно еще и при попытке пользователя войти на сайт, сравнивать не пароль, а его md5.


md5($string) всегда равен md5($string)  не зависимо от значения $string. 
Но получить из md5 хеша исходное значение практически не возвомжно.

Таким образом мы получаем следующие плюсы: 
1) никто не сможет узнать пароль пользователя, даже имея в распоряжении базу данных.
2) md хэш всегда имеет одинаковую длинну, таким образом можно экономить место в БД, прописав в соответствующее поле эту длинну.



Цитата(Spiker @  7.2.2010,  14:38 Найти цитируемый пост)
я лично ereg использую

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


Цитата(yngwie19 @  7.2.2010,  17:08 Найти цитируемый пост)
то тогда Вам вариант можно пропустить?

Если данные принимаются из формы с лишними (волшебными слэшами), то избавлятся от них нужно в обязательном порядке.

Цитата(bars80080 @  7.2.2010,  13:27 Найти цитируемый пост)

нет, назначение функции - форматировать специальные символы, применяемые в хтмл в соответствующие сущности. то есть её надо применять для вывода текста в браузер. к БД она никакого отношения не имеет

Разумется, никакого отношения к БД она не имеет, но в ряде случаев она просто не заменима.
Можно конечно записывать в БД данные как есть, а можно записать в БД уже обработанные данные, готовые к выводу.
Таким образом достигнется небольшая экономия мощностей процессора. Так как данные нужно будет пропускать через эту функцию только один раз.

Автор: nerezus 7.2.2010, 20:58
Цитата

но в ряде случаев она просто не заменима.
 А иногда незаменимы другие функции. Но как и эта, они не относятся к теме. Совсем.

Цитата

а можно записать в БД уже обработанные данные, готовые к выводу.
 Если у вас простая геста и больше, чем к выводу в html эти данные не нужны - то да.

Цитата

Таким образом достигнется небольшая экономия мощностей процессора.
 А теперь расскажите, какие ;) При том условии, что структура данной ф-ии примитивна и оверхед не будет замечен.

Автор: Spiker 7.2.2010, 23:56
ктото пробовал делать следущее?
Код

$passw =  md5(PASSWORD(md5(PASSWORD($_POST['passw']))));

Такое вряд-ли кто-то взломает... до тех пор пока хакер не в курсе сколько раз все было зашифровано.

Автор: MoLeX 8.2.2010, 06:30
Spiker, и зачем? лучше использовать соль и все

Автор: yngwie19 8.2.2010, 08:11
Spiker, тогда уж так:
Код

$passw = md5(md5(PASSWORD($_POST['passw'])));

Автор: MoLeX 8.2.2010, 10:09
Код

$passw = '';
for( ;; )
    $passw = md5($_POST['passw'].$passw);


 smile  smile  smile

Добавлено через 1 минуту и 2 секунды
P.S. может хватить страдать ерундой? если уж такие параноики то следует написать свой алгоритм хеширования и радоваться жизни

Автор: sTa1kEr 8.2.2010, 10:24
Цитата(Spiker @  8.2.2010,  00:56 Найти цитируемый пост)
$passw =  md5(PASSWORD(md5(PASSWORD($_POST['passw']))));

Это делается намного проще
Код

define('SECRET_KEY', 'random key');
$hash = md5($password.SECRET_KEY);

Автор: Vasay 8.2.2010, 10:50
yngwie19, 
Spiker, 

что такое, по-вашему md5 и зачем он нужен?

Автор: Spiker 8.2.2010, 12:54
md5 128-битный алгоритм хеширования
если получить пароль в мд5, то это не проблема его расшифровать

Автор: yngwie19 8.2.2010, 18:40
Цитата(Spiker @  8.2.2010,  12:54 Найти цитируемый пост)
md5 128-битный алгоритм хеширования
если получить пароль в мд5, то это не проблема его расшифровать

 smile 

Автор: MoLeX 8.2.2010, 18:50
Цитата(Spiker @  8.2.2010,  12:54 Найти цитируемый пост)
если получить пароль в мд5, то это не проблема его расшифровать

пожалуйста, расшифруй (а вернее подбери, так как хэш нельзя расшифровать)
Цитата(md5)

f68cb9f45c7395a04747db9781186afd


Добавлено через 35 секунд
пасс: 16 символов

Автор: Spiker 8.2.2010, 19:53
можно по легче задачуsmile)
16 цифр через чур)
этого хеша не было в базе данных

Автор: Vasay 8.2.2010, 20:04
Цитата

md5 128-битный алгоритм хеширования
если получить пароль в мд5, то это не проблема его расшифровать



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

Автор: IgorIV 8.2.2010, 20:20
Цитата(Spiker @  8.2.2010,  19:53 Найти цитируемый пост)
можно по легче задачу)

а не надо было начинать. Назвался груздем, полезай в кузов. Ждем пароль....

Можно и так.
Код

$hash = md5($password.$nick);

Автор: Spiker 8.2.2010, 20:39
есть ресурсы с базой мд5 и расшифрованным мд5.
но которые я просматривал имели базы с мд5 до 8-12 букв\цифр.
поэтому я данный хеш не как не узнаю разве что если MoLeX сам его не скажет.
если раз-читывать на обычного пользователя то вряд-ли у него будет длинный и трудный пароль.

Автор: yngwie19 8.2.2010, 20:48
ребят а подскажите, использование массива $_SESSION является безопасным? его используют? или есть что-то лучше?

Автор: bars80080 8.2.2010, 20:55
Цитата(Spiker @  8.2.2010,  19:39 Найти цитируемый пост)
если раз-читывать на обычного пользователя то вряд-ли у него будет длинный и трудный пароль.

зато стоит своеобразным способом поставить свою соль (не забывая её менять от проекта к проекту), и все эти базы идут лесом

Автор: MoLeX 9.2.2010, 07:16
Spiker, так вот уважаемый, не каких извращенных методов не надо использовать (мы же не в кащея играем у которого игла в яйце, яйцо в ... и т.д.)

вполне хватает:
Код

echo md5("LOGIN\nPASSWORD");


Добавлено через 35 секунд
P.S. f68cb9f45c7395a04747db9781186afd == Rt!s8Gd$5&0-L+93

Добавлено через 2 минуты и 27 секунд
Цитата(Spiker @  8.2.2010,  19:53 Найти цитируемый пост)
16 цифр через чур)

да нет нормальный, я на работе запрещаю использовать пароли меньше 10 символов, и всякий подбор сводиться к нулю

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)