Защищен ли Qooxdoo от XSS

Я ищу информацию о безопасности на Qooxdoo. Я хочу сравнить свое приложение с 10 лучших OWASP Стоит рассмотреть XSS OWASP A3 XSS

Как я могу быть уверен, что Qooxdoo защищен от XSS-атак? Qooxdoo использует какие-нибудь дезинфицирующие средства?

РЕШЕНО

Короткий ответ из всех обсуждений. Да, Qooxdoo безопасен для XSS. По умолчанию значение javascript в любом поле не выполняется.

Но, если вы используете rich = true, вам нужно проверить ввод / вывод


person Benoît VALLETTE d'OSIA    schedule 13.06.2016    source источник
comment
Есть ли какие-то конкретные области OWASP, которые, по вашему мнению, применимы? OWASP, по-видимому, имеет отношение к безопасности сервера, а не клиента, т.е. если клиент скомпрометирован, вопрос заключается в том, может ли сервер защитить себя.   -  person johnspackman    schedule 14.06.2016
comment
Вы правы, я хочу проверить свою заявку на соответствие OWASP. Я использую Jspresso и docker, поэтому могу проверить все точки OWASP. Но для XSS клиент должен быть проверен, в моем случае Qooxdoo, поэтому я задал свой вопрос только для Qooxdoo   -  person Benoît VALLETTE d'OSIA    schedule 14.06.2016


Ответы (1)


Распространенным вектором атаки XSS являются ситуации, когда злоумышленник каким-то образом вводит код JS в веб-приложение, так что этот код затем появляется в DOM веб-страницы и, таким образом, активируется.

Для защиты от такого типа XSS вы должны убедиться, что внутренний сервер не отправляет созданный пользователем (неочищенный) HTML-код в браузер ... (это не имеет ничего общего с qooxdoo).

Тем не менее, обычные виджеты qooxdoo обычно не отображают данные в виде html, поэтому вы в достаточной степени в безопасности даже без умного сервера. Исключение составляет виджет qx.ui.basic.Label и его потомки. Виджет Label может отображать HTML напрямую, если вы установите свойство rich. Для свойства rich по умолчанию установлено значение false, но если вы включите его, вы должны убедиться, что не отображаете «опасный» HTML-контент.

Лишь очень немногие (несущественные) виджеты qooxdoo позволяют вставлять HTML-код в DOM. В этом случае вы должны позаботиться о дезинфекции данных. Речь идет о виджетах:

qx.ui.embed.Html
qx.ui.table.cellrenderer.Html
qx.ui.progressive.renderer.table.cell.Html
qx.ui.virtual.cell.Html
qx.ui.virtual.layer.HtmlCell
qx.ui.virtual.layer.HtmlCellSpan

Если вы действительно используете объекты qx.html.*, qx.bom.* и qx.dom.* для работы с DOM напрямую, вы находитесь вне досягаемости qooxoo и должны действовать соответствующим образом.

Еще один важный вектор атаки - файлы cookie аутентификации. Большинство атак работают, заставляя браузер отправлять запрос вместе с файлом cookie на свой сервер без ведома пользователя.

Сам Qooxdoo не вообще требует от вас использования файлов cookie. Поскольку приложения qooxdoo изначально запускаются в одном окне браузера, вы можете работать без файлов cookie. Простой способ реализовать что-то вроде этого - иметь «синглтон доступа к серверу», который заботится обо всех коммуникациях с серверной частью и предоставляет токен доступа в специальном заголовке, добавляемом к каждому запросу.

Приведенный ниже код может служить руководством ... для проблемы с файлами cookie.

qx.Class.define('myapp.Server', {
    extend : qx.io.remote.Rpc,
    type : "singleton",

    construct : function() {
        this.base(arguments);
        this.set({
            timeout     : 60000,
            url         : 'QX-JSON-RPC/',
            serviceName : 'default'
        });
    },

    properties: {
        sessionCookie: {
            init: null,
            nullable: true
        }
    },

    members : {
        /**
         * override the request creation, to add our 'cookie' header
         */
        createRequest: function() {
            var req = this.base(arguments);
            var cookie = this.getSessionCookie();
            if (cookie){
                req.setRequestHeader('X-Session-Cookie',this.getSessionCookie());
            }
            return req;
        }
    }
});

и если вы предоставите всплывающее окно входа в систему в myapp.uiLogin, вы можете заменить стандартный callAsync, добавив следующее, чтобы всплывающее окно входа в систему, если серверная часть недовольна вашим запросом.

 /**
 * A asyncCall handler which tries to
 * login in the case of a permission exception.
 *
 * @param handler {Function} the callback function.
 * @param methodName {String} the name of the method to call.
 * @return {var} the method call reference.
 */
callAsync : function(handler, methodName) {
    var origArguments = arguments;
    var origThis = this;
    var origHandler = handler;
    var that = this;
    var superHandler = function(ret, exc, id) {
        if (exc && exc.code == 6) {
            var login = myapp.uiLogin.getInstance();

            login.addListenerOnce('login', function(e) {
                var ret = e.getData();
                that.setSessionCookie(ret.sessionCookie);
                origArguments.callee.base.apply(origThis, origArguments);
            });

            login.open();
            return;
        }

        origHandler(ret, exc, id);
    };

    if (methodName != 'login') {
        arguments[0] = superHandler;
    }

    arguments.callee.base.apply(this, arguments);
},

взгляните на приложение CallBackery, чтобы увидеть, как это работает в реальном приложении.

person Tobi Oetiker    schedule 14.06.2016
comment
Я не уверен, что понимаю, почему это ответ о невосприимчивости Qooxdoo к XSS. - person Benoît VALLETTE d'OSIA; 14.06.2016
comment
от какого типа xss-атаки вы хотите защитить себя конкретно ...? Многие используют файлы cookie каким-либо образом, поэтому, написав приложение, которое не использует файлы cookie, вы можете очень легко обойти их целую кучу ... - person Tobi Oetiker; 14.06.2016
comment
И многие вообще не используют файлы cookie. Даже те, которые действительно включают файлы cookie, лучше смягчаются стандартной защитой от XSS. Я даже не уверен, от какой XSS-уязвимости должен защищаться этот ответ. (Или как это могло бы смягчить его, вы просто заменяете одну форму ввода другой формой ввода, но не меняете то, что она вводит вообще) - person Quentin; 14.06.2016
comment
Как я уже сказал, НЕ используя файлы cookie, вы можете избежать целого класса атак ... из-за архитектуры qx это действительно просто ... Если вы имеете в виду другой класс xss-атак, пожалуйста, будьте конкретны, поэтому мы можно обсудить в менее общих чертах. - person Tobi Oetiker; 14.06.2016
comment
Я думаю, что вопрос конкретно нацелен на клиентский XSS (возможность внедрять действительный javascript в DOM с помощью стандартных виджетов qooxdoo), и если qooxdoo специально имеет дело с этим. См. owasp.org/index.php/ - person Vincent Vandenschrick; 15.06.2016
comment
Я осмелюсь предположить, что большинство векторов клиентских xss-атак проистекает из того факта, что люди работают с DOM. Qooxoo в основном так не работает. Пользователь не взаимодействует с домом напрямую ... он использует исключительно api qooxoo ... а qooxoo контролирует все дерево доменов. - person Tobi Oetiker; 15.06.2016
comment
Можно ли сказать, что пользователь, отображающий значение, записанное другим пользователем, не может выполнить какой-либо код javascript из значения поля? - person Benoît VALLETTE d'OSIA; 16.06.2016
comment
Насколько я понимаю, это полностью зависит от кода приложения. Если он использует метку rich=true (которая не является значением по умолчанию) для отображения значения, введенного злоумышленником, и серверная часть не выполняет никакой фильтрации, тогда да, код javascript будет выполнять. Ответственность за то, чтобы введенные строки были удалены от любого вредоносного кода, прежде чем присвоить им метку rich qooxdoo, лежит на разработчике (или используемой им структуре). Начиная с 4.3, Jspresso будет выполнять систематическую фильтрацию входящих значений с помощью библиотеки OWASP java-html-sanitizer. - person Vincent Vandenschrick; 16.06.2016