web-dev-qa-db-ja.com

localStorageからDOMにデータを直接レンダリングしても安全ですか？ XSS攻撃は可能ですか？

LocalstorageはXSS攻撃の影響を受けやすいと私は読んだ。

現在、JSON Web Token（JWT）をlocalstorageに保存しており、localstorageを介してユーザーに関するデータにアクセスして表示します。

_var localstore = // localStorage object

// On user login, server responds with token, store the token on client!
localstore.store(jwt_token);

// later, grab some data out of token
var name = localStore.getName();
_

そして、ある時点で、DOM上のユーザー情報を次のようにレンダリングします。

_<span> Welcome to your profile page! </span>
<span> How are you, {{ name }} </span>
_

だから基本的に：

  • ログイン時に、トークンをクライアントのlocalStorageに保存します
  • LocalStorageにアクセスしてDOMに直接レンダリングする

そのワークフローにはXSSベクトルが含まれていますか？これでいいですか？そうでなければ、私は他のアイデアを持っています：

（1）より良い解決策は：

  • ログイン時に、トークンをクライアントのlocalStorageに保存します
  • ユーザー情報を表示する必要があるときはいつでも、localStorageからトークンを取得し、それを使用してサーバーに直接ユーザー情報を問い合わせます

  • クライアントはユーザーデータを取得し、DOMでレンダリングします

    つまり、

    _// prepare jwt to be sent to server
http.setAuthenticationBearer(localstore.retrieveToken());

// Request user data with jwt! 
http.get('/profile').success( function(data) {
    var name = data['name'];
    // render 'name' in DOM
}
_

短所：ユーザーデータが必要になるたびにサーバーにリクエストを送信する必要があります。理想的ではありません。

（2）またはこれ：

  • ログイン時に、トークンをクライアントのlocalStorageに保存します

  • LocalStorageへのアクセス、データのサニタイザーへのパイプ、DOMへの直接レンダリング

    つまり、<span> How are you, {{ sanitize(name) }} </span>

PRO：オリジナルへの簡単な修正、クリーン、サーバーへのリクエストを行う必要がありません。

短所：データをsanitize()にパイプするときは、毎回覚えておく必要があります。忘れがちです。 （1）のように毎回リクエストを出すよりはましだと思います

xssjavascripthtmldomlocal-storage
7
rublex

エンコード/デコードとXSSサニテーションの事前保存およびpre domレンダリングを組み合わせることがベストプラクティスです。

ブラウザDOM XSS攻撃に関する緩和策はさまざまですが、ここにあるヘッダーオプション（ https://www.owasp.org/index.php/List_of_useful_HTTP_headers ）で強化できます。

ゼロデイの脆弱性がさまざまなブラウザレンダリングエンジンに存在する可能性がありますが、これらはXSS攻撃ベクトルの主な原因である同じOrigin制限の未知の欠陥を防ぐのに役立ちます。

セキュリティは、大部分の攻撃を防止するのに十分なフープを作成しています。異常を監視し、システムとコードベースにパッチを適用し続けるのが残りです。

1
jas-