Эта тема на forum.dklab.ru


foxx: Безопасность сессий в PHP (нестандартная передача SIDa)
Господа! Прошу кое-что прояснить. Ситуация такая: профессиональным программистом не являюсь, хотя на ПХ уже кой-чего написал. Сегодня меня озадачил вопрос: как передавать SID при отключенных кукисах и JS. Только что пришло в голову (и уже оттестированно на денвере :) ) такое вот решение: вместо сессии как таковой использовать некий сторонний механизм передачи (при этом полагается, что между клиентом и сервером передается только ИД "сессии") который соответствует вышеуказанным требованиям, а именно http header`ы. Вам, я так полагаю, известно, что эти заголовки могут быть абсолютно произвольными. Так вот: неким заголовком клиенту передается header ("VasinHeader: ".md5(time)."");. Т.е. мы передали этот самый заголовок юзеру. А получаем мы его от клиента так: if(isset($_SERVER['SERVER_SOFTWARE']['VasinHeader'])) echo 'yyyya!'; (можно, конечно и жести добавить - но это уже отступление). Так вот, в денвере все работает и мне кажется это отличное решение вопроса передачи сессии. Внимание!!! Вопрос!!! Наскольно безопасна передача подобных заголовков? С нетерпением жду отзывов!
chin:
А как Вы браузер заставите передавать этот заголовок? К примеру, при нажатии по ссылке?
foxx:
он его автоматом передает и сохраняет в массиве SERVER SOFTWARE, как показано в примере
Anonymous:
предлагаю "погонять" кусок кода в локали - просто гуляйте по ссылкам и будет показано 'yyyyya!'
chin:
предлагаю "погонять" кусок кода в локали
в смысле??
Anonymous:
пишем index.php
<?php
if(isset($_SERVER['SERVER_SOFTWARE']['VasinHeader'])) echo 'yyyya!';
header ("VasinHeader: ".md5(time)."");
?>
т.е. сначала проверяем наличие, потом устанавливаем - все проще некуда
chin:
Нужно выставлять этот хедер при ЗАПРОСЕ, а не при ответе.
foxx:
пардон... не понял
foxx:
не... я наверное извинюсь... давайте по сути вопроса? вопроса "будет работать или нет" я не ставил (если бы не тестировал, не стал бы тему поднимать). Обратился в этот форум т.к. весьма его уважаю. Обратился по сути вопроса безопасности такого подхода. И очень надеюсь получить отзывы именно касательно вопроса безопасности. заранее thanks
chin:
Ну, например, Apache basic authorization передается через HTTP заголовок в запросе. Он криптится и все вроде довольны.. Вообще, в наше время мало что безопасно. Но этот вариант - ни чуть не более безопасен, чем передача по cookie, т.к. это, по сути, тот же http заголовок.
И все-же, мне интересно, как Вы добьетесь от браузера отправки собственного заголовка? Приведите пример, если не сложно..
foxx:
ну вот... уже в тему, спасибо... по порядку:
1. именно из этого примера (Apache basic authorization) возникла идея :)
2. то что ничто не безопасно, эт я тоже понимаю, также прекрасно понимаю что особой защиты он не прибавит, но!
3. основная задача которую я решал - передача SID`a без кукисов (см.тему), начитался тут про разных параноиков... жутко даже как MS людей запугал злобными хакерами
4. добиваться не надо!!! посмотрите пожалуйста внимательно на приведенный кусок кода. браузер и сервер обмениваются заголовками постоянно! и вот тут вы уже правы в том что это фактически аналог самих кукисов, но! юзер не сможет заблокировать передачу заголовков и МОЯ проблема решена!
меняю вопрос: ожно ли рассчитывать на уровень безопасности, аналогичный Apache basic authorization? (хотя чувствую, именно этот уровень и будет... :) )
еще вопрос: каким образом юзер может похачить headers?
chin:
ожно ли рассчитывать на уровень безопасности, аналогичный Apache basic authorization?
Вполне
каким образом юзер может похачить headers?
Взломом браузера или написанием собственного :)

Кстати, второй ответ относится и к Вам. Я только что, ради собственного интереса, попробовал выше приведенный код - при ответе высылается заголовок VasinHeader. А вот при следующем запросе - нет. Я ж о чем и говорю! Функция Header(...) - это ОТВЕТ сервера браузеру. А нам нужно не только передавать VasinHeader в ответе, а и заставить браузер посылать этот заголовок серверу при ЗАПРОСЕ.
foxx:
пардон... не все выписал из теста... вот полный:

if(isset($_SERVER['SERVER_SOFTWARE']['Gotcha'])) echo 'yyyya!';
if(!headers_sent(header('Gotcha: Gotten'))) echo 'gotchennn';

проверка полность двусторонняя
foxx:
PHP все-тки чудо )
WingedFox:
foxx
Выложите в онлайн пример с 2 страницами:
1я ставит заголовок и редиректит на 2ю.
2я выводит результат проверки этого заголовка.
foxx:
на днях... линк сюда кину
chin:
Ёпрст...
print_r($_SERVER['SERVER_SOFTWARE']); // >> Apache/1.3.33 (Win32) PHP/4.4.0
print_r(isset($_SERVER['SERVER_SOFTWARE']['AnyString'])); // >> 1
print_r($_SERVER['SERVER_SOFTWARE']['AnyString']); // >> A
Откуда Вы взяли, что нужно использовать SERVER_SOFTWARE - ума не приложу...
chin:
на днях... линк сюда кину
желаю успеха! (:
foxx:
$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the webserver. There is no guarantee that every webserver will provide any of these; servers may omit some, or provide others not listed here. That said, a large number of these variables are accounted for in the CGI 1.1 specification, so you should be able to expect those.
оф.ман.
foxx:
'SERVER_SOFTWARE'
Server identification string, given in the headers when responding to requests.
chin:
Английский понимаете?
Серверная идентификационная строка(!), которая отправляется в заголовках при ответе(!) на запросы
...
Эта строка содержит версию серверного софта (версию апача, ОС, PHP).

P.S. особенности типов данных в PHP
$s = "Test String";
print_r($s); //>> Test String
print_r($s[0]); //>> T
print_r($s['AnyString']); //>> T
print_r($s['BlaBlaBla']); //>> T

Где "T" - всеголишь первый символ строки $s.
chin:
PHP все-тки чудо )
ну-ну (:
foxx:
Ёпрст...
поторопился с выводами...
спать надо больше...
и чаще
не работает, как оно и должно быть
спасибо за внимание


foxx писал(а):
PHP все-тки чудо )
ну-ну (:


и все-тки оно есть чудо...
P.S. Если есть мысли по этому вопросу, выложите плз, или может собственный опыт имеется? вроде как-то можно посредством POSTa передавать
chin:

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

Вы хоть поняли, почему оно у Вас не работает? (:
и все-тки оно есть чудо...
Мне тоже нравится (:
Если есть мысли по этому вопросу, выложите плз
Я сначала подумал, что можно воспользоваться заголовком Authentication - но потом понял, что его всеравно отдает браузер, а сервер тут не при чем. Ума не приложу, что нужно сделать, чтобы заставить браузер выдавать нужный нам заголовок. А еще, чтобы потом сервер его благополучно принял...
А POST тут тоже не при чем. Вы что, собираетесь каждый переход по ссылке сопровождать отправкой POST формы? А как же тогда поисковые роботы? Думаете, они будут формы отправлять, чтобы по сайту Вашему пробраться?
foxx:
Вы хоть поняли, почему оно у Вас не работает? (:
ага... как поспал - почти сразу допер
А POST тут тоже не при чем. Вы что, собираетесь каждый переход по ссылке сопровождать отправкой POST формы? А как же тогда поисковые роботы? Думаете, они будут формы отправлять, чтобы по сайту Вашему пробраться?
вот в том-то и впрос: буквально вчера нагуглил "session without cookie" попал на форум буржуйский... вот только во время чтения меня и "осенило" (:. Так вот, там люди как раз вопрос обсуждали и упоминался какой-то способ передачи постом (к сожалению, я видел только отзывы на статью, саму статью не нашел).
foxx:
ха! а все-таки она вертится!
http://xhtmlforum.de/35221-php-session-etag-header.html
WingedFox:
foxx
Ну так посмотрите, что же такое этот самый "E-Tag".
А ещё лучше - прочитайте RFC 2616 и подумайте своей головой - почему его использовать нельзя.
foxx:
вот... посмотрел, почитал, проверил...
попадает прямо в точку в плане поставленной задачи - справляется на ура
подумайте своей головой - почему его использовать нельзя
подумал... может опыту еще маловато (раз в 10 меньше чем нужно нормальному кодеру... самокритика). поясните плз - никак догадаться не могу где собака зарыта
WingedFox:
foxx
Опишите, для чего используется E-Tag.
foxx:
entity tags возвращает значение HTML сущности от запроса
МОЖЕТ использоваться для сравнения сущностей
WingedFox:
foxx
В первую очередь E-Tag используется для валидации контента.
Теперь подумайте, стоит ли мусорить на прокси серверах и вносить путаницу.

Кроме того, прокси сервер не обязан проверять E-Tag, если время жизни документа не истекло.
Таким образом, вполне реален вариант, когда сессия попадёт не по назначению.

Ну и если Вы отключите кеширование, то поимеете очень значительный перерасход траффика и увеличенную нагрузку на сервер.
foxx:
Позвольте несколько глубже прояснить суть вопроса.
Техника обхода кукисов для передачи SIDa которую хочу освоить - не параноя. Я отнюдь не собираюсь заменить функцию сессии этим "нечто". Просто встал вопрос: что делать с теми кто отключает кукисы (кого до смерти напугал MS дырами в безопасности собственного же продукта). Пишется магазин и сайту нельзя ни в коем случае терять клиентов которые повырубали нафик яву и кукисы потому что им сказали "так надо" те кого они считают профессионалами своего дела (MS).
Именно поэтому встал вопрос "безкукисной передачи" SID`a. Конечно, можно URL`ом передать... Но тут дело личного вкуса... мне не нравится такой способ передачи уникального идентификатора - он слишком открытый. Да, конечно, вы возразите что этот способ - столь же "безопасен" как и GET. Но он не столь нагляден, а это уже существенный плюс.
Резюме: планирую внедрить этом способ передачи SID`a исключительно как альтернативу сессии, т.е.:
1. если кукисы разрешены, передаем сессию
2. если кукисы запрещены, передаем ETag`ом
3. если (вот хрен его еще знает, может у клиента браузер глючный) невозможна передача ETag`ом, передаем GET`ом
Вот и вся логика. Есть просто такое желание - сделать сайт одоступнее для посетителей (даже для параноиков) и URL оставить девственно чистым.
Что касается прокси:
очень рассчитываю на: header('Cache-Control: post-check=0, pre-check=0, must-revalidate, proxy-revalidate, private');
если не прав, пожалуйста, поправьте
foxx:
кстати, может вы располагаете действительно правильным и элегантным решением?
Maus:
foxx
Вы не може вкратце и однозначно изложить суть того обсуждения, на которое Вы давали ссылку? Там по-немецки, а этот язык мне неизвестен.
Кроме того, насколько я понимаю (могу и заблуждаться - не было нужды вдумчиво читать спецификацию) механизм работы etag - браузер не отдаст его, если у него этого документа нет в кэше. А если есть, то при одинаковых Etag браузер может счесть, что страница не изменилась, закрыть соединение сразу после получения заголовков и показать старую (закэшированную) версию.
foxx:
etag только носитель. поставленная задача решается только в связке с last-modified. Если документ не подлежит обновлению, он берется из кэша. Если last-modified указывает на необходимость обновления, документ заново получается с сервера, вместе со всеми заголовками (в том числе и etag обновленный получает). Т.о. при last-modified = "сейчас" мы всегда имеем новый etag который возвращается к серверу. вот и все. Этот "эмулятор сессии" будет запускаться также как и сама сессия, после первичного запуска страницы.
да и вообще... по-моему пора тему закрывать. форум авторитетный, речи нет, только вопрос похоже для метного населения не актуальный (может и я зря озадачился? красота URL`a не самое ценное... а ЧПУ и так работает с SID`ом в URL`е). помогли чем смогли, за что большое спасибо. Тему считаю исчерпанной.
chin:
Ну почему, вполне уважаю Ваше "загорание" (:
Буду ждать новостей.
Константин Жинько [tIT]:
осподи! Чем SSL не нравится?
chin:
Кстати, да.
foxx:
"]Чем SSL не нравится?
профессиональным программистом не являюсь
Про SSL тоже, к сожалению, знаю маловато (собственно только расшифровку аббревиатуры). Примерно представляю что такое сокеты. Вот Вы сейчас про него сказали и вроде начинаю догадываться как (теоретически) это с его помощью реализуется.
Понимаю что подробно объяснять будет долго, поэтому прошу: если не затруднит, киньте линку на достойный внимания материал.

Заранее сенькс. И еще пару вопросов:
1. как я понимаю, SSL=REMOTE_PORT+REMOTE_ADDRESS, т.е. реализация слоя SSL происходит на уровне TCP/IP? или все же HTTP?
2. как в этом случае сайт будет "смотреть" на клиентов за проксей (в т.ч. анонимной)?
3. слышал про какие-то паспорта SSL, которые покупать надо где-то. это действительно так или же SSL реализуется только средствами PHP?

Еще раз спасибо за внимание!
Константин Жинько [tIT]:
Про SSL тоже, к сожалению, знаю маловато
Я думаю, он достаточно хорошо инкапсулирован.

как я понимаю, SSL=REMOTE_PORT+REMOTE_ADDRESS, т.е. реализация слоя SSL происходит на уровне TCP/IP? или все же HTTP?
Выше TCP/IP разумеется

как в этом случае сайт будет "смотреть" на клиентов за проксей (в т.ч. анонимной)?
А никак. Будет тупо пересылать закодированный поток данных туда-обратно - как положено.

слышал про какие-то паспорта SSL, которые покупать надо где-то. это действительно так или же SSL реализуется только средствами PHP?
PHP ровно никакого отношения к SSL не имеет. Не паспорт, а сертификат. Можете сами создать, но тогда любой уважающий себя браузер будет предупреждать юзера, что сертефикат-де ни фига не получен от trusted источников, а сделан Васей Пупкиным на Малой Арнаутской. В рунете почти все так и устроено. У ОПСОСов они настоящие часто. Но еще чаще они просроченные и браузер опять-таки матерится. При создании сертификата указывается срок его годности. В сертификационных центрах год стоит сколько-то там баксов. И еще я не помню, есть ли подобные заведения в России.

Ну а почитать можно здесь

Эта тема на forum.dklab.ru