Оптимизация хранения сессий PHP

[xsequel]

MiksIr, по проектированию движка я у вас ничего не спрашивал и не собираюсь. Есть просто сессии и все, стандартные сессии и все, никаких оберток.

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

Может мне еще учесть в движке чтобы как программу для управления шаттлом ее можно было использовать, а че?!, вдруг пригодиться. То что вы предлагаете это те же сессии только в смятку, 1 к 1-ому. Те же сессии только реализованные самим. Я так понимаю у вас много времени и вы любитель пописать велосипеды на досуге.

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

Потому что ваш "вариант" никак за защищает от этой уязвимости, ага. Это что из ряда вывести капчу текстом.

 

[xsequel]

«База» на каком языке написана?..

на с

 

[MiksIr]

MiksIr, по проектированию движка я у вас ничего не спрашивал и не собираюсь. Есть просто сессии и все, стандартные сессии и все, никаких оберток.

Так я и говорю - так бы и писали, что говногодите движок. А то тут, понимаешь, случайно хорошо о вас подумали, что мол проектируете, хотите все правильно сделать.

Может мне еще учесть в движке чтобы как программу для управления шаттлом ее можно было использовать, а че?!, вдруг пригодиться. То что вы предлагаете это те же сессии только в смятку, 1 к 1-ому. Те же сессии только реализованные самим. Я так понимаю у вас много времени и вы любитель пописать велосипеды на досуге.

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

Потому что ваш "вариант" никак за защищает от этой уязвимости, ага. Это что из ряда вывести капчу текстом.

Может больше конкретики? М? А то создается впечатление, что это вы не понимаете сути защиты. Я вообще молчу, что в 99% случаев достаточно реферер проверять, ну да хрен с ним. Речь идет о защите путем подмеса ключа. Я генерирую ключ на основе постоянных данных определяющих пользователя (таких как ip и user_id) с подмесом секретного ключа. При получении формы я генерирую этот ключ снова и сравниваю с полученным. Расскажите, что тут не так. На пальцах, а то может и правда я очевидного не вижу.

 

[xsequel]

Еще раз извините, я не сразу понял, что классы кеширования данных для вас велосипеды

Да блин, зачем мне что-то там кешировать? С какой целью? Я провел эксперимент с 25к файлами самое большое замедление 1сек. А операция мне нужна только раз в сутки так что про таблицы и ls )) рассказывайте хостерам что вам VDS настраивали.

Расскажите, что тут не так. На пальцах, а то может и правда я очевидного не вижу.

Объясняю на пальцах "не говнокодеру" самого простого варианта. Кто-то дает ссылку на прокладку с вредоносным кодом, вы идете туда там идет скрытый запрос с javascript, на url заказа вывода денег например. Этот запрос принимается так как нет посланного ключа сгенерированого раньше, дальше себе генерируйте хоть перегенерируйтесь, вас отправляю куда например хоть на google.com. Все. Вы и есть тот от кого система ждет запрос, вы и его послали, запрос принят. Вы ничего не подозревая смотрите google.com или смотря на что якобы должна быть ссылка.
Насчет реферера, я так понимаю в википедию обратились, за пробелом в знаниях, но я вас разочарую так как это тоже не очень сложно обойти. Так что проверяйте в 99% случаях реферер))

 

[MiksIr]

> Этот запрос принимается так как нет посланного ключа сгенерированого раньше
Нет, этот запрос не принимается, так как с запросом не пришел ключ, который мы ожидаем. Дальше что?

 

[xsequel]

Если вы не храните ключ. Вот тогда расскажите мне на пальцах как вы генерируете ключ

 

[MiksIr]

Я уже сделал это. Перечитайте. Могу разжевать, если уж никак не понимаете. Ключ должен отвечать нескольким критериям:
1. Быть уникальным для пользователя. Подмешивание уникальных данных пользователя, таких как user_id, какая-нить кука с id сессии и т.д делает этот ключ уникальным.
2. Быть секретным, т.е. никто его не может сгенерить кроме вашего сайта. Алгоритм создания хеша и подмешивание секретной фразы обеспечивает это.
3. Ограниченное время жизни. - не критично, но пускай будет. Это тоже легко решается закладыванием этой информации в ключ.
4. Ну и ключ должен пройти валидацию, т.е. пришедший из формы ключ должен совпадать с тем, что мы ждем на сервере. Так как алгоритмы генерации ключа при создании формы и при проверке запроса одинаковы, входные данные одинаковы, то и ключ получится одинаковый. Валидация пройдена.

 

[xsequel]

Да господи что ж вы такой не понимающий. Это все понятно это теория, мне ее рассказывать не надо. Вы мне ответьте конкретно каким образом вы генерируете уникальный ключ? Если вы его нигде не храните как вы можете узнать потом что это тот самый ключ. Вот конкретно скажите что нужно сложить чтобы потом можно было восстановить и чтобы он при этом был уникальным, а? Хотите кодом напишите это всего одна строчка.

 

[MiksIr]

md5($user->id . $security->permanent_secret_key . $request->ip . $user->password . < и т.д. >)

 

[xsequel]

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

 

[MiksIr]

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

 

[xsequel]

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

 

[MiksIr]

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

 

[xsequel]

От этой атаки можно защитится только если названия поля(или параметра URL) и ключ field_name => key при каждом запросе делать уникальными, а для этого где-то хранить нужно их, сессия, БД не важно. Потому что если поле известно то это все проделать с клиентом нет никакого труда. А если только реферер используется тот как 2 пальца ...

 

[MiksIr]

Нет

 

[xsequel]

Ну так просветите. Я вам описал конкретный пример взлома.

 

[MiksIr]

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

 

[xsequel]

Хех,.. в этом и весь секрет. Инструменты я вам палить не буду, не заслужили, но они есть в сети, просто нужно немного в вопросе разобраться.
А вот давайте сделаем по другому, вы даете мне ссылку на сайт свой какой писали и я дам моим словам подтверждение. Вернее вы узнаете со слов пользователей, а я немного в соц.инженерии попрактикуюсь.

 

[MiksIr]

Ответ не принимается. Или рассказываете, или сливаетесь. А о том, какой вы крутой хацкер идите рассказывать на хацкер.ру.

 

[xsequel]

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