セキュリティニュースサイトに史上最大規模のDDoS攻撃、1Tbpsのトラフィックも
米セキュリティ情報サイトの「Krebs on Security」が大規模な分散型サービス妨害（DDoS）攻撃を受けてダウンした。攻撃の規模は665Gbpsに達していたという。別のWebサイトでは1Tbps近い規模のDDoS攻撃も伝えられ、史上最大規模のDDoS攻撃が相次いで発生している。 Krebs on Securityは米東部時間の9月20日夜から大規模なDDoS攻撃の標的となり、21日の時点では、同サイトをホスティングするAkamai Technologiesのおかげでもちこたえていると報告していた。 攻撃の規模は20日午後8時の時点で665Gbpsに達し、その後の分析では620Gbpsという数字が出た。Akamaiがこれまに経験した攻撃は、今年（2016年）に入って発生した363Gbpsが最大だったという。 これと前後してフランスのインターネットサービスプロバイダーOVHは9月22
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
NginxでHTTPS : ゼロから始めてSSLの評価をA+にするまで Part 1 | POSTD
数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report で
glibcのgethostbyname関数に存在するCVE-2015-0235(GHOST)脆弱性について - ブログ - ワルブリックス株式会社
glibcのgethostbyname系関数に脆弱性の原因となるバグが発見されCVE-2015-0235(GHOST)と命名されたようです。放置した場合は相当多くのアプリケーションがこの脆弱性の影響を受けることが予想されます。 glibcは libcのGNUバージョンです。libcはアプリケーションではなく、事実上全てのアプリケーションが利用しているライブラリです。OSの中ではカーネルに次いで重要な部分と言えます。Linuxシステムでは(ことサーバー用途においては)例外なく glibcが使われています。 この glibcに含まれる gethostbyname系関数の実装に 2000年頃から存在したバグが今になって発見され、CVE-2015-0235 通称 GHOSTと命名されました。ネットワークで何らかの通信を行うアプリケーションは必ず※この関数を使用します。 ※追記: 名前解決をサポート
お前このサブネットでも同じ事言えんの？ - 知らないけどきっとそう。
,、,, ,、,, ,, ,, _,,;' '" '' ゛''" ゛' ';;,, （rヽ,;''"""''゛゛゛'';, ﾉｒ） ,;'゛ i ＿ 、＿ iヽ゛';, ,;'" ''| ヽ・〉 〈・ノ |ﾞ゛ `';, ,;'' "| ▼ |ﾞ゛ `';, ,;'' ヽ＿人＿ / ,;'_ ／ｼ、 ヽ⌒⌒ / ﾘ ＼ | "ｒ,, ｀"'''ﾞ´ ,,ﾐ゛ | | ﾘ、 ,ﾘ | | i ゛ｒ、ﾉ,,ｒ" i _| | ｀ー――----┴ ⌒´ ） （ヽ ＿＿＿＿＿＿ ,, ＿´） （_⌒ ＿＿＿＿＿＿ ,, ィ 丁 | | | 前回のエントリ で軽く触れましたが、ARPスプーフィングを用いると、サブネット内からデフォルトゲートウェイを通って外に出て行くはずのパケットを、自分のホ
高木浩光＠自宅の日記 - 「個人情報」定義の弊害、とうとう地方公共団体にまで
■ 「個人情報」定義の弊害、とうとう地方公共団体にまで 現行個人情報保護法の「個人情報」の定義に不備があることを、これまでずっと書き続けてきた。「どの個人かが（住所氏名等により）特定されてさえいなければ個人情報ではない」（のだから何をやってもよい）とする考え方がまかり通ってしまいかねないという危機についてだ。 2003年からはRFIDタグ、2008年からはケータイIDによる名寄せの問題を中心に訴えてきたが、当時、新聞記者から説明を求められるたび、最後には「被害は出ているのでしょうか」と、問われたものだった。当時は悪用事例（不適切な事例）が見つかっておらず（表沙汰になるものがなく）、これが問題であるという認識は記者の胸中にまでしか届かなかった。 それが、昨年夏から急展開。スマホアプリの端末IDを用いた不適切事案が続々と出現し、それぞれそれがなぜ一線を越えているか説明に追われる日々になった。ス
au by KDDI はアホなのか(mediba) - いいえファジイです。
あの悪しきミログと提携し、悪い意味で有名なAirPushのノボットを買収した KDDI子会社のmedibaさん このmedibaという会社、広告業をする前に会社として個人のプライバシーへの考え方がおかしいのか 度々問題を起こしますが(auマーケットでのAirPush等) 信じられない事にこんな会社がauポータルの運営もしているという恐ろしい状況 AirPushの時は、前から海外ではAirPushが問題になっていたにも関わらず 「KDDI 通知バー広告表示」問題！知らなかった人に教えたい様々な指摘まとめ (NAVERまとめ) auマーケットにAirPush導入してKDDIというキャリアはバカじゃないのと 海外から失笑されKDDIという知名度を上げた訳ですが そんなmedibaさん、またやらかしたというか 今まで問題になった事を一つも学習していないようでびっくりです。(わざとだと思うけど) 個
書籍「Android Security」の暗号鍵生成方法には課題がある - ockeghem's blog
書籍「Android Security 安全なアプリケーションを作成するために」は既に各方面で絶賛されているように、Androidアプリケーションの開発者には必携の書籍だと思いますが、新しい分野だけに、首をひねらざるを得ない箇所もありました。このエントリでは、同書第10章「暗号化手法」から共通鍵の生成方法について議論します。 はじめに 書籍「Android Security」（業界では「タオ本」と呼ばれているので、以下タオ本と記述）の10章では、端末内のファイルを暗号化して保存する手法について説明されています。その際に問題となるのが、鍵の生成と保管の方法です。スマートフォン端末、とくにAndroid端末は、アプリケーションのリバースエンジニアリングとルート化の可能性は常にあるため、あらゆる場合にも破られない暗号化というものはありません。このため、守るべき情報資産と、想定する脅威（言い換え
遂にｷﾀ - .∵･(ﾟ∀ﾟ)･∵. - ｯ!!大事なGoogleアカウントを堅牢に守りきる2段階認証プロセス日本語版がとうとう有効になりました！ - 適宜覚書-Fragments
遂にｷﾀ - .∵･(ﾟ∀ﾟ)･∵. - ｯ!!大事なGoogleアカウントを堅牢に守りきる2段階認証プロセス日本語版がとうとう有効になりました！ Googleアカウントは、Googleのサービスを使う上でとても重要です。各種のサービスの利用設定はもとより、そこで蓄積したデータの管理はアカウントに紐づけられています。これは裏を返せば、アカウントの認証情報を取られてしまうと被害が甚大となります。Google側としてもこれを認識してユーザに認証情報を保護するよう啓蒙してきました。 でも、それには限界があって詐取に対する有効な手段として、今年2月に2段階認証プロセスが採用されました。日本語版も7月末に公開されたものの携帯電話でのコード受信が利用出来ず形だけのものとなっていました。恐らくは12月上旬ひっそりですが、とうとうこの機能が利用可能になりましたので導入プロセスを以下に紹介します。 【重要】
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
固有IDのシンプル・シナリオ
結城浩 RFIDなどの、固有IDの問題を考えるためのシンプル・シナリオを提示します。 シンプルなシナリオと具体例を通して、固有IDの注意点がどこにあるかを明確にしましょう。 目次 はじめに このページについて このページの構成 わたしについて 「固有IDのシンプル・シナリオ」 時刻(A): 場所(A)にて 時刻(B): 場所(B)にて ボブが知りえたこと シンプル・シナリオ適用例 適用例1: メンバーズカード 適用例2: IDの自動読み取り 適用例3: 読取機を持ち歩く人 適用例4: ダイヤの密輸 適用例5: 徘徊老人の命を救う 適用例6: 遊園地の迷子探し 適用例7: 携帯電話 固有IDに関連するQ＆A 固有IDのシンプル・シナリオで、何を言いたいのか？ メンバーズカードの例は問題なのか IDには個人情報が盛り込めないのではないか？ 暗号化すれば大丈夫？ 強固なセキュリティでデータベース
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ