ты по-моему не понимаешь в чём дело. инъекция в куки, так ? справа - ключ, слева - сама сессия в base64. ключ является проверкой сессии на корректность (отсутствие левых элементов, кавычек, итд). когда ключ не совпадает - сессия не пашет. ты говоришь о чём-то другом.

ставлю вопрос так: каким алгоритмом может быть произведена проверка сессии через хэш ? 40 символов - Sha 1, но я не могу получить туже сумму при переводе чистой сессии или же base64 кода в неё. что-то тут не так.

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

1. Меняем переменную, запоминаем, что поменяли. Хэш оставляем прежним.

2. Отправляем кук на сервер.

3. Вернул ошибку - переменная участвует в "формировании" хэша, нет - тестим следующую.

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

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

Также думаю, что затея с куками слишком уж трудоёмкая, и стоит поискать более "классические" дырки типа sql-inj, инклудов или XSS'ок...

жжете

Поняша,тут и есть sql inj,только в куках)

Но тут не уязвимо

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