При редиректе пропадает сессия

[zdimon]

При редиректе пропадает сессия

Помогите разобраться со следующей проблемой.

На сайте есть ряд отсылок внутренних сообщений.
После такой отсылки формой вызывается промежуточная страница с
<meta http-equiv=refresh content="2;URL='mypage.php'">
Так вот при первом авторизованном заходе и отправке сообщения с этой промежуточной страницы не отправляется кука с идентификатором сессии и в следствии чего на странице mypage.php уже регистрируется новая сессия.
Но после второй авторизации эта проблема пропадает и при редиректе идентификатор сессии передается нормально.

Привожу диалог

Промежуточная страница

GET / HTTP/1.1
Accept: */*
Referer: http://www.domain.com/index.php?action=mailbox&new=1
Accept-Language: uk
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Host: www.domain.com
Connection: Keep-Alive
Cookie: __utma=17180015.1591574968.1203412182.1203413827.1203415700.6; __utmb=17180015; __utmz=17180015.1203412182.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); __utmc=17180015; PHPSESSID=37e06fcbfeb6bee42eae4d2715947f9c

HTTP/1.1 200 OK
Date: Tue, 19 Feb 2008 10:09:04 GMT
Server: Apache/1.3.37 (Unix) mod_psoft_traffic/0.1 Vortech_PHP/0.1.0-p0 FrontPage/5.0.2.2623 mod_throttle/3.1.2 mod_ssl/2.8.28 OpenSSL/0.9.7e-p1
Cache-Control: no-cache, must-revalidate
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Powered-By: PHP/5.2.1
X-Vortech-PHP: 0.1.0-p0
Keep-Alive: timeout=15, max=92
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

из нее редирект


GET /?action=mailbox&sent=1 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: uk
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Host: www.domain.net
Connection: Keep-Alive
Cookie: __utma=259614684.234869269.1203412238.1203413671.1203414155.5; __utmb=259614684; __utmz=259614684.1203412238.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)

HTTP/1.1 200 OK
Date: Tue, 19 Feb 2008 10:09:10 GMT
Server: Apache/1.3.37 (Unix) mod_psoft_traffic/0.1 Vortech_PHP/0.1.0-p0 FrontPage/5.0.2.2623 mod_throttle/3.1.2 mod_ssl/2.8.28 OpenSSL/0.9.7e-p1
Cache-Control: no-cache, must-revalidate
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Powered-By: PHP/5.2.1
Set-Cookie: PHPSESSID=576eaba5928cdcfe0e2b7aad686c9f31; path=/
X-Vortech-PHP: 0.1.0-p0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

 

[vasa_c]

Почему хосты разные?
Почему нет рефрера во втором запросе?

 

[Sluggard]

 

[Nogrogomed]

если работать с сессией без кук - то идентификатор сессии при переходе надо задавать явно.

 

[kruglov]

если работать с сессией без кук

Это чтоб нас заXSSили?

 

[crocodile2u]

kruglov
А что, экранировать пользовательскую информацию уже не принято?

 

[kruglov]

crocodile2u
Эээ... Вы не поняли... Я про идентификатор сессии, утекший через реферер или кэш браузера.

 

[crocodile2u]

kruglov
Я знаю, что вы насчет XSS дока. Но я вот пока не могу понять, как утекший идентификатор сессии - через реферер или кэш браузера - можно организовать XSS. Было бы интересно послушать.

 

[kruglov]

Классический XSS ворует идентификатор хитрым образом, а тут вот он, пожалте, и воровать ничего не надо.

Если сессия не протухла или в ней ip-адрес ваш не хранится (что тоже чревато, бывают провайдеры с "плавающими" айпишниками).

 

[Sluggard]

kruglov
Давайте определимся. Для чего используется XSS? Не в целях ли кражи информации о сессии и аккаунте?

Я про идентификатор сессии, утекший через реферер или кэш браузера.

Или в "классической" схеме крадут эккаунт именно для использования его в XSS-атаках? И разве

экранировать пользовательскую информацию уже не принято?

 

[kruglov]

Sluggard
Так, короче, классическая XSS атака - это атака, целью которой является выполнение от имени другого, как правило залогиненного пользователя некоторых действий. Действий по отсылке идентификатора сессии, действий по отправлению какой-то формы от имени пользователя и т.д.

Экранирование пользовательской информации и применяется для того, чтоб хитрый хакер не засунул клиентский скрипт, который бы выполнился у другого пользователя.

А тут вообще ничего внедрять не надо, все украдено и записано в URL. И куда этот URL уедет (в рефереры на чужие сайты, в аську друзьям) - неизвестно.

Напомню недавние случаи, когда пользователям отправлялась (или даже регистрировалась в поисковике) ссылка типа site.ru/?sessid=12a23b45c, они заходили, логинились, в результате чего хакер, заходящий на сайт с тем же номером сессии, оказывался уже залогиненным.

 

[crocodile2u]

kruglov
Имхо, имеет место двоякое восприятие терминологии. В моем понимании, так же как и в понимании Sluggard, кража ИД сессии и вместе с ним доступа к экааунту - не есть XSS. Это скорее вопрос недалекости и беспечности пользователя (и, возможно, в какой-то мере таки разработчика).

XSS же для меня - внедрение в обход системы безопасности ресурса своих скриптов (например, если не экранируются HTML-тэги, а на странице выводится ИД сессии, можно выполнить свой скрипт, украсть куки и т. д.)

Хотя выводы я лично делаю те же, что и kruglov: если можно, отключаю session.use_trans_sid

 

[zdimon]

Спасибо, действительно намутил с доменами.
А что если пользователь отключит куки в браузере, разве PHP не начинает всовывать ид сессий в адресную строку?
Как тогда уберечся от XSS?

 

[crocodile2u]

zdimon
Имхо, пользователь, который отключает даже сессионные куки - просто параноик. session.use_trans_sid=0 и в путь.

 

[Sluggard]

zdimon
1. Не приставлять сид внешним ссылкам (если ты добавляешь его вручную). Сам php добавляет его корректно.
2. Ескейпить информацию от пользователя перед выводом в браузер.