?

Log in

No account? Create an account

Previous Entry | Next Entry

Становится всё более ясным, что следующий этап развития Интернет выразится в переходе от сайтов с веб-страничками (неважно, статическими или динамическими) и браузеров, эти странички показывающих, к сервисам с документированным API и отдельным приложениям (Flex/Flash, Silverlight, Java(FX) и т.п.), которые будут с этими сервисами работать. Пока что эти приложения (часто называемые виджетами) мы чаще используем внутри браузера, но это, по-видимому, ненадолго, т.к. всем хочется интеграции с операционной системой, единого clipboard'а, drag-n-drop'a между различными приложениями и т.п. (Adobe AIR).

Помимо понятных угроз из-за доступности такому приложению вызовов функций ОС и доступа к её файлам, существует как минимум одна менее очевидная:
 

В любом сервисе, доступ к которому как-то ограничен (например, платном) существует понятие секретного ключа, по которому этот сервис идентифицирует конкретное приложение-клиент, имеющее право к нему обращаться.
До сих пор обработка данных и выполнение кода происходили главным образом не на клиенте и передача этого ключа осуществлялась между сервером на котором находится сайт и сервером предоставляющим сервис, благодаря чему пользователь-злоумышленник не мог получить этот ключ.
Теперь же ситуация принципиально меняется - приложение запускается на компьютере пользователя и связывается с удалённым сервером, предъявляя ему этот самый ключ. Если пользователь задумал плохое, у него целых два довольно простых пути - он может декомпилировать приложение и найти ключ, либо проанализировать трафик с той же целью.

В идеале, конечно, регистрация на сервисах должна быть организована так, чтобы собственный ключ получал каждый новый пользователь приложения. По разным причинам, на практике это почти всегда не так. Т.е. если я хочу сделать виджет, показывающий, к примеру, погоду, то, регистрируясь в сервисе предоставляющем погоду в виде XML, я получаю один ключ для моего виджета.  Соответственно, любой пользователь виджета, узнав этот ключ, может сделать такой же виджет и получать информацию о погоде за мои деньги.
Два выхода, которые могут как-то решить проблему - это HTTPS/TLS (мало какие сервисы его предоставляют и весьма неохотно - нагрузка на сервер возрастает) либо прокси, когда наш виджет все запросы пускает через наш же промежуточный прокси сервер, где к запросу добавляется ключ (недостаток - трафик через наш сервер плюс нагрузка на него же).
Бывают комбинированные решения. Например, в сервисе Amazon S3 можно запросы посылать через прокси (т.к. трафик небольшой), а файлы напрямую, предъявляя временный/сессионный ключ, полученный на запрос посланный ранее через прокси :)

В целом же описанная ситуация привела к тому, что виджетов, где пользователь платит за услугу значительные деньги или рискует важными данными - появляется мало. Скажу больше, у меня крепнет убеждение, что нежелание сервисов класть себе в корень файл crossdomain.xml (чтобы позволить прямые обращения к ним из Flex приложений) обусловлено нежеланием ассоциировать себя с массовыми потерями денег и данных пользователей и владельцев приложений.

Tags:

Comments

( 5 comments — Leave a comment )
fester_ua
Nov. 29th, 2008 02:10 am (UTC)
Я пока не вижу некоей консистентной среды для исполнения "web applications". Каждая из обозначеных технологий имеет тонны недостатков, и, я надеюсь, не станет industry standart™.
cr_it
Nov. 29th, 2008 10:33 am (UTC)
Так фишка как раз в том, что это неважно. Т.е. важно разработчику, но никак не пользователю приложения. Ну попросят его лишний раз нажать "Yes", потратится лишняя минута на установку плейера для какого-нибудь Silverlight под Solaris (шучу :) - по большому счёту это ни на что не влияет, ибо происходит редко и быстро. Стандартизация тут непринципиальна.
fester_ua
Nov. 29th, 2008 12:38 pm (UTC)
Для меня, как веб-девелопера, это как раз важно. Вот конкретно сейчас занимаюсь разработкой сокет-сервера для браузерной игрушки, с клиентом в флеше, так напарника, который пишет непосредственно клиентскую часть иногда больно слушать. Юзерам оно всё одно, а разработчикам лишние геморройные шишки заводить.
cr_it
Nov. 29th, 2008 02:22 pm (UTC)
Приложения всё же ориентированы на пользователей, так что придётся терпеть :)
Что до конкретики, то мне в качестве платформы Flex/AS3 очень нравится. Последнее время стали чрезвычайно напрягать ужесточения, которые Adobe стал делать в угоду безопасности (все эти бесконечные crossdomain.xml, socket policy server'ы, ограничения для FileReference и прочее - что ни новая версия Player'а, то сюрприз), но меня очень радует общее направление в котором развивается платформа. Я опасался, что после покупки Adobe'ом Flash станет громоздким и тормозным, но так не произошло. Людям хватило смелости поменять AVM на AVM2, AS2 на AS3, поступившись совместимостью, но зато сделав всё по-человечески. Такое редко бывает в подобных проектах. С другой стороны понятно, что если бы они не чувствовали опасность со стороны конкурентов (тот же Silverlight), то вряд ли бы стали шевелиться.
fester_ua
Nov. 29th, 2008 03:07 pm (UTC)
У меня в отношении Flash надежда только на проект, о котором недавно услышал -- использование Ruby вместо AS. Я, конечно, понимаю, что все языки это только syntax sugar вокруг Тьюринговских изысканий, но этот AS использовать просто невозможно. Ну и минус к "стандартизации" флеша -- закрытость. Стандарты такого уровня не должны быть пропиетарными.
( 5 comments — Leave a comment )