Безопасность в Php
 

Начал изучать PHP, но чую, без посторонней помощи не обойдётся :)

Есть три варианта работы с административными скриптами:
1. Все они находятся в папке, к которой доступ ограничивается через .htaccess/.htpasswd. Сами скрипты прав доступа не проверяют.
2. .htaccess/.htpasswd отсутствуют, но скрипты требуют сначала ввести логин/пароль, после чего можно будет работать.
3. .htaccess/.htpasswd отсутствуют. Ввод пароля требуется, но одновременно с сеансом. Поясню. Предположим, есть форма для добавления новости на сайт. В варианте 2 потребуется сначала в отдельной формочке ввести логин/пароль, нажать "Вход", а потом спокойно добавлять новости безо всяких проверок. В варианте 3 сразу открывается форма добавления новости, но помимо неё есть ещё дополнительное поле для пароля, и новость будет добавлена только если введённый пароль верен.

Варианты 2 и 3 ещё имеют подварианты:
а) пароль проверяется напрямую (if $pwd == "password")
б) проверка пароля идёт через хэш-код.

Вопрос: какие уязвимости есть во всех этих вариантах и как с ними бороться?

кривые рукизастрелиться

PS: Юзай 1 способ. Дешево и сердито. Во 2 и 3 если на что и следует обратить внимание, так это на register_globals.

RaZEr
Ok, остановлюсь на первом (он мне сразу понравился как самый простой :yees: )
Можно поподробнее насчёт кривых рук? Не исключаю, что относительно PHP мои руки обладают сим печально известным свойством... Какие тут бывают грабли? Можно пару ссылочек подбросить, где подобные ситуации описаны? По Яндексам да Гуглям, конечно, немного пошуровал, но мало чего полезного смог найти.

В 1-ом способе оступиться особо негде. Он тем и хорош, что прост и надежен.

на самом деле все зависит от реализации(2 и 3 вариант). если ты сделаешь нормальное хранение, проверку и сохранение во время сессии логина, пароля и события "logging in", то нет проблем.

можно например так:

храним логин и пассворд в бд(только не в открытом виде).

проверяем логин и пассворд на самой первой странице.
если все совпало, заводим идентификатор юзера(например уникальное число типа int подлинее, например: 44855928592835982582). далее везде, где "ходит" залогинившийся юзер, во всех формах имеется скрытый input с этим числом. при каждом действии проверяется вошел ли он(путем проверки числа из формы и числа из базы), если совпадает, то все ок, если нет, то exit.
при "выходе", число из базы стирается(при следующем заходе оно будет уже другое).
естественно, что скрытый input подставляется динамически(ведь он каждый раз будет разным). а если человек попытается подделать число путем правки html, то у него ничего не выйдет, т.к. он не знает правильного числа в базе.

второй вариант:

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

такой подход менее надежен, но более прост в реализации.

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

Мое имхо: Лучше пользовать как например сделано в vBulletin3 ... при регистрации пароль отправляется не прямум текстом, а захэшированный MD5 с помощью JavaScript .... далее выдается пользователю в куки ID сессии и юзер работает ... после определенного времени неактивности ID сессии на сервере обнуляется ...

Sheryld
Примерно понял, спасибо. На будущее запомню.

ГеныЧ
Ну пароль-то я сгенерю... А вот передачей его на сервер я не управляю, вся обработка .htaccess/.htpasswd не мной делается, а по всей видимости, Апачем, то бишь настраивается хостером...

С помощью .htaccess/.htpasswd логин:пароль на сервер при каждом запросе передается практически напрямую ... кодируется base64, но разве это шифрование? ... :)

Надежней всего шифрованый канал связи иметь (https если позволяет) ... :)

ГеныЧ
Ну блин, я ж не правительственные секреты пересылать собираюсь! :biggrin: Захотят взломать - взломают. А то ещё страничку новостей по https редактировать... Ещё и шифрование 4096-битным ключом сделать... :ржать:

Раз уж мы решили углубиться в полемику абсолютных защит, то вот такая интересная задачка: Есть у нас пароли в базе, которые необходимо высылать на почтовый адрес пользователя в случае необходимости (забыл). Генерировать случайные пароли нельзя, так как злоумышленнику может стать известен e-mail пользователя и он может многократно инициировать такую смену пароля. Как результат нужно высылать текущий пароль, но при этом существует вероятность утечки данных из базы (сервер сломали), которая может подорвать безопасность всей системы. Какие мысли?

RaZEr
Мне кажется, выходом мог бы стать вариант с активацией:
При запросе клиенту шлётся письмо с уникальным сгенерённым числом. Клиент идёт по определённому адресу, вводит это число (или сразу в письме готовая ссылка), и только после этого генерится новый пароль и отсылается клиенту.

Ага, это мысль.

Если злоумышленник, пользуется чужим мылом, то какая разница, пароль отослать или ссылку с активацией?

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

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

Потому и используется почтовыми службами, что нельзя выслать подтверждение на e-mail.

Это называется - защита от баловства :) Но штука неприятная.
Кстать, сейчас модняво делать ники и логины. Например на форуме ник VIRT, а для авторизаци используется логин йцукен+пароль. Злоумышленнику надо знать логин который, в отличии от ника, нигде не публикуется.

Я конечно незнаю как сейчас, и особенно не в курсе что модно, а что - нет, но логин отдельно от ника я делал всегда. Делается это не столько в целях безопасности, сколько в целях удобства. У многих ники непростые, далеко непростые, и набирать их при каждой авторизации не оч. удобно, не говоря уже про inline HTTP-auth, где все спец. символы прийдется перевести в коды. А что касаемо борьбы с перебиральщиками, то для этого разумней использовать стандартные средства борьбы с роботами - картиночку с циферками и поле ввода.

Я делал очень сложную защиту. Мускулы нету ваще. Всеч ерез конф файл идет + md5

Тоесть пользователь вводит логин и пароль и попадает в свой аккаунт. И данные переходят через ?totot=totototototototototototototototo
И все а в ссчлках стоит просто QUERY_STRING
Получается взломать невозможно, если тока не хакнуть конфиг файл. Естественно в аккаунте стоит проверка isset, if Тоесть простое сравнение. Конечно попотеть пришлось, но работает нормально. Главное права правильные ставить

PASHAN
А от банального брутфорса эта очень сложная защита как защищалась?
Это что, поподробнее нельзя? md5-hash данных или session id?

Это md5 + некоторые значения переменных
точнее to=tototo&to2=to2to2to2

А поподробней можно о бональном брутфорсе? Че-то не встречался. Что это?

brute force - грубая сила(с англ.)
в интернете это вид атаки, который подразумевает чаще всего способ атаки "в лоб". пример: взлом пароля, путем простого перебора.

PASHAN
Получение действующего логина/пароля путем прямого перебора вариантов

брутфорс - это прямой перебор паролей.
http://adelaida.by.ru/manual/program...fors_perl.html

И если честно, я так и не понял, в чем же заключается эта "сложность защиты"???

И как с этим брутфорсом лучше всего бороться?? Но я прочитал ту статью! И там написано что это для папки тока. например Admin
Но в моем случае папка не запароленная. А просто идет сравнение с conf.php

PASHAN
Простейшие варианты борьбы:
1. Давать несколько попыток ввода пароль, затем блокировать аккаунт на некоторое время. К примеру, после 5 ошибки блокировать на 15 минут. Это сделает брутфорс невозможным.
2. Несколько усложненный предыдщий вариант - после каждой последующей ошибки увеличивать время задержки до следующего ввода. К примеру, первые три попытки идут без задержки, затем делается задержка в 10 секунд, при следующей ошибке - 20 секунд и т.д. После 10-20 неверных угадываний задержка вырастет настолько, что опять же перебор будет невозможен.
3. Можно использовать ту же Visual Captcha и т.п. - т.е. рядом с окошком ввода пароля выводится в графическом виде некий зашумленный текст, который пользователь также должен ввести. Роботам его распознать достаточно сложно => они не смогут логиниться.

Вот про 1 вариант! Можешь написать скриптик? А то я со временем ниразу не сталкивался как-то.

PASHAN
Сохраняешь в файле или БД число ошибок, время последнего доступа и т.п. При ошибке делаешь инкремент числа, если при попытке доступа число ошибок больше критического, проверяешь, сколько прошло времени, и в зависимости от этого запрещаешь доступ без дальнейших проверок или сбрасываешь счетчики и по новой.
Думаю, сам напишешь.

Saruman
3-й способ - это гемморой для пользователя.
При частых логинах набирать случайный текст с картинки не самое интересное занятие...

Самый оптимальный способ борьбы с брутфорсом - это все-таки подсчет количества попыток логина, и после 3-5 неправильной - установка таймаута и при этом можно еще отправить уведомление пользователю на мыло об этом.

Также, после множества неверных попыток логина нужно предложить юзеру все таки воспользоваться сервисом смены пароля. В противном случае аккаунт блокируется на более долгое время (12-24 часа)...

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

Saruman
Установки таймаута вполне хватит для почти всех случаев. А там где и этого мало - следует уже подумать, а не нужно ли пользоваться более надежными методами защиты (например, тот же https).

D1g174LM4n14c
Captcha практически 100% помогает от регистрирующихся ботов. Если это важно - то никакие таймауты ее не заменят.

Saruman
Естественно! Но для РЕГИСТРАЦИИ, а не ЛОГИНА! :beer:

D1g174LM4n14c
Не вижу разницы. Я могу нарегить вручную пару десятков аккаунтов, а потом натравить на них бота по готовой базе логинов/паролей.

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

RaZEr
Как раз таки от простого перебора паролей прекрасно защитят и обычные таймауты. Как ты будешь брутфорсить, если у тебя после 20-30 попыток будут задержки по 5 минут между попытками? Так что защититься от подбора паролей не проблема.

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

Ps: Бот чередует логины. Таймаут ставить просто не на что ...

RaZEr
На айпи можно таймауты ставить, кроме логинов. Если он при этом лезет еще и с разных ip - уже другой вопрос. Но в любом случае, это достаточно затрудняет процесс. Сколько у тебя лист проксей, 5000, допустим? А сколько нужно перебрать вариантов паролей? Вот и считай.

Saruman
А смысл? :biggrin:
Ты САМ зарегистрируешь аккаунты и САМ будешь их ломать?

При регистрации captcha нужна. А при логине - нет. Хватит установки таймаута. Это явно понятно. Таким образом аккаунты боты плодить не смогут и подбирать пароли - тоже.

Здесь речь идет о ВЗЛОМЕ аккаунта брутфорсом, где таймаут защитит очень удачно.

D1g174LM4n14c
А что, единственное, что можно делать с аккаунтами - это их ломать? 8)) Тогда действительно все это совершенно не нужно 8))