Леонид Каганов: дневник

Итак, у нас имеются на сегодняшний день следующие технологии хранения авторизации на машине клиента:
1. Традиционные куки
2. Псевдокуки flash
3. Псевдокуки html5

Что-то из этого (или всё) может быть у клиента отключено. На данный момент движок проводит авторизацию только по кукам (пытаясь их восстановить в случае утери через п. 2 и 3). Но правильно ли это? А если у посетителя отключены куки, но присутствует все остальное? Он же может продолжать хранить свою авторизацию, учитываться в счетчиках, участвовать в голосования, писать комменты под одним и тем же номером unic.

Поэтому я собираюсь доработать процедуру авторизации таким образом, чтобы в случае отключенных кук машина клиента, уже получив готовую страницу, выудила свой unic из кэша 2 и 3 типа и сделала следующее:
а) Подавала серверу аяксом сигнал о посещении страницы для статистики.
б) Нарисовала сама недостающее имя и unic в поле «ваш логин» на странице.
в) При действиях клиента (комментариях и т.п.) передавала аяксом его unic вместе с стальными данными, поскольку куки сервер, как мы выяснили, не читает.

Но для этого желательно (неуверен, но по первым прикидкам — да), чтобы парольная строка авторизации отдавалась прямо в теле страницы среди javsscript. Типа:
var unic='1234-F534DG5A56B7D870DF6A8B';

А я почему-то этого боюсь. Ну, понятно, что те же самая строка авторизации хранится в куках, и украсть ее из JS — плевое дело. Но для этого надо запустить чужеродный JS на пей странице. А вот как с текстом страницы?

Разум подсказывает, что никто посторонний не сможет выдернуть из тела страницы посетителя никакую информацию. Даже загнав ее в iframe (насколько я помню, доступ к содержимому iframe от ДРУГОГО сайта запрещен во всех браузерах). По пути через серверы тоже никто посторонний не прочтет страницу (умел бы читать — прочел бы куки).

Но сердце беспокоится — вот так открыто вносить авторизацию в тело отдаваемой страницы.

Как вы думаете? Есть ли какая-то уязвимость в этом?