HTML 5--webストレージ学習ノート
5096 ワード
HTML 5--webストレージ学習ノート
HTML 5は、クライアントにデータを格納する2つの新しい方法を提供します.
localStorage-時間制限のないデータストレージsessionStorage-1つのsessionに対するデータストア(ブラウザのクローズに伴ってロックされたデータを消去)以前は、これらはクッキーで完成していました.localStorage対応前の永続化クッキー、sessionStorage対応前の返信クッキー;
cookieは大量のデータのストレージに適していない(cookieは最大4 KBで、一般的なブラウザはwebストレージのサイズを実現するのは基本的に5 MBである).
クッキーは、ユーザの要求とともにサーバに送信されるため、クッキーの速度が遅く、効率も高くありません.
≪独立したストレージ領域|Independent Storage Space|emdw≫:各ドメイン(サブドメインを含む)には独立したストレージ領域があり、各ストレージ領域は完全に独立しているため、データの混乱は発生しません.
HTML 5では、データはサーバリクエストごとに渡されるのではなく、リクエスト時にのみデータが使用される.Webサイトのパフォーマンスに影響を及ぼさずに大量のデータを格納できるようにします.
異なるWebサイトの場合、データは異なる領域に格納され、1つのWebサイトは独自のデータにしかアクセスできません.
HTML 5は、JavaScriptを使用してデータを格納およびアクセスします.
一:localStorage使用例:
ストレージデータ:window.localStorage.setItem(key,value);
取得データ:window.localStorage.getItem(key);
削除データ:window.localStorage.removeItem(key);
二:sessionStorage使用例:
HTML 5ストレージはCookieストレージの代わりに使えますか?
以下の内容は、ネット上のブログから来ています.
テキストリンク:http://sec.chinabyte.com/98/12292098.shtml
(1)、Cookieブラウザの代わりにCookieを使って認証できるかどうかは何年も経っていますが、localStorageのストレージスペースがそんなに大きい以上、認証データを直接移植することができますか.今のところ、認証データをlocalStorageで格納するのは未熟です.通常、XSS脆弱性を使用してCookieを取得し、このCookieで認証ログインすることができることを知っています.その後、XSSによるCookieデータの取得を防止するため、ブラウザはHTTPONLYを使用してCookieをXSS攻撃から保護することをサポートした.一方、localStorageストレージにはXSS攻撃に対する抵抗メカニズムはありません.XSSの脆弱性が発生すると、localStorageに格納されているデータが入手しやすくなります.あるサイトにXSSの脆弱性がある場合、攻撃者は次のコードを注入し、localStorageを使用してローカルに格納されているすべての情報を取得することができます. #div_code img{border:0px;} 攻撃者も簡単にlocalStorageを使うことができます.removeItem(key)とlocalStorage.clear()は、格納データを空にします.(2)、機密情報を記憶しない(1)から分かるように、リモート攻撃から見るとlocalStorageに格納されているデータはXSS攻撃で入手しやすいため、認証情報や機密情報をlocalStorageで格納することは望ましくない.ローカル攻撃の観点からは、localStorage自体の記憶方式や記憶時効からも機密情報を記憶するべきではない.5つのブラウザでは、Chrome、Opera、Safariの3つのブラウザにローカルストレージを表示する機能モジュールがサポートされています.しかし、ブラウザによってlocalStorageの格納方法は少し異なります.以下は5つのブラウザlocalStorageの格納方法です.上記の説明から分かるように、OperaブラウザはBASE 64暗号化を採用しているほか(BASE 64も簡単に復号化できる)、他のブラウザは明文でデータを格納していることがわかります.一方、データ格納の時効上、localStorageはCookieのようにデータの生存時間を設定することはできず、ユーザーが自発的に削除しない限り、localStorageに格納されたデータは永続的に存在する.以上の記憶方式と記憶時効の解析から,これらの情報が暗号化されすぎないようにlocalStorage方式で機密情報を記憶しないことを提案した.(3)、入出力を厳格にフィルタリングしてローカルストレージに対して、データの再ロードを容易にするために、データをローカルに格納することが多い.これをロードすると、そのままローカルからデータを読み込んでWebページに表示されます.場合によっては、localStorageストレージにデータを書き込んだり読み込んだりする際に、データが入出力によって厳密にフィルタリングされていない場合、これらのデータがHTMLコードとして解析され、XSS攻撃が発生する可能性が高い.TwitterではlocalStorage XSSの脆弱性が発生しました.サブホールがトリガーされる条件は、Twitterの個人用ページで以下のストレージコードを実行すると、個人用ページを開くたびに/xss/ボックスがポップアップすることです. #div_code img{border:0px;} localStorage.setItem(":USER:",'{"name":{"value":{"store":{"recentFollowers":{"value":"name "}}}}}'); このコードから分かるように、TwitterはlocalStorageメソッドを使用して一部の個人データをローカルに格納し、個人のホームページをロードするたびにローカルからデータを格納し、Twitterがデータ除去の厳格なフィルタリングを無視したため、格納されたコードはHMTL符号化として実行され、クロスステーション攻撃が発生する.Twitter localStorage XSS脆弱性の詳細は次のとおりです.http://www.wooyun.org/bugs/wooyun-2010-03075.Twitterという脆弱性を利用するのは難しいが、すべての入出力が有害であるという原則に基づいて、データを厳格に入出力フィルタリングすることを改めて教えてくれた.(4)、ディレクトリ間攻撃を受けやすいlocalStroage格納方式はCookie格納のようにドメイン内のパスを指定することはできず、localStroage格納方式にはドメインパスの概念はない.すなわち,1つのドメインの下の任意の経路にXSSホールが存在する場合,ドメイン全体に格納されたデータは,格納名が分かっている場合に取得できる.次の2つのリンクはlocalStorageを使用してデータを格納すると仮定します.ユーザーxisigrとxhackのそれぞれのblogリンクは同じドメインに属していますが、xisigrとxhackの別のパスがあります.xisigrユーザーが自分のパスの下にストレージ型XSSの脆弱性があることを発見したと仮定すると、コアコードがlocalStorageである自分のblogに取得データコードを加えることができる.getItem(“name”).xhackユーザーはblogにログインする必要はありません.彼はアクセスするだけです.http://h.example.com/xisigrを選択すると、ローカルストレージデータが取得されます.(5)、DNS欺瞞攻撃に遭いやすいGoogleはHTML 5ローカルストレージを使用しない前にGoogle Gears方式でローカルストレージを行い、その時Google GearsはDNS欺瞞攻撃を受けたことがある.Google Gearsはオフラインストレージをサポートしており、Gmail、WordPresssのようなサイトデータをSQLiteデータベースとして保存することができ、後でユーザーは保存したサイトデータをオフラインで読み取るか削除することができます.攻撃者がDNS詐欺攻撃を発動すれば、ローカルデータベースに注入したり、データを取得したり、永続的なバックドアを残したりすることができます.これにより、ユーザーに永続的な危害を及ぼすことになります.Google Gearsが受けたDNS詐欺攻撃方式は、HTML 5のローカルストレージでも同様に有効です.(6)、悪意のあるコードが生息する温床は6点目に「悪意のあるコードが生息する温床」という小さな見出しが誇張された効果を与える.実はここで言いたいのは、HTML 5のローカルストレージが空間的にも時間的にも今後のストレージと呼ばれる傾向であり、「悪意のあるコードたち」が自然に雁南飛に移ってこの温床に生息することを予想しているということです.では、HTML 5のローカルストレージの空間と時間とは何でしょうか.スペースここではストレージスペースを指し、Cookie 4 Kスペースの微小さよりもHTML 5のlocalStroageメソッドではデフォルトでブラウザに5 Mスペースを格納できるのが博大といえますが、Safariブラウザは500 MまでサポートできるのでHTML 5ストレージの覇気が露呈します.時間的には、HTML 5の技術が成熟するにつれて、各ブラウザメーカーが自分の製品の中でHTML 5をサポートしているほか、一部の大手アプリケーションメーカーも信頼している.例えば2011年11月にAdobeが携帯電話のFLASHを放棄すると発表し、HTML 5が全面的に取って代わった.時間が経つにつれて、HTML 5の大きなステップが進む速度もますます速くなり、HTML 5のローカルストレージに使用されるアプリケーションもますます多くなります.「悪意のあるコードが生息する温床」の可能性を理論的に解析した.実際の技術的な実現可能性も非常に簡単です.次は、ローカルにバックドアを残すコアコードです.shellcode function setShellCodz(codz){window.localStorage.setItem("shellcodz",codz);}原文は【ビットネット】から出て、転載は原文のリンクを保留してください:http://sec.chinabyte.com/98/12292098.shtml
HTML 5は、クライアントにデータを格納する2つの新しい方法を提供します.
localStorage-時間制限のないデータストレージsessionStorage-1つのsessionに対するデータストア(ブラウザのクローズに伴ってロックされたデータを消去)以前は、これらはクッキーで完成していました.localStorage対応前の永続化クッキー、sessionStorage対応前の返信クッキー;
cookieは大量のデータのストレージに適していない(cookieは最大4 KBで、一般的なブラウザはwebストレージのサイズを実現するのは基本的に5 MBである).
クッキーは、ユーザの要求とともにサーバに送信されるため、クッキーの速度が遅く、効率も高くありません.
≪独立したストレージ領域|Independent Storage Space|emdw≫:各ドメイン(サブドメインを含む)には独立したストレージ領域があり、各ストレージ領域は完全に独立しているため、データの混乱は発生しません.
HTML 5では、データはサーバリクエストごとに渡されるのではなく、リクエスト時にのみデータが使用される.Webサイトのパフォーマンスに影響を及ぼさずに大量のデータを格納できるようにします.
異なるWebサイトの場合、データは異なる領域に格納され、1つのWebサイトは独自のデータにしかアクセスできません.
HTML 5は、JavaScriptを使用してデータを格納およびアクセスします.
一:localStorage使用例:
ストレージデータ:window.localStorage.setItem(key,value);
取得データ:window.localStorage.getItem(key);
削除データ:window.localStorage.removeItem(key);
<script type="text/javascript">
localStorage.lastname="Smith";
document.write(localStorage.lastname);
</script>二:sessionStorage使用例:
<script type="text/javascript">
sessionStorage.lastname="Smith";
document.write(sessionStorage.lastname);
</script>HTML 5ストレージはCookieストレージの代わりに使えますか?
以下の内容は、ネット上のブログから来ています.
テキストリンク:http://sec.chinabyte.com/98/12292098.shtml
(1)、Cookieブラウザの代わりにCookieを使って認証できるかどうかは何年も経っていますが、localStorageのストレージスペースがそんなに大きい以上、認証データを直接移植することができますか.今のところ、認証データをlocalStorageで格納するのは未熟です.通常、XSS脆弱性を使用してCookieを取得し、このCookieで認証ログインすることができることを知っています.その後、XSSによるCookieデータの取得を防止するため、ブラウザはHTTPONLYを使用してCookieをXSS攻撃から保護することをサポートした.一方、localStorageストレージにはXSS攻撃に対する抵抗メカニズムはありません.XSSの脆弱性が発生すると、localStorageに格納されているデータが入手しやすくなります.あるサイトにXSSの脆弱性がある場合、攻撃者は次のコードを注入し、localStorageを使用してローカルに格納されているすべての情報を取得することができます. #div_code img{border:0px;} 攻撃者も簡単にlocalStorageを使うことができます.removeItem(key)とlocalStorage.clear()は、格納データを空にします.(2)、機密情報を記憶しない(1)から分かるように、リモート攻撃から見るとlocalStorageに格納されているデータはXSS攻撃で入手しやすいため、認証情報や機密情報をlocalStorageで格納することは望ましくない.ローカル攻撃の観点からは、localStorage自体の記憶方式や記憶時効からも機密情報を記憶するべきではない.5つのブラウザでは、Chrome、Opera、Safariの3つのブラウザにローカルストレージを表示する機能モジュールがサポートされています.しかし、ブラウザによってlocalStorageの格納方法は少し異なります.以下は5つのブラウザlocalStorageの格納方法です.上記の説明から分かるように、OperaブラウザはBASE 64暗号化を採用しているほか(BASE 64も簡単に復号化できる)、他のブラウザは明文でデータを格納していることがわかります.一方、データ格納の時効上、localStorageはCookieのようにデータの生存時間を設定することはできず、ユーザーが自発的に削除しない限り、localStorageに格納されたデータは永続的に存在する.以上の記憶方式と記憶時効の解析から,これらの情報が暗号化されすぎないようにlocalStorage方式で機密情報を記憶しないことを提案した.(3)、入出力を厳格にフィルタリングしてローカルストレージに対して、データの再ロードを容易にするために、データをローカルに格納することが多い.これをロードすると、そのままローカルからデータを読み込んでWebページに表示されます.場合によっては、localStorageストレージにデータを書き込んだり読み込んだりする際に、データが入出力によって厳密にフィルタリングされていない場合、これらのデータがHTMLコードとして解析され、XSS攻撃が発生する可能性が高い.TwitterではlocalStorage XSSの脆弱性が発生しました.サブホールがトリガーされる条件は、Twitterの個人用ページで以下のストレージコードを実行すると、個人用ページを開くたびに/xss/ボックスがポップアップすることです. #div_code img{border:0px;} localStorage.setItem(":USER:",'{"name":{"value":{"store":{"recentFollowers":{"value":"name "}}}}}'); このコードから分かるように、TwitterはlocalStorageメソッドを使用して一部の個人データをローカルに格納し、個人のホームページをロードするたびにローカルからデータを格納し、Twitterがデータ除去の厳格なフィルタリングを無視したため、格納されたコードはHMTL符号化として実行され、クロスステーション攻撃が発生する.Twitter localStorage XSS脆弱性の詳細は次のとおりです.http://www.wooyun.org/bugs/wooyun-2010-03075.Twitterという脆弱性を利用するのは難しいが、すべての入出力が有害であるという原則に基づいて、データを厳格に入出力フィルタリングすることを改めて教えてくれた.(4)、ディレクトリ間攻撃を受けやすいlocalStroage格納方式はCookie格納のようにドメイン内のパスを指定することはできず、localStroage格納方式にはドメインパスの概念はない.すなわち,1つのドメインの下の任意の経路にXSSホールが存在する場合,ドメイン全体に格納されたデータは,格納名が分かっている場合に取得できる.次の2つのリンクはlocalStorageを使用してデータを格納すると仮定します.ユーザーxisigrとxhackのそれぞれのblogリンクは同じドメインに属していますが、xisigrとxhackの別のパスがあります.xisigrユーザーが自分のパスの下にストレージ型XSSの脆弱性があることを発見したと仮定すると、コアコードがlocalStorageである自分のblogに取得データコードを加えることができる.getItem(“name”).xhackユーザーはblogにログインする必要はありません.彼はアクセスするだけです.http://h.example.com/xisigrを選択すると、ローカルストレージデータが取得されます.(5)、DNS欺瞞攻撃に遭いやすいGoogleはHTML 5ローカルストレージを使用しない前にGoogle Gears方式でローカルストレージを行い、その時Google GearsはDNS欺瞞攻撃を受けたことがある.Google Gearsはオフラインストレージをサポートしており、Gmail、WordPresssのようなサイトデータをSQLiteデータベースとして保存することができ、後でユーザーは保存したサイトデータをオフラインで読み取るか削除することができます.攻撃者がDNS詐欺攻撃を発動すれば、ローカルデータベースに注入したり、データを取得したり、永続的なバックドアを残したりすることができます.これにより、ユーザーに永続的な危害を及ぼすことになります.Google Gearsが受けたDNS詐欺攻撃方式は、HTML 5のローカルストレージでも同様に有効です.(6)、悪意のあるコードが生息する温床は6点目に「悪意のあるコードが生息する温床」という小さな見出しが誇張された効果を与える.実はここで言いたいのは、HTML 5のローカルストレージが空間的にも時間的にも今後のストレージと呼ばれる傾向であり、「悪意のあるコードたち」が自然に雁南飛に移ってこの温床に生息することを予想しているということです.では、HTML 5のローカルストレージの空間と時間とは何でしょうか.スペースここではストレージスペースを指し、Cookie 4 Kスペースの微小さよりもHTML 5のlocalStroageメソッドではデフォルトでブラウザに5 Mスペースを格納できるのが博大といえますが、Safariブラウザは500 MまでサポートできるのでHTML 5ストレージの覇気が露呈します.時間的には、HTML 5の技術が成熟するにつれて、各ブラウザメーカーが自分の製品の中でHTML 5をサポートしているほか、一部の大手アプリケーションメーカーも信頼している.例えば2011年11月にAdobeが携帯電話のFLASHを放棄すると発表し、HTML 5が全面的に取って代わった.時間が経つにつれて、HTML 5の大きなステップが進む速度もますます速くなり、HTML 5のローカルストレージに使用されるアプリケーションもますます多くなります.「悪意のあるコードが生息する温床」の可能性を理論的に解析した.実際の技術的な実現可能性も非常に簡単です.次は、ローカルにバックドアを残すコアコードです.shellcode function setShellCodz(codz){window.localStorage.setItem("shellcodz",codz);}原文は【ビットネット】から出て、転載は原文のリンクを保留してください:http://sec.chinabyte.com/98/12292098.shtml