POST так же безопасен, как Cookie? - PullRequest
1 голос
/ 26 февраля 2009

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

Мы придумали и внедрили функциональное решение для проверки POST PHPSESSID.

Является ли отправка идентификатора сеанса такой же безопасной, как отправка его в файле cookie?

Возможная причина: потому что оба находятся в заголовке http, и одинаково возможно для клиента подделать. Возможная причина против: потому что проще подделать переменную POST, чем Cookie.

Ответы [ 6 ]

5 голосов
/ 26 февраля 2009

Это так же безопасно - подделать POST так же легко, как cookie. И то, и другое делается просто установкой флагов в cURL.

При этом, я думаю, у вас также есть хорошее решение.

2 голосов
/ 26 февраля 2009

Я думаю, что отправка через GET также будет работать нормально, поскольку вы подделываете что-либо в HTTP-запросе (используя curl или даже flash). Важно то, что зашифровано в вашем параметре cookie / post / get и как оно шифруется и проверяется на стороне сервера.

2 голосов
/ 26 февраля 2009

Если вы можете получить идентификатор сеанса из активного содержимого для его POST, это, вероятно, означает, что ваш cookie сеанса не помечен HttpOnly , который один из наших хостов утверждает, в противном случае хорошая идея для защиты от межсайтовых скриптовых атак .

Вместо этого рассмотрим монитор загрузчика на основе JavaScript или даже обновления, который должен достаточно хорошо интегрироваться со всем остальным, чтобы файл cookie мог быть HttpOnly.

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

1 голос
/ 26 февраля 2009

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

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

0 голосов
/ 26 февраля 2009

Я просто хочу повторить, что и Cookie, и Post одинаково небезопасны.

0 голосов
/ 26 февраля 2009

Данные POST не являются заголовком HTTP, но они отправляются как часть потока TCP, что делает его таким же простым для чтения / подделки, как заголовок HTTP. Если вы перехватите HTTP-запрос, он будет выглядеть примерно так:

POST /path/to/script HTTP/1.1
Host: yourdomain.com
User-Agent: Mozilla/99.9 (blahblahblah)
Cookie: __utma=whateverthisisacookievalue;phpsessid=somePHPsessionID

data=thisisthepostdata&otherdata=moredummydata&etc=blah

Таким образом, как уже говорили другие, POST и куки-файлы (и данные GET, то есть строки запросов) легко подделать, поскольку все они - просто текст в одном и том же пакете HTTP.

...