информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСтрашный баг в WindowsЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / web building
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
прикинуться на промежуточном скрипте броузером и вручную дернуть окончательную форму по http, вернув пользователю результат? 06.03.06 23:49  Число просмотров: 3305
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
<web building>
PHP: Промежуточная страница между формой и принимающим скриптом. 05.03.06 23:32  
Автор: Cyber_Onix Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Всем привет
Возникла такая задача:

есть форма, посылающая данные в некий логин скрипт. Необходимо сделать промежуточную страницу, на которой произвести некие действия с посылаемыми данными (установить куки, проверить на валидность и тд), но что бы это было почти прозрачно для пользователя: то есть промежуточная страница в итоге автоматом должна выполнять логин в конечный скрипт.
Можно конечно воспользоваться конструкцией типа
<script>auth.submit();</script> , но может быть есть еще пути?

А именно не хочется что бы на компьютере пользователя могла закешироваться эта промежуточная страница, поскольку в ней в скрытых полях формы в случае <script>auth.submit();</script> будут храниться логин и пароль, что не есть хорошо в смысле секурности
прикинуться на промежуточном скрипте броузером и вручную дернуть окончательную форму по http, вернув пользователю результат? 06.03.06 23:49  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Не понял как это защитит от кеширования 07.03.06 03:12  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
кэширование, как я понял, не нужно из-за hidden-полей, а их никто не заставляет отдавать клиенту 07.03.06 04:31  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Походу я не свосем корректно объяснил задачу: 07.03.06 11:05  
Автор: Cyber_Onix Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Походу я не свосем корректно объяснил задачу:

есть старница на неком сайте, с формой логина и пароля для входа в почту. Есть почтовый вэб интерфейс, в в логин скрипт которого и попадают на данный момент данные переданные из формы.
Для того что бы можно было поддерживать мультидоменность, но оставить пользователю возможность логиниться с "коротким" логином (без @domain.net) в принимающем скрипте были сделаны некоторые модификации (типа $login = $login . '@' . $domain) Это не есть хорошо, поскольку версии вэб морды переодически обновляются и приходится не забывать после обновления снова модифицировать скрипты.

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

Единственный вариатн пришедший мне в голову: это промежуточная страница в том же домене, что и страница авторизации, принимающая данные из формы, анализирующая их, сажающая куки, а так же превращающая две переменные $login и $ domain в одну, как раз того вида, который по умолчанию нужен принимающему скрипту на почтовой морде.

Следовательно: 1. надо принять на этой странице данные через POST (не проблема). 2. Что то с ними сделать (тоже не проблема) 3. Отправить пользователя в почтовый интерфейс, передав опять таки методом POST уже обработанные данные.

Опять таки - единственные вариатн который работоспособен в таком виде:

<?
$login = $_POST[login];
$domain = $_POST[domain];
$pass = $_POST[password]
$login = $login.'@'.$domain;

// Посадить куку.
//Запретить кеширование.

echo "<FORM id='auth' action='http://mail.domain.net/login.php' method=post>
<INPUT type=hidden name=login value='$login'>
<INPUT type=hidden name=pass value='$pass'>
<script>auth.submit();</script>
</FORM>";
?>

В примерно таком варианте все работет, но смущает уже описанная потенциальная возможность сохранения этой промежуточной страницы на компьютере пользователя... Смущает именно из-за <INPUT type=hidden name=pass value='$pass'>

Вот такая вот ситуевина
а, понятно 07.03.06 15:12  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Есть конечно вариант всю работу вести через прокси, который живет в первом домене и ходит к почтарю во второй, но это уже совсем криво.
Не пойдет - потому как окончательным результатом является... 07.03.06 00:32  
Автор: Cyber_Onix Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Не пойдет - потому как окончательным результатом является попадание пользователем в свой почтовый ящик.
так можно и дальше продолжать работать через этот самодельный прокси 07.03.06 01:03  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Или выбрать момент и проделать редирект на правильный адрес, все куки в этот момент уже будут выставлены правильно. Единственный подводный камень - если идентификация привязана к ip.
можно попробовать обойтись без POST метода и скриптов - если... 06.03.06 18:22  
Автор: paganoid Статус: Member
<"чистая" ссылка>
> Всем привет
> Возникла такая задача:
>
> есть форма, посылающая данные в некий логин скрипт.
> Необходимо сделать промежуточную страницу, на которой
> произвести некие действия с посылаемыми данными (установить
> куки, проверить на валидность и тд), но что бы это было
> почти прозрачно для пользователя: то есть промежуточная
> страница в итоге автоматом должна выполнять логин в
> конечный скрипт.
> Можно конечно воспользоваться конструкцией типа
> <script>auth.submit();</script> , но может быть
> есть еще пути?
>

можно попробовать обойтись без POST метода и скриптов - если результирующий скрипт логина и промежуточный могут принимать данные в GET формате.

Т.е.
1. Форма методом GET шлется на промежуточный скрипт
2. Промежуточный ставит куки и делает редирект на целевую логин-страницу
3. Логин страница принимает параметры из урлы и
4. Редиректит на более-менее симпотную урлу, где в адресе логин/пароль не светятся, только sessid.

Метод не подойдет, если форма достаточно сложная, или результирующая логин-пага - "чужая" (хотя что это за вебмастер, который дает формам слаться с чужих refereroв?).

> А именно не хочется что бы на компьютере пользователя могла
> закешироваться эта промежуточная страница, поскольку в ней
> в скрытых полях формы в случае
> <script>auth.submit();</script> будут храниться
> логин и пароль, что не есть хорошо в смысле секурности

Кеширование рубится методом, который раскрыл другой докладчик - pragma no-cache. Там чуток больше вариантов хедеров, но суть приблизительно одна и та же.
К сожалению нельзя. Смысл вот в чем: есть форма логина в... 06.03.06 19:23  
Автор: Dr.Nebula Статус: Незарегистрированный пользователь
<"чистая" ссылка>

> можно попробовать обойтись без POST метода и скриптов -
> если результирующий скрипт логина и промежуточный могут
> принимать данные в GET формате.

К сожалению нельзя. Смысл вот в чем: есть форма логина в почту на сайте, есть
конечный скрипт, принимающий из этой формы значения параметров. Менять скрипт
не хочу, поскольку как раз таки от этого и ухожу: в промежуточном скрипте надо
будет "унифицировать" передаваемый логин для создания "правильного": с доменом,
зависящим от того с какой страницы пользователь посылает данные. А так же в нем
(в промежуточном) буду ставить куку для запоминания последнего введенного логина.
Поэтому бы и хотелось что бы промежуточный скрипт работал "прозрачно"...

Остановливать кеширование прагмами можно, но не хочется - всегда есть вероятность что все таки станица "упадет" на диск, и в этом случае в ней можно будет найти пароль
тогда POST, без скриптов (поущербнее вариантец) 07.03.06 10:14  
Автор: paganoid Статус: Member
<"чистая" ссылка>
1. Можно промежуточным скриптом принять таки POST запрос, после обработки и выставления кукоф, сделать redirect 302.

Судя по rfc2616

If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.

после этого телодвижение бровсер должен гавкнуть (Опера так и делает), что форма редиректится и перебросить на целевую пагу.

Вариант не шибко красивый, зато без скриптов. Можно сделать в промежуточном приемнике разводку - если клиент не поддерживает javascript, то делаем вот так, с 302 - по крайней мере, не выкинешь долю посетителей.

2. Кстати, если со скриптами, то и логины свои унифицировать можешь именно ими и ими же и куку ставить - без промежуточной страницы вообще.

> Остановливать кеширование прагмами можно, но не хочется -
> всегда есть вероятность что все таки станица "упадет" на
> диск, и в этом случае в ней можно будет найти пароль

Имхо, ЕСЛИ есть промежуточная страница (а это, так понимаю, условие), ТО "всегда есть вероятность" и никуда от этого не уйти.
Тогда уж лучше 301 07.03.06 14:20  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> после этого телодвижение бровсер должен гавкнуть (Опера так
> и делает), что форма редиректится и перебросить на целевую
> пагу.
С 301м статусом не гавкнет даже Опера (хотя я ни разу не видел, чтоб она сообщала о редиректах и не знаком с таким поведением).
301 по смыслу "вечный редирект", не подходит. Работает вообще только 307, как выяснилось. 07.03.06 15:44  
Автор: paganoid Статус: Member
Отредактировано 07.03.06 16:02  Количество правок: 5
<"чистая" ссылка>
Попробовал редиректить разными методами - вообще метод POST часто сбрасывается при редиректе. Т.ч. метод не подходит ни для 302, ни для 301, ни для 303. Все бровсеры тихо кладут на rfc, сбрасывают метод в GET и ни о чем никого не предупреждают.

Работает вообще только 307. Опера вякает, НО не по делу хехе, пересылает POST параметры на финальное расположение в любом случае. IE, вопреки rfc, не вякает, молча перебрасывает форму.

пример такого редиректа, test.php. Форма шлется и сразу редиректится.

<?

if (@$_GET["ok"] != 1 && $_SERVER["REQUEST_METHOD"]=="POST") {
header("HTTP/1.0 307 Temporary Redirect");
header("Location: /test.php?ok=1");
exit;
}

?>
<html>
<form method="POST">
<? echo @$_POST["waw"]; ?>
<input type=text name=waw><input type=submit>
</form>
</html>


---

как изменить в этом случае список параметров, и можно ли это сделать вообще, увы не знаю. Но куки поставить вполне можно.

> С 301м статусом не гавкнет даже Опера (хотя я ни разу не
> видел, чтоб она сообщала о редиректах и не знаком с таким
> поведением).

301 это "редирект на вечный прикол", по смыслу не подходит. Теоретически, агент, получая в следующий раз редирект на такую локацию, должен вообще пропускать ее и сразу запрашивать цель, минуя промежуточное звено. Другое дело, что POST не должен кешироваться, ноооо.. вобщем все равно, ибо POST-редирект для этого статуса и не работает.

Сообщения о ТАКИХ редиректах достаточно редки, не все про такой статус и знают даже. Тем не менее, на сайте ICQ использовался когда-то.
Вариантов вижу три 06.03.06 03:17  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
1. Сохраняй эти промежуточные данные на сервере, а в выводимой форме в hidden'ах указывай временный идентификатор, чтоб пользователь мог идентифицировать себя.

2. В промежуточной форме храни не сами секьюрные данные, а хэш от них (и заодно от времени, для секурности).

3. Если предложенные варианты не подойдут (хотя мне сложно представить такую ситуацию), используй заголовок "Pragma:no-cache" со всеми сопутствующими cache-control и expires. Конечно, закешироваться-то оно может, но большинство браузеров делать этого не будут.
При всех этих вариантах придется модифицировать принимающий... 06.03.06 19:26  
Автор: Cyber_Onix Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> 1. Сохраняй эти промежуточные данные на сервере, а в
> выводимой форме в hidden'ах указывай временный
> идентификатор, чтоб пользователь мог идентифицировать себя.
>
> 2. В промежуточной форме храни не сами секьюрные данные, а
> хэш от них (и заодно от времени, для секурности).
>

При всех этих вариантах придется модифицировать принимающий скрипт, а этого бы делать не хотелось: при обновлении через CVS изменения потрутся и придется все писать заново... Patch тоже не выход если изменения в принимающем скрипте будет много - может и не наложиться
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach