Распространенным вектором атаки 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