28 ноября 2008, 21:43 (5618 дней назад, №8747)"Web 3.0" и проблемы с безопасностью при разработке виджетов
Становится всё более ясным, что следующий этап развития Интернет выразится в переходе от сайтов с веб-страничками (неважно, статическими или динамическими) и браузеров, эти странички показывающих, к сервисам с документированным API и отдельным приложениям (Flex/Flash, Silverlight, Java(FX) и т.п.), которые будут с этими сервисами работать. Пока что эти приложения (часто называемые виджетами) мы чаще используем внутри браузера, но это, по-видимому, ненадолго, т.к. всем хочется интеграции с операционной системой, единого clipboard'а, drag-n-drop'a между различными приложениями и т.п. (Adobe AIR).
Помимо понятных угроз из-за доступности такому приложению вызовов функций ОС и доступа к её файлам, существует как минимум одна менее очевидная:
В любом сервисе, доступ к которому как-то ограничен (например, платном) существует понятие секретного ключа, по которому этот сервис идентифицирует конкретное приложение-клиент, имеющее право к нему обращаться.
До сих пор обработка данных и выполнение кода происходили главным образом не на клиенте и передача этого ключа осуществлялась между сервером на котором находится сайт и сервером предоставляющим сервис, благодаря чему пользователь-злоумышленник не мог получить этот ключ.
Теперь же ситуация принципиально меняется - приложение запускается на компьютере пользователя и связывается с удалённым сервером, предъявляя ему этот самый ключ. Если пользователь задумал плохое, у него целых два довольно простых пути - он может декомпилировать приложение и найти ключ, либо проанализировать трафик с той же целью.
В идеале, конечно, регистрация на сервисах должна быть организована так, чтобы собственный ключ получал каждый новый пользователь приложения. По разным причинам, на практике это почти всегда не так. Т.е. если я хочу сделать виджет, показывающий, к примеру, погоду, то, регистрируясь в сервисе предоставляющем погоду в виде XML, я получаю один ключ для моего виджета. Соответственно, любой пользователь виджета, узнав этот ключ, может сделать такой же виджет и получать информацию о погоде за мои деньги.
Два выхода, которые могут как-то решить проблему - это HTTPS/TLS (мало какие сервисы его предоставляют и весьма неохотно - нагрузка на сервер возрастает) либо прокси, когда наш виджет все запросы пускает через наш же промежуточный прокси сервер, где к запросу добавляется ключ (недостаток - трафик через наш сервер плюс нагрузка на него же).
Бывают комбинированные решения. Например, в сервисе Amazon S3 можно запросы посылать через прокси (т.к. трафик небольшой), а файлы напрямую, предъявляя временный/сессионный ключ, полученный на запрос посланный ранее через прокси :)
В целом же описанная ситуация привела к тому, что виджетов, где пользователь платит за услугу значительные деньги или рискует важными данными - появляется мало. Скажу больше, у меня крепнет убеждение, что нежелание сервисов класть себе в корень файл crossdomain.xml (чтобы позволить прямые обращения к ним из Flex приложений) обусловлено нежеланием ассоциировать себя с массовыми потерями денег и данных пользователей и владельцев приложений.
"Finally, we come to the instruction we've all been waiting for – SEX!" / из статьи про микропроцессор CDP1802 / В начале 1970-х в США были весьма популярны простые электронные игры типа Pong (в СССР их аналоги появились в продаже через 5-10 лет). Как правило, такие игры не имели микропроцессора и памяти в современном понимании этих слов, а строились на жёсткой ...далее