там, где идёт работа с деньгами, к вам приезжают консультанты, ведут вас играть в гольф и кататься на яхте, и между делом продают вам решения за $30 000 000 ; )
во-первых, хочу уточнить про PUT/POST в REST, а то в посте они перепутаны. PUT — создание, POST — обновление
во-вторых, WS-* кажется мягким и шелковистым до тех пор, пока не влезаете в legacy код, и не начинаете разгребать чужие грабли. Вот тогда вам придётся собирать эти дикие запросы руками, и вы быстро разлюбите эту семейку протоколов. И не надейтесь, что legacy код бывает только у идиотов, с которыми вам не придётся работать — я лично бился с API не какой-то шарашкиной конторы, а самого Google, у которого WSDL не соответствовал реальности, а обновить они его не могли. Очень было весело… Такая психология «инструменты всё сделают за нас» была очень популярна в первые годы XML, но довольно быстро сошла на нет. Далеко не всегда инструменты защитят вас от кромешного ужаса.
для меня самым ярким примером глупости WS-* было то, что в нём есть аналог HTTP, при том, что сам WS-* работает на HTTP. Получается такой HTTP-over-HTTP.
а, пожалуй, решающий аргумент за REST состоит в том, что он на порядки лучше интегрируется в веб, потому что он и есть веб — его очень просто, легко и эффективно кешировать, балансировать, шардить и прочая, и прочая — и всё это существующим дешёвым железом общего назначения. У нас есть перед глазами пример интернета — невероятно успешной огромной сети, и HTTP — одна из главных причин такой её масштабируемости. Глупо выбрасывать работающий и надёжно проверенный инструмент. Пользуйтесь HTTP, а не WS-*/SOAP
я не буду дальше в комментах что-то доказывать, просто для пользы хабра хочу, чтобы тут были эти слова
я не понимаю, как вы можете называть уязвимости уязвимостями и при этом говорить, что это не проблемы. Уязвимости — это проблемы, а не архитектурные особенности. Уязвимости устраняются. Куча других уязвимостей во флеше уже устранена, хотя про них тоже можно было бы сказать «ну флеш — это по факту системное приложение…»
браузер, вообще-то, тоже системное приложение, которое подобно флеш-плагину интерпретирует скрипты. Вы хотите сказать, что дыры в IE — это не проблемы IE?
вообще-то ещё один из хороших принципов REST состоит в том, чтобы не дублировать в запросе методы. Когда вы хотите что-то получить, вы используете HTTP-метод GET, и нет смысла писать в урле /user/getInfo, достаточно просто /user/info. Когда вы хотите что-то добавить, вы используете HTTP-метод PUT на урл /comments, удалить — метод DELETE на тот же урл. Большинство глаголов в урлах становятся не нужны.
короче:
GET /user/info — прочитать информацию
POST /user/info — обновить информацию
GET /item/comments — получить комментарии
PUT /item/comments — добавить комментарий
DELETE /item/comments — удалить комментарий
It required uploading the SWF to my own account, then logging the victim into that account (via CSRF), loading the SWF into the browser, logging them out, and enticing the user to log in while keeping the original page loaded
речь идёт именно об swf, а не о письме с опасным embed — с фильтрацией-то в gmail наверняка всё в порядке
> покажите, пожалуйста, хоть один веб-сервер который по-умолчанию определяет mime тип по внутренним соображениям, при этом не принимая во внимание расширение файла.
тот, который на mail.google.com, что продемонстрировано по ссылке в посте
я не эксперт по безопасности, поэтому точно не скажу
и всё-таки давайте не забывать, что далеко не все веб-сервера отдают content-type. Например, на ya.ru картинки отдаются без него. А nginx очень популярен как раз для файлохостингов
вот на такой необоснованной уверенности обычно и попадаются ; )
необходимые пояснения:
* уверенность названа необоснованной из-за слов «почему-то есть уверенность»
* конкретно яндекс-диск скорее всего не подвержен уязвимости, я его привёл как доступный пример файлохостинга
* если в списке проверок автоопределителя типов проверка на флеш происходит до проверки на зип, то файл определится как флеш
нет, для этого достаточно на хабре запостить ссылку на этот зип с заголовком «получи айфон бесплатно»: юзер кликает по ссылке, у него на весь экран открывается флеш и делает своё чёрное дело
вообще-то флеш продвигается как безопасный контент, которого не выпускают из песочницы и не дают ему острых предметов, удивительно, что вы не знали об этом; )
просто внезапно оказалось, что в песочнице хранятся особо ценные печеньки
там сказано, что ваши фильтры не помогут, если юзеры могут загружать зипы, потому что зип-файл остаётся зип-файлом, даже если ему в начало вставлен флеш. Кажется, то же самое там и про pdf и прочие казалось бы безобидные форматы. Фильтр посмотрит, что это зип, и пропустит файл.
во-вторых, WS-* кажется мягким и шелковистым до тех пор, пока не влезаете в legacy код, и не начинаете разгребать чужие грабли. Вот тогда вам придётся собирать эти дикие запросы руками, и вы быстро разлюбите эту семейку протоколов. И не надейтесь, что legacy код бывает только у идиотов, с которыми вам не придётся работать — я лично бился с API не какой-то шарашкиной конторы, а самого Google, у которого WSDL не соответствовал реальности, а обновить они его не могли. Очень было весело… Такая психология «инструменты всё сделают за нас» была очень популярна в первые годы XML, но довольно быстро сошла на нет. Далеко не всегда инструменты защитят вас от кромешного ужаса.
для меня самым ярким примером глупости WS-* было то, что в нём есть аналог HTTP, при том, что сам WS-* работает на HTTP. Получается такой HTTP-over-HTTP.
а, пожалуй, решающий аргумент за REST состоит в том, что он на порядки лучше интегрируется в веб, потому что он и есть веб — его очень просто, легко и эффективно кешировать, балансировать, шардить и прочая, и прочая — и всё это существующим дешёвым железом общего назначения. У нас есть перед глазами пример интернета — невероятно успешной огромной сети, и HTTP — одна из главных причин такой её масштабируемости. Глупо выбрасывать работающий и надёжно проверенный инструмент. Пользуйтесь HTTP, а не WS-*/SOAP
я не буду дальше в комментах что-то доказывать, просто для пользы хабра хочу, чтобы тут были эти слова
браузер, вообще-то, тоже системное приложение, которое подобно флеш-плагину интерпретирует скрипты. Вы хотите сказать, что дыры в IE — это не проблемы IE?
короче:
GET /user/info — прочитать информацию
POST /user/info — обновить информацию
GET /item/comments — получить комментарии
PUT /item/comments — добавить комментарий
DELETE /item/comments — удалить комментарий
и так далее
речь идёт именно об swf, а не о письме с опасным embed — с фильтрацией-то в gmail наверняка всё в порядке
> покажите, пожалуйста, хоть один веб-сервер который по-умолчанию определяет mime тип по внутренним соображениям, при этом не принимая во внимание расширение файла.
тот, который на mail.google.com, что продемонстрировано по ссылке в посте
drafonfly меня подвёл, показал не все заголовки : (
я не эксперт по безопасности, поэтому точно не скажу
и всё-таки давайте не забывать, что далеко не все веб-сервера отдают content-type. Например, на ya.ru картинки отдаются без него. А nginx очень популярен как раз для файлохостингов
необходимые пояснения:
* уверенность названа необоснованной из-за слов «почему-то есть уверенность»
* конкретно яндекс-диск скорее всего не подвержен уязвимости, я его привёл как доступный пример файлохостинга
* если в списке проверок автоопределителя типов проверка на флеш происходит до проверки на зип, то файл определится как флеш
вы не поняли. Я выкладываю этот «зип» на яндекс.диск, и он ломает именно яндекс, а хабр мне нужен только для того, чтобы люди перешли по ссылке
неизвестно, как именно определится майм-тип у такого «троянского коня»
ps: если что, я знаю, что под троянами сейчас обычно имеют в виду другое
просто внезапно оказалось, что в песочнице хранятся особо ценные печеньки
Released: 02 Nov 2006
«new attribute is introduced to cookies for Internet Explorer 6 SP1» ( msdn.microsoft.com/en-us/library/ms533046(VS.85).aspx )
Internet Explorer 6 Service Pack 1 Released ( www.techzonez.com/forums/showthread.php?t=2147 ), September 9th, 2002
эту фичу можно использовать уже больше 9 лет ; )