ANTICHAT — форум по информационной безопасности, OSINT и технологиям
ANTICHAT — русскоязычное сообщество по безопасности, OSINT и программированию.
Форум ранее работал на доменах antichat.ru, antichat.com и antichat.club,
и теперь снова доступен на новом адресе —
forum.antichat.xyz.
Форум восстановлен и продолжает развитие: доступны архивные темы, добавляются новые обсуждения и материалы.
⚠️ Старые аккаунты восстановить невозможно — необходимо зарегистрироваться заново.
 |
|

21.07.2013, 18:52
|
|
Постоянный
Регистрация: 15.03.2009
Сообщений: 435
Провел на форуме: 4061203
Репутация:
704
|
|
Понимаешь,exT1ma4ka!Что бы тут была уязвимость,надо поставить ковычку и при обновлении страницы должны быть sql ошибка,которая скажет о налиции уязвимости.
То что ты делаешь вообще к уязвимостям не относится
С Уважением,InDuStRieS!
|
|
|

21.07.2013, 21:26
|
|
Новичок
Регистрация: 12.05.2010
Сообщений: 10
Провел на форуме: 37183
Репутация:
0
|
|
ты по-моему не понимаешь в чём дело. инъекция в куки, так ? справа - ключ, слева - сама сессия в base64. ключ является проверкой сессии на корректность (отсутствие левых элементов, кавычек, итд). когда ключ не совпадает - сессия не пашет. ты говоришь о чём-то другом.
ставлю вопрос так: каким алгоритмом может быть произведена проверка сессии через хэш ? 40 символов - Sha 1, но я не могу получить туже сумму при переводе чистой сессии или же base64 кода в неё. что-то тут не так.
|
|
|

21.07.2013, 21:54
|
|
Новичок
Регистрация: 21.06.2005
Сообщений: 1
Провел на форуме: 0
Репутация:
0
|
|
Возможно (в самом простом случае), некоторые поля из левой части проходят объединение, и результат такой вот конкатенации обсчитывается в хэш, который является проверкой, не подкрутил ли чего юзер в куках (его мы и видим в правой части). Вся проблема - узнать, какие параметры и каким образом между собой комбинируются. Тут есть величайшее множество возможных реализаций, которые наверняка можно узнать, лишь докопавшись до исходников сайта. В самом элементарном варианте, который я описал, узнать, какие переменные используются при генерации хэша, можно так:
1. Меняем переменную, запоминаем, что поменяли. Хэш оставляем прежним.
2. Отправляем кук на сервер.
3. Вернул ошибку - переменная участвует в "формировании" хэша, нет - тестим следующую.
Но здесь всё может пойти прахом (даже если мы узнаем, какие переменные проходят конкатенацию, а какие - нет), если потом они как-то модифицируются (например, между ними ставится тире, и от полученной строки считается хэш)... В общем, самый верный вариант - копать исходники, как ни крути.
Если где-то сморозил глупость - сильно не бейте, просто высказал свои мысли, на практике ничем таким никогда заниматься не приходилось.
Также думаю, что затея с куками слишком уж трудоёмкая, и стоит поискать более "классические" дырки типа sql-inj, инклудов или XSS'ок...
|
|
|

21.07.2013, 22:10
|
|
Постоянный
Регистрация: 15.03.2009
Сообщений: 435
Провел на форуме: 4061203
Репутация:
704
|
|
жжете
Поняша,тут и есть sql inj,только в куках)
Но тут не уязвимо
|
|
|

21.07.2013, 22:22
|
|
Новичок
Регистрация: 12.05.2010
Сообщений: 10
Провел на форуме: 37183
Репутация:
0
|
|
H3L1X, тесты проводились, боюсь вся строка участвует в формировании хэша. даже когда переставляешь переменные местами - всё рушится.
|
|
|
|
 |
|
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
|
|
|
|