Итак, ваш вопрос поднимает пару вопросов, о которых я хотел бы знать больше, но я постараюсь изо всех сил, чтобы хотя бы наметить вещи ...
Ваш браузер кэширует URL-адреса, которые содержат конфиденциальную / защищенную информацию в пути, таким образом оставляя потенциальное окно для вашей личной информации для других. Последствия:
- Кто-то может подойти к вашему компьютеру, когда вас нет, или, возможно, получить доступ к вашему компьютеру удаленно, или - если надлежащие меры предосторожности не приняты на нескольких уровнях - использовать метод XSS для получения ваших кэшированных URL-адресов через javascript .
И проблема законна, но вы уже указали, какие шаги вы можете предпринять, чтобы облегчить их:
Не открывайте несколько окон, некоторые частные, некоторые не такие приватные. Используйте частные сеансы браузера для личного просмотра. У меня действительно была идея для надстройки Firefox, которая позволила бы вам создать своего рода «темный список», список доменов, которые всегда должны быть в режиме инкогнито. Таким образом, вы можете быть на своем банковском сайте, переключиться на твиттер, и он знает, что у него могут быть разные сессии и т. Д.
Настройте браузер на удаление (или хотя бы запрос на удаление) всех личных данных при каждом закрытии.
На стороне сервера ни один ответственный разработчик веб-приложений не должен КОГДА-ЛИБО использовать учетные данные или личные данные в URL для защищенного сайта. Это не гладко, это лениво. Я думаю, что идентификационные номера или идентификаторы сессии не намного лучше (я вернусь к этому во втором пункте). Ваш банк должен использовать: /onlinebanking/UserServices/transactions в качестве URL-адреса RESTful и должен подтверждать все по каждому запросу, вплоть до IP, на уровне сервера (mod_auth и чертовски хороший сертификат). Я очень устал, когда люди говорят о «снижении нагрузки на сервер» или даже о «снижении количества обращений к базе данных». Программное обеспечение специально разработано для получения большого количества запросов. Мой ноутбук HP, построенный 6 лет назад и похожий на старый холодильник, НЕ был разработан для того, чтобы облегчить нагрузку на сервер, и ожидание 10 минут плохо спроектированного js-скрипта (см .: новый почтовый клиент Yahoo!) вызывает у меня желание нанести удар. И если больше нечего ожидать от плохого испорченного гигантского сервера, он должен обеспечивать вашу безопасность КАЖДЫЙ раз.
Хорошо, эта напыщенная речь окончена.
- Может ли ваш брат видеть ваши кэшированные URL-адреса? Может быть. Моя подруга может сказать, когда я заходил на сайты ххх, даже когда я очищаю историю (почему? Потому что она все еще отображается в недавно закрытых вкладках! Да, конфиденциальность!) И они не кэшируются для RESTfulness, они кэшируются Потому что это то, что делают браузеры. Таким образом, вы должны принять те же меры предосторожности после перехода на сайт с
iamgoingtokillhimtonight/posts в URL-адресе, что и для того, чтобы скрыть свое «я», когда вы заходите на сайты прона или просматриваете день рождения. настоящие идеи.
В части моей интерпретации:
Так что да, URL-адреса кэшируются, и это страшно для любого, кто хочет просмотреть указанный кеш, чтобы попасть в ваш бизнес. Но, похоже, другая проблема, которую вы выражаете, это то, что они могут с этим сделать, то есть кросс-браузерные эксплойты. Может ли кто-то использовать этот кэшированный URL-адрес, чтобы создать сценарий, чтобы получить информацию о вашем банке и уничтожить вас? Да. Но преимущество, которое они получают, если они уже знают, как это сделать, невелико. Это больше похоже на то, чтобы сохранить им шаг, а не оставлять ключи в дверях. Если я смогу каким-то образом увидеть ваш кеш через js и, таким образом, увидеть URL-адрес вашего безопасного банка, то я мог бы так же легко увидеть URL-адрес вашего банка, если они не использовали симпатичный URL, и так же легко написать мой XSS вокруг него. И если я смогу увидеть ваш кеш, я наверняка смогу увидеть ваши куки и украсть их (только в Интернете файлы cookie стоят больше, чем кеш). Поэтому применяются те же правила до AJAX:
- Пользователи не должны записывать пароли
- Срок действия файлов cookie сеанса должен истечь в конце сеансов
- веб-приложения должны использовать белые списки, сертификаты и одноразовые номера для обеспечения целостности и подлинности запросов пользователя.
Я не могу не подчеркнуть, насколько успех XSS основан на лени (или невежестве) разработчиков (включая меня) и растерянности и наивности пользователей. Большинство действительно больших результатов XSS включают в себя социальные хакинг до интернет-хакерства. Фишинг-мошенничество или письмо от старого друга или испанского заключенного, просто просит вас перейти по этой невинной ссылке или поделиться какой-то бессмысленной личной информацией. Одна вещь, которую я мог видеть на примере вашего банка, которая усугубила бы ситуацию, заключается в том, что теперь я знаю по этому сайту, что ваше имя - Алекс, а по URL-адресу - ваша фамилия - Форестер. Это может упростить поиск подробностей, чтобы облегчить получение другой информации.
Итак, в общем и целом, наконец:
RESTfulness и AJAX не представляют намного большей угрозы, чем история браузера и плохая безопасность сервера, и поэтому одни и те же правила применяются как к пользователям, так и к разработчикам. Но вы совершенно правы, что такие RESTful URL указывают на то, что мы ухудшаем эти методы, а не улучшаем; использовать технологию, чтобы быть ленивее, вместо того, чтобы использовать преимущество, чтобы сосредоточиться на реальной тяжелой работе.
Ну, это было весело. Вернуться к соляным шахтам.