Greasemonkeyの過去においてのセキュリティ上の問題の解説。 Greasemonkeyだけに限らず、JavaScriptによるユーザ拡張を作成している全ての方に対して一読の価値があるドキュメントだと思われます。 原文：O'Reilly Media - Technology and Business Training Greasemonkeyの共通な落とし穴を避ける Greasemonkeyのセキュリティの歴史があなたの今にどう影響するのか (著) Mark pilgrim "Greasemonkey Hacks"の著者 2005/11/11 昔々、あるところにセキュリティホールがありました。（これは普通のおとぎ話ではないからそのまま読んでください。） Greasemonkeyのアーキテクチャは最初に書かれて以来大幅に変更されてきた。Version0.3は初めて広範囲に人気を得たバー
http://d.hatena.ne.jp/hoshikuzu/20060130#P20060130BARSFAKE http://d.hatena.ne.jp/amachang/20071010/1192012056 (IT戦記 - 一行で IE の JavaScript を高速化する方法) はじめに 次のような限定されたケースにおいてなのですが。説明上の都合でこれを課題Ａと呼ぶこととします。 <SCRIPT TYPE="text/javascript"> <!-- var strA = "$data"; // ・・・以下サイト運営者による処理記述例 alert(0); //--> </SCRIPT>上記のようなケースに限定してのオハナシですけれど、$dataをエスケープする方向でのXSS対策として金床さんなどによってかつて論議されて、このままでは使えそうにないと棄却されたJavaScr
ストーリー by yoosee 2007年09月03日 11時38分 いっそApache100.0とか表示しとけばいいじゃない 部門より 技術系ブログ「ウノウラボ」に「5分でできるウェブサーバのセキュリティ向上施策」という記事が掲載されて話題になっています。ApacheやOSのバージョンを表示しないようにする方法や、PHPでX-Powered-Byを応答しなくする方法が紹介された記事ですが、コメント欄や260件以上の登録を集めたはてなブックマークでは賛否両論になっています。「セキュリティがみじんも上がっていない」という意見や「セキュリティの甘さが見え見え」という意見がある一方で、隠さないでいると「こんな基本的なこともやっていないサイトと思われるよ」という意見も。そういえば、7月の@ITの記事「たった2行でできるWebサーバ防御の「心理戦」」にも同様のことが書かれていました。セキュリティ会社
だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ
Link: http://blog.php-security.org/archives/91-MOPB-Exploits-taken-down.htmlドイツで他人のコンピュータを攻撃するソフトウェアの公開などを禁止する法律が施行されたためMOPBの攻撃コードが削除されました。 ダウンロードリンクは在りますがダウンロードしたファイルの中身は以下のようになっています。 Dear Visitor, since Friday 10th, August 2007 a new and very troubling law is enforced in germany. It is no longer legal to create and/or distribute so called hacking tools in germany. This includes port scanners lik
携帯電話向けWebアプリの脆弱性事情はどうなっているのか@高木浩光＠自宅の日記 より リンク先のWebサイトには、Refererと共に端末IDもリクエストヘッダとして送信されているわけで、セッションID入りURLと端末IDがセットで流出するのだから、当然、同じHTTPリクエストを送るだけの方法でなりすましアクセスされてしまう。 URIにセッションIDを含める方法では、悪意のあるサイトにリンクを張るだけでRefererヘッダからセッションIDが取り放題となる。また、悪意のあるサイトにアクセスしたユーザーは端末IDもHTTPヘッダに含めそのサイトに送信してしまう。端末IDは簡単に詐称することが出来るので、端末IDをチェックしてもセッションハイジャックの防止線にはならない、というお話。 私は携帯端末は専門ではないので細かいことは良くわからないのだが、以下を前提にして、携帯電話からセッション
■ 蔓延する「サイバーパテントデスクのWWWサーバ」 「現場でコピペしてるんだ」の話から、5年前の話を思い出し*1、再び検索してみると、該当ページは増えていた。 http://www.yurinsha.com/ssl.htm インターネットセキュリティ（SSL）は安全です!! SSL（Secure Sockets Layer）は、WWWブラウザとWWWサーバ間でデータを安全にやりとりするための業界標準プロトコルです。 SSLには、認証と暗号化の機能があります。 認証機能により、接続しているWWWサーバが確かにNRIサイバーパテントデスクのWWWサーバであることを保証します。 また、暗号化機能により、検索内容が暗号化された上でインターネット上で通信されます。これにより、データがインターネット上で盗聴、改竄される危険性が小さくなります。 http://tweb.omt.ne.jp/ssl_in
目次 あらまし 1. 従来のスパム対策 2. S25Rスパム対策方式のコンセプト 3. クライアント制限の規則 3.1. 一般規則 3.2. ブラックリスト 3.3. ホワイトリスト 3.4. その他のフィルタ 4. 統計データ 5. S25Rスパム対策方式を大規模サイトで運用する方法 6. S25Rスパム対策方式をインターネット全体で運用するために 7. スパマーがS25Rスパム対策方式をすり抜ける方法 まとめ 付録A. Postfixでの設定方法 付録B. 拒絶記録抽出用スクリプト あらまし オープンリレー（第三者中継）を行うメールサーバが少なくなり、最近では多くのスパマーが、ADSLやケーブルネットワークなどのエンドユーザー用高速回線につながってボットに感染したたくさんのエンドユーザーコンピュータからスパムを直接ばらまいている。オープンリレーブラックリストはもはや役に立っていない。有
■ 素人メディアに脆弱性報告文化を破壊されるおそれ みなさんは、「ニセ脆弱性」という言葉を耳にしたことがあるでしょうか。 これは、見かけは脆弱性のようだけれども、実は、脆弱性とはとても言えないもののことで、「疑似エクスプロイト」や「似非ゼロデイ」などとも呼ばれます。 「そんなものがどこにあるんだ」とお思いの方も、例として、「サニタイジング」や、「hiddenは危険」や、「非接触スキミング」などの名前を挙げれば、「ああ、そういうもののことか」と納得されるかもしれません。それとも、かえって、「え？」と驚かれるでしょうか。 例えば、皆さんもよくご存知のように、「サニタイジングは脆弱性対策にいい」と盛んに言われ、ひところは大手コーディネーション機関もこぞって解説を出すほどのブームになりました。サニタイジングがよく語られたのは、もちろん、サニタイジングの対策効果に裏づけがあると信じた人が多かったから
mixi の画像表示方法が One Time URL 方式に変更 Posted by yoosee on Web at 2006-11-09 23:42 JST1 mixi、画像が外部のWebサイトで表示される仕様を修正mixi が仕様変更で日記等の画像が外部から見えないようにしたとのお知らせ。以下のページにアップロードされた画像のURLが変更となり、当該ページでのみ表示される仕様に変更となりました。メンテナンスのお知らせ 2006.11.08 以前に mixi の画像はどう配信されているのか という記事を書いたので、どのような認証方法にしているのか気になってちょっと見てみた。 画像の URL を見てみると、http://ic50.mixi.jp/p/(ランダムな文字列)/45532d00/diary/11/09/(ownerid)_123.jpg のようになっている。多分これは、日記の表
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
最終更新日: Wednesday, 29-Nov-2006 02:46:05 JST Webバグ CSRF (Cross Site Request Forgeries) DoS (サービス拒否) サニタイズ オレオレ証明書 Cookie Monster SQL インジェクション HTTP Response Splitting (レスポンス分割) HTTPのページのフレームにHTTPSのページを表示 バッファオーバーフロー フィッシング Forceful Browsing (強制ブラウズ) クロスサイトスクリプティング ゼロデイ(0day)攻撃 ディレクトリトラバーサル セッションハイジャック 権限昇格 OS コマンドインジェクション オープンプロキシ Webバグ ＼ __ ／ ＿ （ｍ） ＿ビーコーン |ミ| ／ ｀´ ＼ ('A`
記事データ 投稿者 望月真琴 投稿日時 2005-05-13T21:05+09:00 タグ CSRF htaccess mixi Movable Type まとめ セキュリティ 脆弱性 概要 MT をインストールしたら真っ先に行うべきセキュリティ対策の改訂版です。正しい認識と適切な対処、それとバックアップが肝だと思います。 リプライ 12 件のリプライがあります。 この記事の説明およびもくじ MT をインストールしたら真っ先に行うべきセキュリティ対策という記事を 2004 年 9 月に書きましたが、当時は Movable Type 2.661 の環境を想定して書いたもので情報としては古く、また多くのトラックバックをいただいたおかげで追加情報を得られたということもあり、新たにまとめ直してみようと思いました。 MT をインストールしたら真っ先に行うべきセキュリティ対策を既に読まれた方は、いくつ
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 「第2回 顧客データがすべて盗まれる」は、クロスサイトスクリプティング（XSS）と同様に実際のプログラミングを行うプログラマの責任であるという対策で、最も危険と思われるSQL InjectionとOS Command Injectionについて紹介した。今回は、プログラミング以前の設計段階で潜り込むセキュリティホール――見落としがちなセッション管理の脆弱性について説明していく。 We
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
■CSRF - クロスサイトリクエストフォージェリ CSRF - クロスサイトリクエストフォージェリ SpecIII - CSRF - クロスサイトリクエストフォージェリから引用させて頂きます。 CSRFの概略 CSRFはCross Site Request Forgeriesの略です。恥ずかしながら私は最近こういったこういった攻撃方法があることを知りました。日頃のアンテナの低さがバレますね。 CSRFはサイトに対する正規のユーザーの権限を利用した攻撃です。あるサイトのある処理を行うページに正規のユーザーを誘導し、強制的に望まない処理を発生させます。 具体的には記事の編集や削除といった機能を持つページのURLをダミーのリンクに埋め込んで踏ませたり、imgタグのsrcとして指定して知らず知らずのうちにアクセスさせます。特に後者の例ではユーザーが全く気がつかぬうちに攻撃が完了します。攻撃の結果
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く