タイトルが不穏ですが調査やサポートに連絡した結果「通常使用は問題ない」との結論になりましたので先に言っておきます。じゃあなぜ記事にしたかというと「WEBサイト作るときに超困る」からです。 追記：以下の検証等は（2015年11月バージョンの）カスペルスキー2016 Windows版です。 一体何が起きているのか カスペルスキー 2016および2015の話です。2016はつい最近パッケージ版が発売されましたね。このカスペルスキー2016 Windows版 をインストールすると、アクセスする（ほぼ全ての）WEBサイトに**「カスペルスキー謹製 javascriptコード」**が挿入されます。 これはカスペルスキーと全く関係ないMicrosoftのWEBサイト(https://www.microsoft.com/ja-jp)を表示した時のhtmlソースです。 見辛くてすいません。microsoft
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
YouTubeの脆弱性が悪用され、ショッキングなデマが流れたり、コメントが表示されなくなるなどの影響が広がった。 動画共有サイトの米YouTubeを狙った攻撃が発生し、ショッキングなデマが流れたり、コメントが表示されなくなるなどの影響が広がった。7月4日から5日にかけて、米セキュリティ機関のSANS Internet Storm Centerや英Sophosなどが伝えた。 それによると、この攻撃ではYouTubeのコメントシステムに存在するクロスサイトスクリプティング（XSS）の脆弱性が悪用された。この影響でコメントが表示されなくなったり、画面に「ニュース速報：（歌手の）ジャスティン・ビーバーが交通事故で死亡」というデマがポップアップ表示されるなどの被害が広がった。ほかにも不正なポップアップが出たり、悪趣味なWebサイトにリダイレクトされたりするケースが相次いだという。 Googleは攻撃
html5securityのサイトに、XSSの各種攻撃手法がまとめられているのを発見せり!ということで、個人的に「お!」と思った攻撃をサンプルつきでご紹介します。 1. CSS Expression IE7以前には「CSS Expressions」という拡張機能があり、CSS内でJavaScriptを実行できたりします。 <div style="color:expression(alert('XSS'));">a</div> 確認 @IT -［柔軟すぎる］IEのCSS解釈で起こるXSS で詳しく解説されていますが、CSSの解釈が柔軟なことともあいまって自前で無害化するのはなかなか困難。以下のようなコードでもスクリプトが実行されてしまいます。 <div style="color:expr/* コメントの挿入 */ession(alert('XSS'));">a</div> 確認 <div s
Google CajaはJava/JavaScript製のオープンソース・ソフトウェア。OpenSocialやFacebookアプリ、iGoogle Widgetなど、サードパーティ製のWebガジェットを実行するプラットフォームが増えている。サービスをプラットフォームとして活用することで新たな価値を提供できる反面、セキュリティへの懸念がある。 リダイレクトチェック Webブラウザ上で実行するということはJavaScriptが実行できないといけない。だが何でもできてしまっては困る。セキュリティを担保しつつ、開発者の自由度を確保するというのは非常に難しい。そこで利用を考えたいのがGoogle Cajaだ。 Google Cajaは安全なDHTML埋め込みを実現するためのソフトウェアで、Googleの開発者によって開発されている。安全な埋め込みとはすなわち危険なコードを取り除きつつ、Web上で実
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） 次は、JSONにおけるセキュリティ対策 皆さんこんにちは、はせがわようすけです。第4回「［気になる］JSONPの守り方」はJSONPについて説明しましたので、今回は「JSON」についてもセキュリティ上注意すべき点について説明します。 JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。 まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。 ［サーバ側］ HTTP/1.1 200 OK Content-Type: application/json; charset=
会員限定サービスです 今なら年額プランで最大9,080円お得 お申し込み 会員の方はこちら ログイン 日経クロステック TOPページ
■ 「NoScript」をやめて「RequestPolicy」にした セキュリティ屋が、Firefoxユーザに「NoScript」の使用を推奨することがしばしばあるが、私は賛同しない。 JPCERT/CC、技術メモ「安全なWebブラウザの使い方」を公開, INTERNET Watch, 2008年11月4日 *1 技術メモ − 安全なWebブラウザの使い方, JPCERT/CC, 2008年11月4日 IV. 各 Web ブラウザに共通する設定上の注意事項 1. スクリプト等の実行を制限する JavaScript 等のスクリプトや（略）は（略）Ajax に代表されるインタラクティブなインターフェースが実現できるなど、高い利便性が得られます。反面、PC 上の重要なファイルを削除・変更するなど、悪意を持った処理が行われる可能性もあります。従って無制限にスクリプト等を実行できるようにしておくのは
汎用的なものではないが、技術的には非常に興味深い代物だ。Webサイトではロボットによるクローリングを防止するためにCAPTCHAと呼ばれる仕組みを導入していることがよくある。ぐにゃぐにゃな文字で、人であれば読めるがコンピュータには読めないであろう文字を表示して人かロボットかを判別するのだ。 上に表示されている画像を解析して文字として表示するデモ だがただ文字を画像化したくらいではOCRのような仕組みを使って読まれる可能性がある。それを示したのがMegaupload auto-fill captchaだ。 今回紹介するフリーウェアはMegaupload auto-fill captcha、MegauploadのCAPTCHAを破るGreasemonkeyだ。ソースコードは開示されているがライセンスは明記されていなかったのでご注意いただきたい。 Megaupload auto-fill cap
F-Secure「JavaScript Injection Attack」より September 18，2008 Posted by Choon Hong このところJavaScriptインジェクション攻撃が流行している。マルウエア感染を広める有効な手段として，この種の攻撃を活用するマルウエア作者が増えている。 ほんの1年前まで，悪意ある攻撃者が頼りにしていたのは攻撃用Webサイトを指す（電子メール，検索リンク，またはインスタント・メッセージング・ワームの）リンクに人々を誘導する手法だった。今では，JavaScriptインジェクション攻撃を利用し，Webサイトの訪問者をやすやすと「誘拐」してしまう。この攻撃は，いわば闇世界のハッカーたちがマルウエアをまん延させるのに使うアーミーナイフである。 我々が確認したところ，アクセス数の多いWebサイトの多くがJavaScriptインジェクション攻
最近，ある企業のシステム管理者から「Webページを不正に改ざんされる事件が最近特に増加し，その改ざんされたサイトをWebブラウザで閲覧した場合，ウイルスを送り込まれることが多いと聞く。Webブラウザを使用する時に，利用者側で行うべき対策をアドバイスしてほしい」との相談を受けました。 確かに，3月に入ってから国内の数多くのWebサイトが改ざんの被害にあっています（関連記事）。痛ましいのは，被害者であるはずのWebサイトが不正な改ざんにより，一般の閲覧者への加害者に仕立てられることです。Webサイトの管理者は，当然ながら今回の攻撃で主な手口として使用されたSQLインジェクション対策などの不正アクセスに耐えうる対策を施すべきです。しかし，このように多数のWebサイトが改ざんされる状況になった現在では，インターネットを利用する側も，これまで以上に充分な対策を行う必要があります。 第1回目のコラムで
iframe に関するセキュリティ上の制限 常識かもしれないが、とりあえずメモ。 次のような HTML を考えてみる。 <html> <body> <iframe src="http://www.softculture.com/" id="iframe1"></iframe> </body> </html> これをファイルとして保存して、それを FireFox 2.0 で直接読み込む。（つまりローカルで実行) Firebugs のコンソールで次の Javascript のコードを実行すると、 document.getElementById("iframe1").contentWindow.document.body "Permission denied to get property HTMLDocument.body" と言われてエラーになる。 別のサイトを読み込む iframe の中身
追記：早速破られた！ safeCall("var w=(function(){return this;}).call();w.alert(w.document.cookie);"); id:kazuhooku - http://b.hatena.ne.jp/kazuhooku/20071206#bookmark-6709542 サイ本よく見ると確かに「オブジェクトのメソッドとして呼び出された関数内でも、入れ子にされた関数内のthisはグローバルオブジェクトを参照します」て書いてあった。あとMDCにも http://developer.mozilla.org/ja/docs/Core_JavaScript_1.5_Reference:Operators:Special_Operators:this_Operator ========= 面白い記事があった、Greasemonkeyのunsaf
XSS対策:JavaScriptのエスケープ(その3) - ockeghem(徳丸浩)の日記にて、JavaScriptのリテラルを動的生成する場合のエスケープ方法について検討したが、id:hoshikuzuさんから、考慮がもれているという指摘を受けた(http://d.hatena.ne.jp/hoshikuzu/20071011#p1:TITLE=2007-10-11 - hoshikuzu | star_dust の書斎 - JavaScriptエスケープについて論考)。 上記は長いエントリーではあるが、要約すると、特定文字エンコードの特定のバイト●に対して、特定ブラウザにおいて「●\」が一文字「■」として解釈されるため、「"」に対するエスケープ「\"」が破綻するという意味に解釈した。 興味深い内容であるので、以下に考察してみよう。 なぜエスケープが破綻するのか 上記のようなケースはさ
大垣さんのブログから 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。 <script> 123[''+<_>ev</_>+<_>al</_>](''+<_>aler</_>+<_>t</_>+<_>(1)</_>); </script> このスクリプトの中には、興味深い要素がたくさん含まれていますが、説明もなく放り出されているので理解が難しいでしょうね。 E4Xについて まず目につくのは、JavaScript(ECMAScript)のスクリプト中にXML形式でオブジェクト・リテラルを記述できるE4X(ECMAScript for XML)という機能です(FireFox1.5以降で対応)。これは、例えば以下のように使います。 var order = <order> <name>Webアプリケーションのセキュリティ完全対策</name>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
