Комментарии 10
Если уж и кешировать сетевые запросы, то понятно, что не нужно кешировать конфиденциальные данные КО!
Спасибо за замечание. Идеей статьи было продемонстрировать, что поведение NSURLConnection является потенциально уязвимым. Кэширование происходит совершенно прозрачно (т.е. неявно) для разработчика и поэтому может стать причиной утечки конфиденциальных данных, например, вследствие неосведомленности разработчика о тонкостях поведения NSURLCache.
НЛО прилетело и опубликовало эту надпись здесь
лол, а чем пост защищенней? тем что в урле не палится? очень странное у вас представление о безопасности
В целом, POST лучше. Это если рассматривать общий случай:
1) пароли не сохраняются в дефолтовые логи апача
2) пароли не сохраняются в истории браузера
3) пароли не рискуют утечь через «Referer:», хотя зависит от ряда условий конечно, но все же…
Это в общем случае для юзер-форм аутентификации.
В REST API, более значима проблема 1). То есть надо париться с логингом, что бы пароли не сохранять на сервере в открытом виде.
1) пароли не сохраняются в дефолтовые логи апача
2) пароли не сохраняются в истории браузера
3) пароли не рискуют утечь через «Referer:», хотя зависит от ряда условий конечно, но все же…
Это в общем случае для юзер-форм аутентификации.
В REST API, более значима проблема 1). То есть надо париться с логингом, что бы пароли не сохранять на сервере в открытом виде.
Грубо говоря:
GET /page/?password=qwerty HTTP/1.1
Host: bestonlinefreesecurity.com
vs
POST /page/ HTTP/1.1
Host: bestonlinefreesecurity.com
password=qwerty
Безопасность!
GET /page/?password=qwerty HTTP/1.1
Host: bestonlinefreesecurity.com
vs
POST /page/ HTTP/1.1
Host: bestonlinefreesecurity.com
password=qwerty
Безопасность!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Утечка конфиденциальных данных при кешировании сетевых запросов на платформе iOS