QooxdooはXSSから保護されています

Question

Qooxdooのセキュリティに関する情報を探しています。私がレビューしOWASP top 10 ポイント対私のアプリをチェックしたい はXSS OWASP A3 XSS

どのように私はQooxdooがXSS攻撃に対して安全であることを確認することができますか？ Qooxdooはいくつかのサニタイザツールを使用していますか？

は、すべての議論から

短い答えを解決しました。はいQooxdooはXSSに安全です。デフォルトでは、どのフィールドにもjavascript値は実行されません。

しかし、あなたは真=金持ち使用する場合は、入力/出力

Answer 1

共通XSS攻撃ベクトルは、このコードは、次に現れるように、攻撃者が何らかの方法でWebアプリケーションにJSコードを入力状況、ある確認する必要がありウェブページのDOM内に配置され、こうして活性化される。

この種類のXSSから保護するには、バックエンドサーバーがユーザーが生成した（クリーンでない）htmlをブラウザに送信しないようにする必要があります（これはqooxdooとは関係ありません）。

これは普通のqooxdooウィジェットでは一般的にデータをhtmlとして表示しないので、巧妙なサーバーがなくてもかなり安全です。例外はqx.ui.basic.Labelウィジェットとその子孫です。ラベルウィジェットには、richプロパティを設定した場合、HTMLを直接表示する機能があります。 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 

あなたが直接DOMで動作するようにqx.html.*とqx.bom.*とqx.dom.*オブジェクトを使用する場合、あなたはqooxooの範囲を超えているし、それに応じて行動する世話をする必要があります。

もう1つの重要な攻撃ベクトルは認証Cookieです。ほとんどの攻撃は、ブラウザがCookieとともにサーバーに要求を送信し、ユーザーがそれを認識することなく行われます。

Qooxdoo自体はではありません。では、Cookieをまったく使用する必要がありません。 qooxdooアプリケーションは1つのブラウザウィンドウで動作するため、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); 
}, 

the CallBackery applicationをご覧ください。これは実際のアプリケーションでどのように動作するかをご覧ください。