Comments 10
Если уж и кешировать сетевые запросы, то понятно, что не нужно кешировать конфиденциальные данные КО!
Спасибо за замечание. Идеей статьи было продемонстрировать, что поведение NSURLConnection является потенциально уязвимым. Кэширование происходит совершенно прозрачно (т.е. неявно) для разработчика и поэтому может стать причиной утечки конфиденциальных данных, например, вследствие неосведомленности разработчика о тонкостях поведения NSURLCache.
UFO just landed and posted this here
лол, а чем пост защищенней? тем что в урле не палится? очень странное у вас представление о безопасности
В целом, 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
Безопасность!
Sign up to leave a comment.
Утечка конфиденциальных данных при кешировании сетевых запросов на платформе iOS