CWE-20入門
サマリ この記事の想定読者は、企業等の脆弱性ハンドリング担当者です。脆弱性情報にしばしば出てくるCWE-20の読み解き方を説明します。 CWEとは CWEはCommon Weakness Enumerationの略で、日本語では「共通脆弱性タイプ一覧」と訳されています。この訳からも分かるように、脆弱性をタイプ毎に分類しているものです。つまり、SQLインジェクション、XSS、バッファオーバーフロー等に、CWE-XXXという「分類番号」をふったものと考えるとわかりやすいでしょう。以下は、IPAが公表しているCWEの解説記事からの引用です。 1999年頃から米国政府の支援を受けた非営利団体のMITRE(*2)が中心となり仕様策定が行われ、2006年3月に最初の原案が公開されました。その後、40を超えるベンダーや研究機関が協力して仕様改善や内容拡充が行われ、2008年9月9日にCWEバージョン1.
OWASPのSQLインジェクション対策方針を読んで「おまえは俺か」と思った
つい最近まで、グローバル・スタンダードのセキュリティ施策ではバリデーションが極めて重視されている、いささか過剰ではないかと思っていたのですが、OWASPの文書を読みなおしたところ、これは僕の思い過ごしだったかと思い始めました。あくまでOWASPに限った話ではありますが… OWASP Top 10 2004については、以下のようなプレゼンをしたことがあります（2012年3月27日）。 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ OWASP Top 10 2004をはじめとして、バリデーションが過剰に重視されているのではないかという指摘でした。 しかし、最近OWASPの文書を読みなおしてみると、OWASP Top 10 2004当時にあった「バリデーション至上主義」のようなものはすっかり影を潜め、私が（そして日本の専門家の多くが）言っていることとほとんど変わらないことに
WordPressの侵入対策は脆弱性管理とパスワード管理を中心に考えよう
この記事はWordPress Advent Calendar 2015の7日目の記事です。 今年初めてWordCamp Tokyoにて講演の機会をいただき、WordPressのセキュリティについて話しました（スライド）。そこでもお話ししましたが、WordPressに限らず、Webサイトへの侵入経路は2種類しかありません。それは以下の2つです。 ソフトウェアの脆弱性を悪用される 認証を突破される したがって、侵入対策としては以下が重要になります。 全てのソフトウェア（OS、Apache等、PHP、WordPress本体、プラグイン、テーマ等）を最新の状態に保つ パスワードを強固なものにする 以上! と叫びたい気分ですが、それではシンプル過ぎると思いますので、以下、WordCampでお話した内容とリンクしながら、もう少し細く説明したいと思います。 全てのソフトウェアを最新の状態に保つ Word
嵐のコンサートがあるとダブルブッキングしてしまうホテル予約システムを作ってみた
今年の5月1日に、仙台市内のホテルで多重予約のトラブルが発生したと報道されています。 部屋数２０３室の仙台市のビジネスホテルで、９月１８～２３日の宿泊予約を数千件受け付けるトラブルがあった。アイドルグループ「嵐」のライブが宮城県内で開催される期間だった。インターネットでの申し込みが殺到し、システム障害が起きたとみられるという。 トラブルがあったのは、仙台市泉区の「ホテルルートイン仙台泉インター」。ホテルなどによると、９月１９、２０、２２、２３日に宮城スタジアム（宮城県利府町）で嵐がライブを開くことが明らかになった後の５月１日午前５時ごろ、ネットを使った予約申し込みが殺到していることに気づいたという。 ２０３室のホテルなのに「予約」数千件 嵐公演で殺到か：朝日新聞デジタル より引用 5月1日の朝に何があったのか調べてみると、この日の早朝にテレビや新聞でコンサートの情報が流れたようですね。 お
みずほ銀行のトランザクション認証を試してみた
既に報道されているように、インターネットバンキングに対する不正送金事件が多発しています。 警察庁は2015年2月12日、2014年（平成26年）の1年間に発生した、インターネットバンキングでの不正送金事件の被害状況などに関するデータを発表した。 不正送金事件の発生件数は1876件となり、前年の1315件から500件以上増加。被害額については約29億1000万円となり、前年の14億600万円から2倍超の増加となった。 2014年のネットバンキング不正送金は約29億円で法人被害が激増、警察庁発表 より引用 このような状況を受けて、フィッシング対策協議会では、インターネットバンキングの不正送金にあわないためのガイドラインとして以下の「鉄則」を公開しています。 第一の鉄則：乱数表等（第二認証情報）の入力は慎重に！ 第二の鉄則：インターネット利用機器を最新の状態に保とう！ これらは確かに重要な施策で
「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価
弊社本社の麻布十番移転に伴い、本社近くの麻布図書館を利用しています。麻布図書館は土地柄のイメージにあう瀟洒な建物で、蔵書がない場合は港区の他の図書館から取り寄せ（無料です）ができますので、よく利用しています。今回は、山田祥寛さんの「10日でおぼえるPHP入門教室 第4版 」を借りて読んでみました。一読して、本書がセキュリティにもよく配慮されていることがわかりましたので、以下にご紹介したいと思います。 クロスサイトスクリプティング(XSS) 表示の際にHTMLエスケープするという原則を忠実に守っています。そのため、下記の e() という関数を定義して呼び出しています。 function e($str, $charset = 'UTF-8') { return htmlspecialchars($str, ENT_QUOTES, $charset); } その他にもXSS対策として重要な下記の
EximのGHOST脆弱性の影響とバリデーションの関係
追記(2015/2/6) 大垣さんから訂正依頼のコメントを頂いておりますので合わせてお読みください。徳丸としては特に訂正の必要は感じませんでしたので、本文はそのままにしています。そう思う理由はコメントとして追記いたしました。 (追記終わり) 大垣さんのブログエントリ「GHOSTを使って攻撃できるケース」を読んだところ、以下のようなことが書いてありました。 1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。 2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。 3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。 【中略】 どんなソフトウェアが危ないのか？ ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。 インタラクティブな動作を行っ
気づけばプロ並みPHP 副読本：お助け電子BOOKへの寄稿の顛末
谷藤賢一さんの著書『気づけばプロ並みPHP~ショッピングカート作りにチャレンジ! 』に、発売1周年の謝恩キャンペーンとして『副読本：お助け電子BOOK』が公開されました(*1)。私はこの副読本の中で、『第2章 【徳丸 浩氏 スペシャル寄稿】安全なWebアプリケーションのために』を寄稿しています。このエントリでは、寄稿の顛末を報告したいと思います。 動機 私が本書『気づけばプロ並みPHP』を購入したのは昨年の10月29日ですから、本書が出版されてまもなく、今から約1年前です。私は本書を一読して、セキュリティ上の多数の問題があることに気がつきました。 以前は、セキュリティ上の問題が多い本は書評をブログ記事として書くことも多かったのですが、この際は書評という形にするのはためらいがありました。その理由は以下の様なものです。 私のブログの読者層はセキュリティに関心の高い方たちであり、本書の読者とは重
digitalOceanクラウド上に安く簡単にkippoハニーポットを構築する
ozumaさんの公開された抱腹絶倒のスライド資料「さくらのVPSに来る悪い人を観察する その２」が凄い人気で、ブクマコメントなどで「ぼくもやってみたい」という希望が多いようです。既に、同じozumaさんが「sshハニーポットをkippoで作ってみる」というエントリで作り方（CentOS6.4想定）を公開されていますが、pythonのモジュールのセットアップなど少し難しいという人がいるかもしれません。 それ、digitalOcean + Ubuntuならもっと簡単に安く（しかも安全に）できるよ ということで、簡単・安い・安全な kippoハニーポットの作り方を説明します。digitalOceanは一時間約1円の完全従量制なので、お財布も安心ですw digitanOceanのアカウントを作成する こちらを参考にdigitalOceanのアカウントをご用意ください。こちらのリンクからアカウントを
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入した
Webサイトの改ざん事件が多発しています。Webサイトに対する基本的なセキュリティ施策を実施していればまず被害にあうことはないとは思うものの、全ての手口が公開されているわけではないので、何となく「嫌な感じ」もします。 【参考】 Web サイト改ざんに関する注意喚起(JPCERT/CC) 2013年6月の呼びかけ 「 ウェブサイトが改ざんされないように対策を！ 」(IPA) @Police ウェブサイト改ざん事案の多発に係る注意喚起について(pdf) 5月から多発しているHP改ざんインシデントをまとめてみた。 - piyolog 当方のサイト（会社、個人）は、一通りのセキュリティ施策は実施しているつもりですが、絶対に改ざんされないかというと、改ざんされることは想定しておかなければならないと考えています。 当方のセキュリティ施策の例 FTPをやめ、sshのみで管理運用 sshのパスワード認証を
eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策
eBook Japanに対する不正アクセスについて、詳細の発表があり、いわゆる「パスワードリスト攻撃」であることが発表されました。 前回のご報告までは「複数のIPアドレスからログインページに対して機械的に総当たり攻撃等を行う大量アクセス行為（ブルートフォースアタック）」とご説明しておりましたが、詳細調査の結果、「不正の疑われる複数のIPアドレスからログインページに対して、予め持っていたログインIDとパスワードの適用可否を試行する大量アクセス行為」であることが判明いたしました。 つまり、大量アクセス行為を仕掛けてきた者は、当社以外の他のサービスなどで他のサービスのログインIDとパスワードを不正に入手し、ユーザーがログインIDとパスワードを共通に設定している可能性を狙って当社サービスに不正にログインしようとし、上記件数についてはログインに成功してしまったということです。 そのように判断した根拠
ModSecurityをソースからビルドしてhashdos対策に活用する
このエントリではModSecurityをソースからビルドする方法を説明した後、hashdos専用のチューニングを施す流れを説明します。 はじめに既にModSecurityについては、CentOS+yumおよびUbuntu+apt-getにより導入する方法を説明しています。このエントリでは、ModSecurityをソースからビルドする方法を説明します。 ModSecurityのビルドは依存関係が複雑であり、バージョンによってビルド方法が変わるなど、面倒な面があります。このエントリでは、CentOSとUbuntuの場合について、実際的なビルド方法を説明します。 準備するもの ModSecurityは以下のプロダクトに依存しています(ModSecurity HandbookP27)。ビルドに先立って準備しておく必要があります。 Apache Portable Runtime(APR) APR-U
PDOにおける一応の安全宣言と残る問題点
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと
そろそろWAFに関して一言いっとくか～三重苦を乗り越えてWAFが普及するための条件とは～
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2） 備忘のため転載いたしますが、この記事は2008年7月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 なお、この記事を書いた後、WAFはこの記事の予言（願い?）通りに進展したように思います。そのあたりの歴史については、こちらのインタビュー記事を参照下さい。 補足終わり PCIデータセキュリティ基準(PCIDSS)がWAF(Web Application Firewall)について言及していることなどから、最近再びWAFへの関心が高まっている。一方、WAFは、一部のユーザや専門家に非常に評判が悪い。なぜ、そのようなことになるのか。本稿では、WAFの基本機能を説明した上で、その限界と運用上の問題を指摘し、今後のWAFの使い方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
