я поэтому и назвал jsessionid "почти параметром".
такая форма впихивания jsessionid это спецификация J2EE. т.е. да, это особенность спецификации сервлетов к HTTP (и как следствие к GET) отношения не имеющая. почему так а не иначе - тема отдельного не маленького разговора... 


UnicornMirage, телохранители говорят "если дело дошло до стрельбы, то мы уже облажались". перефразируя: если DOS атака прорваласть до апп сервера, что-то делать уже поздно. С DOS атаками борются совершенно специфицескими методами с помощье спецально программного обеспечения и железа, как правило на уровне фаерволов. это не проблемма разработчика вэб приложения. это проблемма сетевых и системных администраторов. спецификация J2EE не предусматривает никаких механизмов борьбы с DOS атаками. и повторяюсь - на этом уровне это делать уже очень поздно!  

Это сообщение отредактировал(а) ALKS - 8.5.2006, 20:20

Так, товарищи!

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

Прежде всего: Servlets API - есть по сути жабный программный интерфейс для работы с HTTP. Вот от этого давайте и плясать.

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

Теперь: что значит узнавать. В HTTP не так много средств, которые позволяют это делать. Спецификация Servlets определяет три механизма отслеживания сессий:

- кукисы:

- URL rewriting:

- SSL сессии.

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

Следующий по надежности/удобству метод - это кукисы. Кукисы хороши почти всем, если не считать одной досадной неприятности: некоторые клиенты могут не поддерживать куки, а там, где они поддерживаются, они могут быть выключены юзером.

Теперь очень важный момент: что такое куки и как они работают. Кука - это, грубо говоря, именованная строка текста, которая сассоциирована с адресом URL или его частью. Хотя кукисы не являются частью текущего стандврта HTTP/1.1, они описаны в RFC 2109 (http://www.w3.org/Protocols/rfc2109/rfc2109) от 1997 г. и поддерживаются всеми современными и не очень браузерами.

Так вот, как куки появляются и что с ними происходит дальше. Инициатива по созданию куки принадлежит серверу: когда он возвращает клиенту ответ HTTP (например, содержимое веб-страницы в HTML), он может при этом предварить собственно содержимое одним или несколькими заголовками HTTP. Согласно RFC 2109, одним из таких заголовков может быть Set-Cookie



Согласно все тому же RFC 2109, браузер (если он поддерживает куки и они не выключены юзером) должен в том или ином виде эту принятую куку сохранить. А вот теперь самое интересное. Что происходит, кода юзер тыкает в ссылку? Правильно, браузер отправляет на сервер соответствующим образом оформленный HTTP запрос. Если при этом на URL ресурса распространяется действие ранее сохраненной куки, то браузер автоматически, не дожидаясь особого приглашения, добавляет к запросу заголовок Cookie:



Таким образом, при первом посещении сайта куки на клиенте еще нет - она появится вместе с ответом сервера. Зато при всех последующих посещениях мы уже по содержанию запроса можем узнать, был ли товарищ у нас раньше. Но - внимание! - мы не можем гарантировать, что он точно НЕ БЫЛ. Как мы используем это знание применительно к сессиям? А вот как.

Когда юзер приходит первый раз, и мы решаем открыть сессию, веб контейнер генерит уникальный идентификатор. Потом он создает объект типа сессия и присваивает ему этот идентификатор. Объект типа сессия - это по сути просто расширенный мап с рядом дополнительных свойств для нашего удобства. Что мы туда положим - это уже чисто дело нашей фантазии: можно положить историю хождения в рамках сессии, можно хранить товары для покупки (шоппинг карт) и прочую лабудень.

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

Хорошо, если юзер человеческий: ну сколько он там сможет натыкать? Десяток-другой бесполезных сессий. А что если пришел поисковый робот? Апорт, например, может запросто за несколько минут сделать сотни заходов. И если хороших, добропорядочных роботов можно определить по содержимому заголовка User-Agent, то бывают ведь и недобропорядочные (собиратели емейлов, например). которым никакой robots.txt не писан и которые любят маскироваться под человеческие браузеры. А еще бывают выкачивалки, которые в мгновение ока могут наплодить такую кучу сессий, что любой сервер загнется.

Напрашивается вопрос: а что же делать? А делать надо вот что: создать прослойку в веб приложении (например, в виде фильтра, хотя и необязательно), которая будет заниматься предварительной обработкой запросов и выявлять клиентов, для которых создавать сессию нежелательно. Логика обработки может включать:

- определение известных поисковиков;

- хранение истории все хапросов за определенный период времени (скажем, 30 минут), и выявление деятелей, которые заходят слишком часто (идентифицировать, например, по совпадению IP и содержимого User-Agent);

- ведение черного списка IP, и запросы с этих адресов слать лесом немедленно и без церемоний.

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

Трудно? Да, трудно. Но никто ведь и не обещал, что будет легко.

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

На этом можно было бы и поставить точку, но у нас остался нерассмотренным еще один механизм отслеживания сессий: URL rewriting. Если говорить совсем коротко, то вот: НИКОГДА, НИКОГДА не используйте этот механизм. Почему - могу объяснить. Но - отдельно, а то и так пост здоровый получился.
 

Здорово!! [+] Однозначно    

Не, ну он еще спрашивает, а?.. 

На крайний случай, можешь просто метнуть в нас умной ссылкой. Но лучше сам - доходчиво получается.  

У меня действительно есть очень умная ссылка: я набрел на нее несколько месяцев назад и сохранил на всякий случай линк: http://servlets.com/archive/servlet/ReadMs...me=jsp-interest

Но вот что странно: когда я сейчас пошел посмотреть, все ли там на месте, оказалось, что самое интересное-то как раз куда-то пропало. Но не все потеряно, как оказывается. Повинуясь какому-то необъяснимому предчувствию, я сохранил тогда не только линк, но и весь текст мессаги - то, чего я практически никогда не делаю. Итак, вопреки козням злых сил, которые изо всех сил стараются скрыть правду о URL rewriting, мы сегодня имеем возможность узнать, как оно все обстоит на самом деле. Вот это сообщение:



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

Что я могу сделать - так это прокомментировать аргументы автора, потому что если не представляешь, что такое URL rewriting, то некоторые вещи могут показаться непонятными. Но это завтра. 

Да вроде всё ясно  

текст отличный, спасибо Stampede.

Но. C первыми двумя доводами я не согласен. 

понятно вполне, что имееться под UGLY urls  плохо например то что такие урлы не любят многие поисковые движки ну и еще есть нюансы. но вы можете переписать урл любый образом. как вам нравиться. нарпимер так: www.mysitecom/app/session/30qwihfdlh/go.html и возвращать его в понятное сервлет контейнеру состояния в фильтре до начала работы.

второй пункт... ну мы написали кастом таг который делает внутри url-rewriting и не только на самом деле таг делает очень много полезной работы а его использование не сложнее обычного <A>. так что простите второй довод откровенная ерунда - песьня о тупых ленивых кодерах 

а насчет безопасности. ХЗ. может быть я не эксперт. но вы знаете, если человек не сможет купить плазменный телевизор за $3000 на магазине под нашим движком только из-за того что он параноик и у него отключены куки - нас повесят  
по нашим логам более 5% клиентов приходят без поддрежки куки = минус 5% продаж??? - наc повесят с особой жестокостью.  

И еще. черные списки на уровне App servera? да я не хочу не то чтобы App server пытался бороться с атаками, я не хочу чтобы даже мой HTTP сервер получал подобный реквесты. вся гадость обязана отсекаться еще на уровне IP пакетов до того как я начал тратить ресурсы сервера где запущено мое приложение на анализ подобных реквестов. аппаратный фаервол выдержит нагрузку на 2 порядка больше чем самый оптимальный сервлет контейнер. да и умеею они в вопросах защиты ну очень много (там даже всякий статистический анализ фуззи логика и эвристика). некоторую оптимизацию можно делать (хотя хи хи некоторые краулеры умеют куки и грамотно юзают сессии. очень грамотно.) но только как дополнение к защите более "низкого" уровня. 

Это сообщение отредактировал(а) ALKS - 9.5.2006, 11:11

большое спасибо за информацию  Вы хорошо поняли мои мысли..
такой вопрос - а если делать сессию по IP - можно ли?  

ну ты же сам создаеш сессию в сервлете. сам и решай когда ее создавать а когда нет. напрмер вычитваеш IP из заголовка запроса и решаеш  

Не совсем понятно, что имеется в виду. UnicornMirage ведь говорит о том, чтобы создавать сессию, привязываясь к IP как средству идентификации клиента. Насколько я знаю, в Servlets API такого не предусмотрено, и тому есть веские причины.

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

Что еще хуже, это если из одной внутренней сетки придут несколько разных человек: внешний адрес-то (как он видится для сервера) у них будет один и тот же! Скажем, в университетской сетке какой-нибудь добропорядочный препод зашел в магазин прикупить детям подарков к новому году, набрал кучу ништяков, оплатил и пошел дальше по своим делам. И тут в магазин заходит студень - лоботряс и двоечник. Смотрит - хопа, а его принимают за профессора. Вот уж он нарадуется 

Я. конечно, маленько утрирую: собственно оплата в нормальном магазине должна идти по HTTPS, но ты понял, к чему я клоню: IP как средство идентификации клиента ни в дугу не годится.
 

А с ALKS у нас вообще с разных позиций разговор получается: он говорит как разработчик магазина, а я - как вебмастер.



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

Ну а самая ж*па - это если ты такие урлы поисковикам скормишь. Долго будешь потом удивляться, почему к тебе никто попасть не может 

Ну и по остальным позициям примерно такая же петрушка. Для тебя 5 процентов недопродаж - это катастрофа, а для просто вебмастера - пшик. Ну пришел параноик, и бог с ним, болезным. Никто ведь его не гонит. Пусть себе ходит, глазеет по сторонам. А что зарегиться не может - ну и пофиг, его проблемы.

Ну или вот ты говоришь фаервол. Его ведь тоже конфигурять нужно, администрить. Но самое главное: он же не может передать инфу в сервлет. А фильтр - может! Сколько чего нароет, столько и напихает в атрибуты запроса.

Так штаа...  

ну это все очевидно  более милиона пользователей аналогового доступа в нет немецкого провайдера AOL ходят с 4х IP-ов  
я не внимательно прочел вопрос. я думал он спрашивает в контексте DOS атак  ну т.е. каким образом НЕ создавать сессию если IP не нравиться.


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

нормальные поисковики кстати умеют куки и все эти линки с сессиями не попадают туда. 

по поводу фильтра смотри. сначала твой HTTP сервер должен получить запрос и перенаправить его твоему сервлет контейнеру. потом сервлет контейнер должен его преврать в объект HttpRequest и передать фильтру. это очень много работы которая отъедает ресурсы твоего вэб сервера. ещё до того как твой фильтр заработал. так что любаай серьезная атака вынесет твой вэб сервер на два порядка быстрее чем фаерфолл который делает фильтрацию на гораздо более низком уровне затрачивая намного меньше аппаратных ресурсов кроме того я хотел бы посмотреть на сервлетный фильт в полной мере реализуюшил логику интелектульного обнаружения распределенных дос атак. это будет фильтр километровой длины и работать будет с сответсвующей скоростью )

да фаер надо конфенурить. но это не проблемма разработчика вэб приложения. это проблемы администраторов их спец обородования и снец софта и они это сделают гораздо эфективнее. не нужно брать на себя не свою работу.
да фаер не может передать инфу вэб приложению. но дело то в том что я и не хочу эту инфу получать! я хочу чтобы со злом разобрались не то что до моего вэб приложения но даже до моего вэб сервера.

ну магазин не магазин но за посетителей надо бороться.  в конце концов они - наши деньги. и я не хочу терять поситителей изза такой ерунды как отсутсвие куки 
5% это 10000 EUR продажного оборота в сутки для вэб магазина бытовой электроники средне-мелкого размера... так что думайте сами...
 

Вот я и говорю: разная у нас аксиоматика 

То, что хорошо для магазина, не всегда годится для информационного вебсайта, и наоборот: разные цели, разные требования, своя специфика, свои особенности трафика и пр. В общем, универсальных рецептов нет, а то, что мы тут написали, пусть послужит в качестве guidelines.

 

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

UnicornMirage, в томкате можно реализовать свой SessionManager.