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

[CaptainFlint]

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

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

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

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

[RaZEr]

какие уязвимости есть во всех этих вариантах

кривые руки

как с ними бороться

застрелиться

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

[CaptainFlint]

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

[RaZEr]

Можно пару ссылочек подбросить, где подобные ситуации описаны?

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

[Sheryld]

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

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

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

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

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

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

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

[ГеныЧ]

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

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

[CaptainFlint]

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

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

[ГеныЧ]

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

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

[CaptainFlint]

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

[RaZEr]

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

[CaptainFlint]

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

[RaZEr]

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

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

[CaptainFlint]

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

[V0iD]

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

[RaZEr]

Проверенная техника, недаром юзается на львиной доле фри мейл-серваков

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

Сообщение от CaptainFlint

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

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

[RaZEr]

Кстать, сейчас модняво делать ники и логины

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

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

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

[Saruman]

PASHAN
А от банального брутфорса эта очень сложная защита как защищалась?

?totot=totototototototototototototototo

Это что, поподробнее нельзя? md5-hash данных или session id?