もばいる全盛感のある世間的には今更,FLASH なんてどうでもいいし,swfobject.js 自体 2009年から更新されてないから,こんな古いものをと言われかねないような話ではあるものの,日本語での言及をあまり見てないし,つい先日もさる通信キャリアがトップページでやらかしてて多分知られてないんだろうなと思ったので書こうと思った次第. swfobject.js とは何か この記事の対象読者にとっては説明するまでもない話とはおもうけど一応前置きとして説明しておくと,swfobject.js は FLASH を web ページに埋め込むための JavaScript のライブラリ.クロスブラウザ対応してたり,面倒な HTML-tag のお作法を覚えなくても良くなったりとでデファクトスタンダードな感じのモノ.2007年とちょい古いがリクルートMTL の SWFObject v2.0 ドキュメント
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Evernoteに任意のHTMLを注入できる脆弱性がありました。 http://togetter.com/li/125281 Evernoteのセキュリティポリシーとかには触れず、とりあえず何が可能だったのか、どういう状況だったのかを書きます。 4/18 16時ごろ Evernoteの登録ページのHTMLに以下のような記述があります。 <script type="text/javascript"> $(document).ready(function() { suggestedTags = []; suggestedNotebook = ""; sourceUrl = ""; providerName = ""; payload = { "user" : { ... }, ..後略.. </script> このsourceUrl = ""の部分、https://www.evernote.c
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2010年9月21日に twitter で起きた XSS脆弱性攻撃の個人的な観測記録です。 twitterの現状 対応・修正済み。 Twitter Status - XSS attack identified and patched. Twitterのステータス - XSSアタックについて認識し、パッチによる修復作業を行いました。 Twitter / Del Harvey: The XSS attack should now ... Twitter / Yoshimasa Niwa: 修正作業を行い、先程のXSS問題は修正されました。多 ... この問題は何か スクリプト挿入脆弱性 Script Insertion Vulnerability XSS脆弱性 Cross-Site Scripting Vulnerability どんなバグか URLで、/(slash)に挟まれた@(atmar
NTTドコモとソフトバンクモバイルは、フィーチャーフォン(いわゆるガラケー)にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている(しようとしている)挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。 NTTドコモに学ぶ「XSS対策」まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。 <?php session_start(); ?> <body> こんにちは<?php echo $_GET['p']; ?>さん </body>これを以下のURLで起動すると、IE7では下図のような表示になります。 []http://example.com/xss01.php?p=山田<scrip
OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。 クロスサイトスクリプティングとブログパーツ gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか? Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaS
[柔軟すぎる]IEのCSS解釈で起こるXSS:教科書に載らないWebアプリケーションセキュリティ(3)(1/3 ページ) XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます (編集部) なぜか奥深いIEのXSSの話 皆さんこんにちは、はせがわようすけです。 第1回「[これはひどい]IEの引用符の解釈」と第2回「[無視できない]IEのContent-Type無視」でInternet Explorer(IE)の独自の機能がクロスサイトスクリプティング(XSS:cross-site scripting)を引き起こす可能性があるということについて説明してきました。 第3回でも引き続き、IE特有の機能がXSSを引き起こす例ということで、
こんにちは、SEの進地です。 XSS(Cross Site Scripting)脆弱性の中であまり注意を払われていないタイプにDOM Based XSSというものがあります。アナウンス自体は随分と昔から行われており、webappsec.orgでも2005/7/4にAmit Klein氏が"DOM Based Cross Site Scripting or XSS of the Third Kind"を発表しています。 Web 2.0的アプリなどでのAjaxの普及でJavaScriptが多用される現在のWeb開発では、DOM Based XSSが入り込む可能性は従来よりも高まっています。そこで、今回はこのDOM Based XSSについて説明しようと思います。 DOM Based XSSとは何か? 一般的にXSS脆弱性と聞いて思い浮かべるのは、攻撃者の悪意ある入力データ(JavaScript
追記2:2007-10-11 - hoshikuzu | star_dust の書斎を見ると、下に書いてるような対策では不十分なようだ。 追記:エスケープすべき文字は、Re: JavaScript内(文字列)にデータを出力する場合の適切なエスケープ手順|freeml byGMOなどを参考に。 シングルクォート(')をエスケープせずXSSの原因になっているサイトをけっこう見かけたので、どういう時問題になるのか書いておく。 JavaScriptの文字列を動的に埋め込む場合。 <script> var q = 'hoge"fuga'; document.getElementById('word').appendChild(document.createTextNode(q + 'の検索結果')); </script> のように、変数に代入する文字列を動的に作っている場合、RubyのCG
_今こそXSS対策についてまとめよう 沢出水(さわ いずみ)さんからトラックバックを頂戴した。 元々はホワイトリスト方式の優位は神話というエントリでホワイトリストはどう作る?を引用(批判)した事が発端の模様です。 一見真っ向対決しているようなので興味深く読ませていただいたのですが、正直、両者の主張の違いがわかりません。 どちらもXSS等インジェクション系の対策としてはアプリケーションで入力値が正しい形式の範囲内かチェックし、出力時に必要なエスケープ処理を行う、という結論に思えるんですけど… [ホワイトリストとブラックリストより引用] ご指摘の通りで、XSS対策は入り口でのバリデーションと表示(HTML組み立て)時のエスケープだ。しかし、元ブログの主題はホワイトリストとブラックリストの比較なので、「ただ、表面的に文章を追っただけでは『何をホワイトリストと呼ぶのか』という部分がだいぶ違う印象を
更新: 2008年1月27日 Web アプリケーションのセキュリティガイドラインには、たいていの場合「スクリプト内に動的生成の文字列などを出力してはならない」という掟があったりするのですが、それにあえて背く場合のお話。 こんな感じの HTML 断片があったとします。 <script type="text/javascript"> <!-- foo.bar = <%= value %>; //--> </script> そして、この「<%= value %>」の部分に、ユーザが検索文字列として入力した任意の値を入れるというのが課題です。もちろん、そのまま出力すると XSS であっさり死亡するので、何らかの処理をしてから出力する必要があります。ちなみに、ユーザが何を入力したのか正確に知りたいので、任意の文字を削除したりすることはできない (削除してしまうと仕様を満たせない) と考えてください。
WebOS Goodies へようこそ! WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 本日は、codeなにがしウィジェットを作る過程で思いついた、ちょっとしたネタをご紹介。外部から API などで取得したテキストを安全に自サイトで表示するための Tips です。 codeなにがし API のレスポンスに含まれるデータは、ほとんどが HTML エスケープされた状態で渡されます。ですので、基本的にはそのまま HTML に挿入できます。これはこれで便利な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く