Как стать автором
Обновить

Утечка конфиденциальных данных при кешировании сетевых запросов на платформе iOS

Время на прочтение7 мин
Количество просмотров6.4K
Всего голосов 13: ↑13 и ↓0+13
Комментарии10

Комментарии 10

Если уж и кешировать сетевые запросы, то понятно, что не нужно кешировать конфиденциальные данные КО!
Спасибо за замечание. Идеей статьи было продемонстрировать, что поведение NSURLConnection является потенциально уязвимым. Кэширование происходит совершенно прозрачно (т.е. неявно) для разработчика и поэтому может стать причиной утечки конфиденциальных данных, например, вследствие неосведомленности разработчика о тонкостях поведения NSURLCache.
НЛО прилетело и опубликовало эту надпись здесь
лол, а чем пост защищенней? тем что в урле не палится? очень странное у вас представление о безопасности
В целом, POST лучше. Это если рассматривать общий случай:

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

Безопасность!
НЛО прилетело и опубликовало эту надпись здесь
бороться надо не с последствиями :)
НЛО прилетело и опубликовало эту надпись здесь
ага, а в коде mysql_query(«select * from users where password=». $_REQUEST[password])
Зарегистрируйтесь на Хабре, чтобы оставить комментарий