Google Web Toolkit Безопасность бизнес-приложений

Содержание

Слайд 2

Появление GWT Google Web Toolkit (GWT) был неожиданно открыт для публики

Появление GWT

Google Web Toolkit (GWT) был неожиданно открыт для публики 18

мая 2006 года на ежегодной конференции JavaOne в Сан-Франциско. Цель, которая стояла перед GWT, была очень простой: сделать разработку с помощью технологии Ajax проще за счет сокрытия несовместимостей браузеров от программиста и позволить разработчику работать в среде, подобной Java.
Слайд 3

Принципы GWT Google Web Toolkit объединяет клиентский и серверный код в

Принципы GWT

Google Web Toolkit объединяет клиентский и серверный код в отдельном

приложении, написанном на одном языке - Java. Это имеет ряд преимуществ. С одной стороны, довольно много разработчиков знают Java и JavaScript или Flash. С другой стороны, Java изобилит средствами разработки, такими как Eclipse, NetBeans и IDEA. GWT позволяет создавать web-приложения так же, как вы создаете Swing приложения, обеспечивая создание визуальных компонентов, установку обработчиков событий, отладку и т.д. - все в пределах стандартной IDE.
Слайд 4

Источник уязвимости Необходимо учитывать, что код Java, написанный в удобной IDE,

Источник уязвимости

Необходимо учитывать, что код Java, написанный в удобной IDE, в

конце концов, преобразуется в код JavaScript и будет исполняться в клиентском браузере. Поэтому GWT неявно перенимает все недостатки JavaScript, которые существуют на сегодняшний день. Разработчики Google максимально позаботились об общих вещах безопасности, но не меньшая ответственность в обеспечении безопасности лежит на программистах, использующих GWT.
Слайд 5

Угрозы При рассмотрении угроз для технологии GWT следует учитывать как угрозы

Угрозы

При рассмотрении угроз для технологии GWT следует учитывать как угрозы к

самой технологии – стандартным классам, взаимодействию клиента с сервером по протоколу GWT RPC, - так и угрозы, которые необходимо учитывать программисту при проектировании и разработке программного комплекса.
Слайд 6

Угрозы Эти проблемы, как и многие другие в интернете, берут начало

Угрозы

Эти проблемы, как и многие другие в интернете, берут начало от

вредоносных программистов. Люди, которые проводят огромный процент своей жизни над размышлениями о том, как украсть данные. Продавцы web браузеров вносят свой вклад в борьбу с этими людьми и один из путей осуществления этого Same-Origin Policy.
Слайд 7

Same-Origin Policy Same-Origin Policy (SOP) говорит, что код, запущенный на странице,

Same-Origin Policy

Same-Origin Policy (SOP) говорит, что код, запущенный на странице, который

был загружен с Сайта А, не может иметь доступа к данным или к сетевым ресурсам, принадлежащим любому другому сайту или даже любой другой странице (кроме других страниц, которые также загружены с Сайта А). Целью является предотвращение инъекции вредного кода хакерами в Сайт А, собирающего ваши личные данные и отправляющего Сайту В. Это, конечно, известные ограничения, защищающие AJAX код от XMLHTTPRequest вызовов к URL, который не является тем же сайтом, с текущей страницей.
Слайд 8

Варианты XSS взлома злой код создает невидимый iframe и добавляет в

Варианты XSS взлома

злой код создает невидимый iframe и добавляет в него

. Действие формы устанавливается в URL сервера, который контролирует атакующий. Затем форма заполняется данными, которые поступают из родительской страницы и затем форма отправляется.
Слайд 9

Варианты XSS взлома JavaScript может добавлять новые ресурсы - такие как

Варианты XSS взлома

JavaScript может добавлять новые ресурсы - такие как

теги - на текущую страницу. Можно вызвать изображение, находящееся на foo.com, для встраивания на bar.com. Не сложно вообразить сценарий, где злой код крадет полезную информацию и зашифровывает ее в ; например, тег может выглядеть так:
"/>
Слайд 10

Варианты XSS взлома злой код создает невидимый iframe, конструирует URL с

Варианты XSS взлома

злой код создает невидимый iframe, конструирует URL с параметрами

в запросе содержащие в себе информацию из родительской страницы и затем устанавливает iframe "src" в URL сервера, который находится под контролем атакующего.
Слайд 11

Варианты XSS взлома злой код создает тег с функциями, похожими на

Варианты XSS взлома

злой код создает