全インターネットを遮断できるサイバー兵器
それは全インターネットを遮断できるサイバー兵器で、今ある防衛では止めようがない。 ―と、これを開発したミネソタ大のマックス・シュハード（Max Schuchard）氏と同僚のみなさんは言ってます。 でも大丈夫、まだ壊す気はないそうですから。この研究成果をもとに防衛改善を呼びかけているだけですよ。 シュハード氏が考えたのは、インターネットの構造そのものを逆手にとってインターネットを潰す新たな攻撃手段です。 ネットでは毎分何百もの接続ポイントがオフラインになるけど、ネットはそれを迂回するので、誰も気づきませんよね。ああいうことが可能なのも、インターネットを構成するもっと小さなネットワーク ―自律システム（autonomous systems、AS）と呼ぶ― がルータ経由で互いに交信し合っているから。ある通信パスが変わると、近くのルータがボーダー・ゲートウェイ・プロトコル（BGP）というシステム
Google's Vulnerability Reward Program - ma<s>atokinugawa's blog
Googleは2010年11月からGoogleのウェブアプリケーションのセキュリティ脆弱性を報告した人に報酬を支払う制度をスタートしました。僕も早速いくつか報告し、以前TwitterでGoogleから$7337頂いたよとつぶやきましたが、あれから新たに$6337の入金があり、今のところこの制度で$13174($1337 × 2 + $1000 × 2 + $500 × 17)を頂いています！ありがとう！ 追記 7337+6337=13674なので入金があったのは$13674($1337 × 2 + $1000 × 2 + $500 × 18)でした。合計を間違えてました。足し算難しい！＞＜+$500！ 修正されたものは情報を公開してもいいとのことなので、報告した中から多少変わったタイプの脆弱性を3つ紹介しようと思います。 <script>タグのsrcを細工することによるXSS こんなページ
JavascriptのMath.random()でユーザートラッキングができるという話 - kogelab::memo
表題の件について。 地味な話ですが、javascript（というかECMAの仕様）にあるMath.random()には、乱数のシードを与える方法が無いようです。 そんなわけで、われわれ一般市民は各ブラウザが独自に実装している、謎のシードで初期化された謎のアルゴリズムで作られた乱数を通常使うわけですが。 Mozillaからこんなの出てた。 曰く、Math.random()のシードによる初期化は、ブラウジングセッションごとに1度しか行われないと。 で、シードはまあ、かぶる率そんなに高くなさそうなので、そのシードをUSERの（擬似的な）ID代わりにしてしまえば、ユーザーのトラッキングができるよーん、とのこと。 はじめ読んだとき、「おおー、かっけー！」と思ったんですが、ちょっと待て。 シードって外から取れんのか。 というわけで、色々調べたところ、各ブラウザは（多分IEも）線形合同法による擬似乱数を
【レポート】7分でほぼ全無線LAN機器を攻撃可能! - 森井教授がWPA-TKIPの脆弱性を解説 (1) WPA-TKIPの検証結果で"誤解"を生んでから1年、新たな攻撃手法を披露 | エンタープライズ | マイコミジャ�
2009年8月、我々は一般の無線LAN機器でWPAよりもセキュアとされるWPA-TKIPを利用する際も脆弱性があることを示した。しかし、「中間者攻撃という必ずしも現実的でない環境を仮定したこと」、「MIC鍵を得ているという仮定の下で偽造パケットを1分以内に生成できること」が誤解を与え、その脆弱性の深刻さを十分伝えることができなかった。したがって、現在でも一部ではWPA-TKIPには深刻な脆弱性がないと認識されている。 その認識を改めるべく、我々は2010年8月に開催されたJWIS2010で「WPA-TKIPに深刻な脆弱性が存在すること」、「その脆弱性を突いて容易にシステムダウンさせることが可能なこと」を具体的な方法を交えて示した。WPA-TKIPには深刻な脆弱性が存在するのである。 WEPはもはや暗号ではない、ではWPA-TKIPは? 2008年10月、我々のグループはわずか4万パケット程
CVE - CVE
TOTAL CVE Records: 225772 NOTICE: Transition to the all-new CVE website at WWW.CVE.ORG and CVE Record Format JSON are underway. NOTICE: Legacy CVE download formats deprecation is now underway and will end on June 30, 2024. New CVE List download format is available now. The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.
今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた
「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。 これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。 このドキュメント作成に協力したという、独立行政法人産業技術総合研究所 情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月
Twitter用APIを悪用したJavaScriptの多重難読化
現在のIT部門にとって最大の脅威は、マルウエアに感染したWebページではないだろうか。マルウエアに感染したHTML文書は大抵の場合、活動内容を隠しておくために、JavaScriptで攻撃用コンテンツを動的に生成するようになっている。セキュリティ検査で発見されないようにするため、こうした攻撃の手口はどんどん複雑化している。今回分析するのは、自動解読エンジンをごまかす細工と5段階の難読化が施されたサンプルだ。 分析対象はWebページに感染した6Kバイトの難読化JavaScriptであり、解読していくと最後に攻撃用サイトを指す一つのiframeタグが現れる。攻撃者は暗号表やXOR演算、代入暗号に加え、古典的な文字入れ替えといった手法を組み合わせることで、最終的なコンテンツを隠そうとしている。当ブログでも以前こうした難読化手法をいくつか紹介した。 解読するには、ペイロードとなっているこのJavaS
Web Application Exploits and Defenses
A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz Want to beat the hackers at their own game? Learn how hackers find security vulnerabilities! Learn how hackers exploit web applications! Learn how to stop them! This codelab shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you'll get a chance to
WEBプログラマー必見！WEB脆弱性基礎知識最速マスター - 燈明日記
以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。 WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。 また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。 WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。 そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。 今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。 このまとめがWEBアプリケーション開発の参考になれば幸いです。 インジェクション クロスサイト・スクリプティング セッション・ハイジャック アクセス制御や認可制御の欠落 ディレクトリ・トラバーサル(Directory Traversal) CSRF（
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
知らなかったらNGなWEBアプリケーション脆弱性一覧 : mwSoft blog
先日、AmebaなうがCSRFという非常にポピュラーな脆弱性を披露したかと思ったら、ここ数日はセブンネットショッピングでXSSの脆弱性と、ID推測による他ユーザの個人情報閲覧の問題が発生しているという噂が流れています。 ユーザの情報を預かっておきながら、基本的なセキュリティの対策もできていないというのは、銀行に例えるなら、お金を預けようとした時に「お金は預かります。ちゃんと保管します。でも警備はあまりしないので盗まれたらスイマセン」と言われるようなものだと思う。 警備に穴があったというのではなく、まともに警備してませんでした、というのはさすがにありえないことです。 そこで、野良WEBプログラマである私が知っている脆弱性を列挙してみた。 私はプログラマであってセキュリティの専門家ではないです。しかも今年の春辺りからずっと外向けのWEBプログラムは組んでません。 その人間が知っているものを並べ
Windows 7のゲストアカウント名を変更してセキュリティを強化 | ライフハッカー・ジャパン
強化と言っても、ハッカーからの侵入を全てブロック出来るようになり、完璧なセキュリティシステムが出来上がる、というような大げさなものではないですが、ユーザ名とパスワードのコンビネーションをリモートハックしたり、マルソフトウェアなどを介して、アクセスを試みる部外者の侵入に対するセキュリティを少し強化できます。 ゲストアカウントのユーザ名がGuestの場合、ゲストアカウントが設定されていることが分かれば侵入出来る可能性がぐっとアップしてしまうわけです。How-To Geekの本家ホームページでライターMysticGeekがWindow 7でのゲストアカウント名変更方法を紹介してくれています。やり方は管理者でログインしてちょろちょろっと変更を加えるだけなのでとても簡単です。 やり方は下記の通り： 1. コントロールパネルから管理者ツールをクリック。 2. 管理者ツールのウィンドウでローカルセキュリ
URLを巡るだましの手口
スパム送信者は，メールをスパム・フィルタに見つけられないようにするために，たちの悪い様々な手を使う。例えば難読化やなりすまし，有名ブランドの不正使用といったことが行われると，スパム・メッセージ識別を目的としたコンテンツ・フィルタリング処理が難しくなる。 米シマンテックが最近見つけたスパム攻撃は，信頼できるドメインの名前の一部またはすべてを，形の似た文字を使ってまねたドメイン名を使ってなりすましていた。この手口を詳しく説明する前に，馴染みの薄い可能性がある「国際化ドメイン名」（IDN），「Punycode」，「同形異義語スプーフィング」に触れておこう。 IDN IDNはASCII文字以外の文字を含むドメイン名である。アラビア語や中国語の文字，サンスクリット語のデーバナーガリ文字など，非ラテン系の文字をドメイン名に入れることができる（関連記事：IDN）。 例：「ёxample.com」というド
ファイル名は「左から右に読む」とは限らない?!
ファイル名は「左から右に読む」とは限らない?!：セキュリティTips for Today（8）（1/3 ページ） 私たちの常識が世界では通用しないことがあります。攻撃者はそんな心のすきを狙って、落とし穴を仕掛けます。今回はそれを再認識させるかのような手法と、その対策Tipsを解説します（編集部） 皆さんこんにちは、飯田です。先日、セキュリティ管理者の方々と「今後のウイルス対策のあり方」について意見交換をする機会がありました。参加者からは活発な意見や質問も飛び交い、盛り上がりを見せた意見交換会となりました。私自身も多くの気付きや学びを得ることができ、貴重な時間を過ごすことができました。 その意見交換会の中で、Unicodeの制御文字を利用したファイルの拡張子偽装の話題が出ました。この手法は目新しい手法ではなく、数年前からすでに指摘されていたものです。しかし、久しぶりに本手法について議論するこ
SQLの暗黙の型変換はワナがいっぱい
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月24日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、SQLにおいて「暗黙の型変換」を使うべきでない理由として、具体的な「ワナ」をいくつか紹介します。 数値項目に対するSQLインジェクション対策のまとめにて説明したように、RDBの数値型の列に対してSQLインジェクション対策をする方法として、以下の三種類が知られています。 バインド機構を用いる パラメータの数値としての妥当性確認を行う パラメータを文字列リテラルとしてエスケープする このうち、方法3を使うべきでない説明の補足です。具体的には、方法3には、「暗黙の型変換」が発生しますが、それが思わ
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
Ruby スクリプトでデータを暗号化する方法 - WebOS Goodies
本日は、 Ruby の OpenSSL バインドを利用してデータを暗号化する方法をご紹介します。というのも最近、自宅サーバーにある各種データを Web 上のサービスに移動しようと画策していまして、その際にプライベートなデータは暗号化して保存したいのです。ほとんどの Web API は暗号化なしの HTTP で通信しますし、いくらパスワードで保護されているとはいえ、他所の HDD にプレーンな状態で保存するのは不安ですからね。 それ以外でもスクリプトで暗号化の処理をしたい場面はいろいろあると思います。そんなときは、ぜひ参考にしてください。 それでは、まずは暗号化の処理から。 OpenSSL はさまざまな暗号化アルゴリズムをサポートしていますが、ここではリファレンスでも推奨されている AES-256-CBC を使うことにします。ひとつの文字列（バイト列）を暗号化する関数は以下のようになります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTML5 Security Cheatsheet
html5security - Project Hosting on Google Code