Много почитал про защиту скрипта, одна из проблем, как я понял, сложность защиты сессии.
Появилась такая идея, еще не пробовал реализовывать, а мож вообще глупо. Хотелось бы услышать ваши замечания и любую критику, стоит ли такое вообще делать.
Суть такая:
Номер сессии хранится в базе с данными:
- entry - просто номер строки
- cid - ид куки
- sid - ид сессии
Перед стартом сессии проверяется наличие куки (допустим с таким же именем cid), если оно есть, ищем в базе и получаем sid. И формируем "псевдокуки" с именем сессии:
$_COOKIE['SESSIONID'] = $sql['sid'];
После чего можно стартовать сессию и она возьмется в соответствии с заданными вручную куки. А пользователю генерируем новый cid с меткой времени и посылаем новый cid и его пишем в базу. Получается одноразовый ключ входа в сессию.
Соответственно еще нужно много чего дописать, перепроверить, запретить при первом старте сессии посылать куки пользователю с sid'ом.
Спустя 44 минуты, 41 секунда (21.06.2012 - 09:44) vagrand написал(а):
$_COOKIE['SESSIONID'] = $sql['sid'];
Эта строка уже посылает куки пользователю, так конечно делать не рекомендуется но оно работает. В любом случае если вы посылаете что-то в куки и потом используете это для авторизации то есть возможность что куки у пользователя уведут.
Так что ваш способ ничего не защищает.
Спустя 19 минут, 11 секунд (21.06.2012 - 10:03) Quieteroks написал(а):
vagrand
Вот то что переопределение глобального массива влияет на посылаемое пользователю, вообще не слышал... Он же содержит принятые от пользователя данные, а для отправки куки есть функция setcookie(). И лишние заголовки не должны по идеи отправляться пользователю без этой функции, поскольку скрипт считает, что они пришли ОТ ПОЛЬЗОВАТЕЛЯ, и их повторно нет необходимости отправлять, если нет как раз той самой функции setcookie().
А во вторых читайте внимательно, cid генерируем при каждом новом запуске скрипта. Даже если куки украдут, то лишь на один раз, до входа реального пользователя на сайт, который знает свой пароль. Замучаются дергать cid у пользователя. Или их будет столько вариантов, что просто отпадет желание их проверять.
Вот то что переопределение глобального массива влияет на посылаемое пользователю, вообще не слышал... Он же содержит принятые от пользователя данные, а для отправки куки есть функция setcookie(). И лишние заголовки не должны по идеи отправляться пользователю без этой функции, поскольку скрипт считает, что они пришли ОТ ПОЛЬЗОВАТЕЛЯ, и их повторно нет необходимости отправлять, если нет как раз той самой функции setcookie().
А во вторых читайте внимательно, cid генерируем при каждом новом запуске скрипта. Даже если куки украдут, то лишь на один раз, до входа реального пользователя на сайт, который знает свой пароль. Замучаются дергать cid у пользователя. Или их будет столько вариантов, что просто отпадет желание их проверять.
Спустя 19 минут, 28 секунд (21.06.2012 - 10:23) vagrand написал(а):
| Цитата |
| Вот то что переопределение глобального массива влияет на посылаемое пользователю, вообще не слышал |
Действительно, не ставятся, видать я протупил.
| Цитата |
| А во вторых читайте внимательно, cid генерируем при каждом новом запуске скрипта. Даже если куки украдут, то лишь на один раз, до входа реального пользователя на сайт, который знает свой пароль. Замучаются дергать cid у пользователя. Или их будет столько вариантов, что просто отпадет желание их проверять. |
Ну и что что при каждом запуске. Вот я украл у тебя куки, затем зашел по ним на сайт и мне сгенерило новые куки и так все время, пока я хожу по сайту. Как сайт поймет что я это не тот человек, для которого куки были сгенерены изначально?
Спустя 10 минут, 33 секунды (21.06.2012 - 10:33) Quieteroks написал(а):
vagrand
| Цитата |
| Ну и что что при каждом запуске. Вот я украл у тебя куки, затем зашел по ним на сайт и мне сгенерило новые куки и так все время, пока я хожу по сайту. |
Украл одни куки, пока он ими воспользуется, сиссия либо будет уничтожена, либо перезаписан новый cid. Даже если успел воспользоваться, настоящий пользователь при открытии сайта перезапишет куки на себя. И тот кто украл, будет вновь их воровать.
| Цитата |
| Как сайт поймет что я это не тот человек, для которого куки были сгенерены изначально? |
Можно cid шифровать с вложенной информацией о клиенте к примеру. Можно бузу чуть расширить.
Спустя 9 минут, 28 секунд (21.06.2012 - 10:43) vagrand написал(а):
| Цитата |
| Украл одни куки, пока он ими воспользуется, сиссия либо будет уничтожена, либо перезаписан новый cid. |
Очень много чего можно успеть и речь у тебя в посте идет не о том что можно успеть а о новом алгоритме защиты сесии. Но кк оказывается ничего твой алгоритм не защищает, т.к. куки, если будут украдены, все равно позволят злоумышленнику авторизоватся на сайте.
| Цитата |
| Украл одни куки, пока он ими воспользуется, сиссия либо будет уничтожена, либо перезаписан новый cid. Даже если успел воспользоваться, настоящий пользователь при открытии сайта перезапишет куки на себя. И тот кто украл, будет вновь их воровать. |
Каким образом настоящий пользователь авторизируется на сайте после воровства его куки если cid будет уже другой? Только если повторно введет логин и пароль, но это к защите сесии уже не относится.
| Цитата |
| Можно cid шифровать с вложенной информацией о клиенте к примеру. Можно бузу чуть расширить. |
Приведи пример информации, которую ты добавишь в шифрование и которую злоумышленник не сможет передать серверу вместе с украденной cookie?
Спустя 47 минут, 29 секунд (21.06.2012 - 11:30) Quieteroks написал(а):
vagrand
| Цитата |
| Приведи пример информации, которую ты добавишь в шифрование и которую злоумышленник не сможет передать серверу вместе с украденной cookie? |
| Цитата |
| куки, если будут украдены, все равно позволят злоумышленнику авторизоватся на сайте |
Как я заметил такой информации нет. Но если злоумышленник не предоставит ее в при первом запуске, куки будет бесполезной, ибо cid уже потерял свою актуальность и сессия будет потеряна для обоих сторон. Тот же ip и браузер добавив в шифрование, уже не позволит частично избежать подделки. Все подделывается, но все же, попытка не пытка.
| Цитата |
| Каким образом настоящий пользователь авторизируется на сайте после воровства его куки если cid будет уже другой? |
Так и авторизуется, через свой логин и пароль, который знает он, но, надеюсь, еще не знает злоумышленник.
| Цитата |
| о новом алгоритме защиты сесии |
Идея вообще стоит внимания, с доработками естественно? Или глупо вообще такое пробовать?
Спустя 48 минут, 14 секунд (21.06.2012 - 12:18) vagrand написал(а):
| Цитата |
| Тот же ip и браузер добавив в шифрование, уже не позволит частично избежать подделки. |
Это не помешает, но не дает гарантии, т.к. и IP и браузер могут быть одинаковы.
| Цитата |
| Так и авторизуется, через свой логин и пароль, который знает он, но, надеюсь, еще не знает злоумышленник. |
Ну как я и говорил к самой защите сессии это отношения не имеет.
| Цитата |
| Идея вообще стоит внимания, с доработками естественно? Или глупо вообще такое пробовать? |
Естественно стоит, защита лишней не бывает, но я бы посоветовал вам сконцентрировать свое внимание на написании кода таким образом что бы куки нельзя было украсть. Естественно что куки могут украсть и не через сайт, а при помощи вируса на компе пользователя.
Тут можно порекомендовать следующее:
1. Перегенерацию хеша куки после каждой загруки страницы сайта;
2. Предыдущие хеши уже не валидны;
3. Экспайр по времени;
4. Смена пароля пользователя только при ручном введении текущего пароля.
Спустя 14 минут, 31 секунда (21.06.2012 - 12:33) Quieteroks написал(а):
| Цитата |
| 1. Перегенерацию хеша куки после каждой загруки страницы сайта; 2. Предыдущие хеши уже не валидны; 3. Экспайр по времени; 4. Смена пароля пользователя только при ручном введении текущего пароля. |
Это все естественно и так делается. И попытка всячески уберечь скрипт тоже проводятся.
| Цитата |
| я бы посоветовал вам сконцентрировать свое внимание на написании кода таким образом что бы куки нельзя было украсть |
Как кража куки может зависеть от программиста?
Потеря интереса к куки наверно никогда не угаснет, пока есть авторизация для пользователя.
Спустя 3 часа, 4 минуты, 46 секунд (21.06.2012 - 15:38) vagrand написал(а):
| Цитата |
| Как кража куки может зависеть от программиста? |
Почитай про XSS уязвимости, например тут: http://www.fssr.ru/hz.php?file=article&name=News&sid=5005
Спустя 21 минута, 23 секунды (21.06.2012 - 15:59) Quieteroks написал(а):
vagrand
Ну вроде и подобные атаки пробую пресекать.
Ну вроде и подобные атаки пробую пресекать.
Спустя 5 часов, 8 минут, 36 секунд (21.06.2012 - 21:08) fdr написал(а):
по мне пускай пользователь сам думает о защите своих куках)))
Спустя 6 дней, 16 часов, 23 минуты, 4 секунды (28.06.2012 - 13:31) alex455 написал(а):
| Цитата (vagrand) |
| Эта строка уже посылает куки пользователю, так конечно делать не рекомендуется но оно работает. В любом случае если вы посылаете что-то в куки и потом используете это для авторизации то есть возможность что куки у пользователя уведут. |
Это уже проблема пользователя, а не web-dev'а. Насколько я понимаю, если его cookie уведут, то зайти под его именем смогут в любом случае...
Спустя 5 минут, 48 секунд (28.06.2012 - 13:36) vagrand написал(а):
alex455
| Цитата |
| Это уже проблема пользователя, а не web-dev'а. Насколько я понимаю, если его cookie уведут, то зайти под его именем смогут в любом случае... |
Вы понимаете не правильно. Почитайте про XSS уязвимости
Спустя 1 час, 40 минут, 56 секунд (28.06.2012 - 15:17) ApuktaChehov написал(а):
Quieteroks - вы должны понять одно. НЕТ 100% защиты ни от чего. Если вы что-то берете от пользователя, что бы опознать его, то это информацию всегда может быть скомпрометированой. Все что вы можете, так это усложнить жизнь взломщику, сделать нерентабельным взлом. Проверяйте вместе с куками: IP, UserAgent, OS и т.д. Если что не совпадает, требуйте аутентификацию.