Ist Qooxdoo gegen XSS geschützt?

Question

Ich suche Informationen über Sicherheit auf Qooxdoo. Ich möchte meine app vs OWASP top 10 Ein Punkt zu überprüfen, ist die XSS zu überprüfen OWASP A3 XSS

Wie kann ich sicher sein, dass Qooxdoo gegen XSS-Angriffe sicher ist? Verwendet Qooxdoo einige Sanitizer-Tools?

GELÖST

Eine kurze Antwort von allen Diskussionen. Ja, Qooxdoo ist XSS-sicher. Standardmäßig wird kein JavaScript-Wert in einem Feld ausgeführt.

Aber, wenn Sie reich verwenden = true, müssen Sie Eingabe/Ausgabe

Answer 1

Ein gemeinsames XSS Angriffsvektor überprüfen sind Situationen, in denen ein Angreifer irgendwie eingibt JS-Code in einer Web-Anwendung, so dass dieser Code dann zeigt sich, im DOM einer Webseite und wird so aktiviert.

Um sich gegen diese Art von XSS zu schützen, müssen Sie sicherstellen, dass der Backend-Server nicht vom Benutzer generiertes (nicht bereinigtes) HTML an den Browser sendet ... (das hat nichts mit qooxdoo zu tun).

Das heißt, die regulären qooxdoo Widgets zeigen im Allgemeinen keine Daten als HTML an, so dass Sie auch ohne einen cleveren Server einigermaßen sicher sind. Die Ausnahme ist das qx.ui.basic.Label Widget und seine Nachkommen. Das Label-Widget kann HTML direkt anzeigen, wenn Sie die Eigenschaft rich festlegen. Die rich-Eigenschaft ist standardmäßig auf false festgelegt, aber wenn Sie sie aktivieren, müssen Sie sicherstellen, dass Sie keinen "gefährlichen" HTML-Inhalt anzeigen.

Nur sehr wenige (nicht wesentliche) qooxdoo-Widgets ermöglichen das Einfügen von HTML-Code in das DOM. In diesen Fällen müssen Sie darauf achten, die Daten zu bereinigen. Die Widgets in Frage sind:

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 

Wenn Sie qx.html.* und qx.bom.* und qx.dom.* Objekte verwenden Sie direkt mit dem DOM zu arbeiten, Sie sind außerhalb der Reichweite von qooxoo und darauf achten, entsprechend zu handeln.

Ein weiterer wichtiger Angriffsvektor sind Authentifizierungscookies. Bei den meisten Angriffen wird der Browser aufgefordert, eine Anforderung zusammen mit dem Cookie an seinen Server zu senden, ohne dass der Benutzer dies bemerkt.

Qooxdoo selbst tut nicht erfordern Sie Cookies überhaupt zu verwenden. Da qooxdoo-Anwendungen standardmäßig in einem einzigen Browserfenster ausgeführt werden, können Sie ohne die Verwendung von Cookies arbeiten. Eine einfache Möglichkeit, etwas wie diese zu implementieren, ist ein "Server-Access-Singleton", der die gesamte Kommunikation mit dem Backend übernimmt und das Zugriffstoken in einer speziellen Kopfzeile bereitstellt, die jeder Anfrage hinzugefügt wird.

Der folgende Code könnte als Richtlinie ... für das Cookie-Problem dienen.

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; 
     } 
    } 
}); 

und wenn Sie ein Login Popup-Fenster in myapp.uiLogin bieten könnten Sie die Standard callAsync durch die ersetzen Zugabe nach einem Login-Fenster Popup, wenn das Backend mit Ihrer Anfrage unglücklich ist.

/** 
* 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); 
}, 

einen Blick auf the CallBackery application zu sehen, wie diese in einer realen Anwendung funktioniert.