何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
PHP6移行で増える脆弱なWebアプリ
(Last Updated On: 2009年9月19日)PHP6のリリースはまだまだ先の話なのですが、PHP6への移行で脆弱なWebアプリが大量に発生する可能性があります。 理由は2つ – mb_check_encodingで全ての入力文字エンコーディングが正しいかチェックしていない – PHP6のhtmlentities/htmlspecialcharにはマルチバイト文字チェックコードが削除される PHPのコードを書いている人も自覚していないと思いますが、この影響はかなりあると考えられます。 近日中にgihyo.jpのセキュリティブログに詳しい情報を記述します。 追記：PHP5.3のコードを見てみたら、バックポートすべきではないのにバックポートされてました。つまり、PHP6がリリースされたらと言う問題ではなく、今ある問題になっています。一応、改修を提案するつもりですがどうなるか判りませ
デブサミ200 優秀スピーカー賞
エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。Webシステムを対象としたセキュアコーディング／セキュアプログラミング、SAMM、ソースコード検査、Webシステム開発、パフォーマンスチューニングの技術支援、コンサルティング、セミナー開催、書籍などの執筆、PROVE for PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。 ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。 氏名：大垣 靖男 私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。 ご依頼・ご相談は info@es-i.jp まで。
Session Adoptionが攻撃に有用な実例
(Last Updated On: 2018年8月18日)PHP:既知のセキュリティ脆弱性 – Session AdoptionでWebmailアプリケーションであるSquirrelMailとRoundCubeがこの攻撃に脆弱であることを紹介しました。 タイミング良く(?)同じくPHPベースのWebmailアプリであるIMPにクロスサイトスクリプティング脆弱性が発見され修正されました。(IMP-4.3.3未満/IMP-4.2.2未満) 試しに、ソースコードをチェックしてみました。 IMPはsession_regenerate_idを呼び出しています。この為、SquirrelMail/RoundCubeと比べるより安全です。しかし、対策は十分ではありませんでした。 PHP:既知のセキュリティ脆弱性 – Session Adoptionで紹介した簡単なテスト結果では MomongaLinux5
PHP4.4.9のセキュリティ状態
(Last Updated On: 2018年8月13日)PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。 PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。 PHP4セキュリティ保守サービスではPHP 4にも対応しています。サポートしている脆弱性の概要は、弊社のお知らせをご覧下さい。 まだまだ、SQLインジェクションが無くなっていない事は非常に残念です。PHP4で作られたWebアプリケーションはSJISやEUCを文字エンコー
PHP 5.3の名前空間仕様が変更されました
(Last Updated On: 2018年8月13日)名前空間に関する議論は5年以上も行われていたのですが、今度こそ結論が出たようです。 何故このようなエントリを書くかというと、Software Design（技術評論社）の11月号にPHPの最新情報としてα版PHP 5.3を紹介しているからです。入稿後に仕様変更があったので最新号の記事ですが既に内容が古くなってしまいました。 # とは言ってもまだ新しい仕様のPHPは無いですが α版なので仕様や機能が大きく変更される事もありますが大きな変更がありました。見本誌が刷り上がった頃に名前空間の区切り文字が”::”だと静的にメソッドを呼び出す場合やクラス定数を呼び出す場合に困る場合がある、とPHP開発者のMLで議論になり始めました。 ML上、IRC上、オフラインの打ち合わせが行われ、数週間におよぶ議論の結果が昨日MLに投稿されました。名前空間の
ホワイトリストとブラックリスト – Firewallの場合
(Last Updated On: 2018年4月6日)ホワイトリストとブラックリストの議論はFirewallの利用が一般的になる過程で十分に議論され、90年代に議論され尽くした、と思っていました。しかし、解説の余地はまだまだあるようです。ネットワークFirewallによるセキュリティ対策を簡単に振り返り、セキュアコーディングの現状を考察したいと思います。 追記：このエントリはネットワークFirewallのポートフィルタリングについて議論しています。ホワイトリストで対策すべきはアプリケーション自体です。ネットワークFiewallはホワイトリスト型セキュリティで対策しますが、WAFなどのアプリケーションFirewallはブラックリスト方式で対策するのが現実的です。ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しな
ホワイトリストと出力
(Last Updated On: 2018年6月12日)先週末、まっちゃ445というセキュリティ勉強会にお呼び頂きました。未修正のPHP4/5の脆弱性やパネルディスカッションのパネラーとして話をさせて頂きました。関係者の皆様、いろいろ参考になりました。ありがとうございました。 この勉強会の主題の一つがWeb Application Firewall(WAF)でした。パネルディスカッションのテーマもWAFでした。進行役にはサイバー大学の園田さん、パネラーにはサーボーズラボの竹迫さん、HASHコンサルティングの徳丸さん、そして私の4人でパネルディスカッションを行いました。 3人ともWAFの効用や限界に意見の相違はなかったのですが、私と徳丸さんにはシステム開発に於けるブラックリストとホワイトリストの使い方には意見の相違があったと思います。うまく議論をまとめられなかったのでブログに書きます。 追
誤ったWAFの使い方 – 国連でも
(Last Updated On: 2018年8月8日)WAF(Web Application Firewall)とは、通常のレイヤー2や3（IP, TCP/UDP）レベルのファイアーウォールよりもさらに上のレベルのアプリケーション層のファイアーウォールです。アプリケーションはレイヤー7とも言われ、ネットワークスイッチなどではアプリケーションの中身まで参照してスイッチングするスイッチはレイヤー7スイッチと呼ばれてきましたが、ファイアーウォールではレイヤー7ファイアーウォールと呼ばれる事は少なく、WAFと呼ばれる事が多いです。 WAFの目的は名前からも明白です。Webアプリケーションを脅威から守るために利用されます。WAFはWebアプリケーションをセキュリティ上の脅威から守る事ができますが、昔レイヤー2/3のファイアーウォールの能力が誇大に広告され、誤った認識で利用されていたように、WAFの
「例えば、PHPを避ける」ってなぁにその曖昧な書き方？
(Last Updated On: 2014年12月5日)この記事のタイトルは参照しているページのタイトルをそのまま使っています。 誤解を招く記事 – LAMPセキュリティを強化する4つの方法で、 実行できる最も重要な対策は、PHPを使わないことです。 と、理解できない対策を勧めています。セキュリティの事を解っていない素人が書いた事は、記事の内容と趣旨から明らかです。 しかし、IPAにも同じような事が書いてあったのですね。「例えば、PHPを避ける」ってなぁにその曖昧な書き方？で書かれています。去年から掲載されていたと思います。 IIS+ASPのアプリにダメダメなWebアプリが多いのも事実ですが、言語を問わずダメなプログラムだらけです。LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠では最近発見されたPythonベースのCMS、Ploneの
LAMPセキュリティを向上させる方法
(Last Updated On: 2008年3月24日)LAMPはLinux, Apache, MySQLとPHPまたはPerl, Pythonを利用したWebシステムの総称として利用されている用語です。 特にLinux/Apache/MySQL/PHPはよく見かけるシステム構成です。ホスティングサービスを提供する会社でこの構成をサポートしていない会社を探すのが難しいくらいではないかと思います。広く使われていますが、「十分に安全な状態」と言える状況で運用されているケースはほとんどありません。 関連エントリ LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠 誤解を招く記事 – LAMPセキュリティを強化する4つの方法 脆弱性情報を収集する 全てのソフトウェアにセキュリティ上の問題が含まれている、と考えて間違いありません。利用しているソフト
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
(Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
(Last Updated On: 2014年12月5日)LAMPセキュリティを強化する4つの方法 http://enterprisezine.jp/article/detail/311 書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。 # 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。 実行できる最も重要な対策は、PHPを使わないことです。腐った果物を導入する前に、以下に目を通してください。 後にPerl/Ruby/Pythonの方がかなり安全である旨の記述があります。メモリ管理が必要ない同じスクリプティング言語のレベルで「Perl/Ruby/Pythonを使えばセキュアなアプリケーションができる」と考
セキュリティ関係の番組
(Last Updated On: 2008年2月26日)YouTubeに投稿されていたセキュリティ関係の番組です。 全て英語で字幕などはありません。日本でも同じような番組があるのかも知れませんが、テレビはニュースくらいしか見ないので放送されているのかどうか分かりません。 英国BBCのニュース番組のようのです。 Orthus（コンピュータセキュリティの会社）の方のコメントは全くの正論です。多くの会社はセキュリティ製品を購入することで安全性が確保できると考えて、もっとも基本的な対策であるソフトウェアのアップデートを行っていないケースは少なくありません。コンピュータシステムへの攻撃も進化しているので防御策のアップデートも書かせません。 比較的、最近アメリカで作成されたと思われる番組です。 番組中で「セキュリティ上の問題はネットワークではなくアプリケーションにある」と指摘しています。セキュリティ
ホワイトリストはどう作る?
(Last Updated On: 2018年8月13日)まずホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません。 例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1 私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力／出力の
OpenIDのライブラリにはCSRFに脆弱な物が多い
(Last Updated On: 2018年8月8日)GNUCitizenによると CSRF – It comes very handy. It seams that no matter how much you talk about it, very few pay attention on the problem. And it is not a problem that you can afford to have. And among the XSS issues, which most OpenID libraries have, CSRF (Cross-site Request Forgery) seams to be the most pervasive form of attack. http://www.gnucitizen.org/blog/hijacking-ope
どの言語で書いてもおかしなコードを書く奴は書く
(Last Updated On: 2013年12月1日)# 書きかけです。後で編集予定 「Web屋のネタ帳」のどの言語で書いてもおかしなコードを書く奴は書くに対するコメントです。その記事にはRubyのまつもと氏のブログの引用もあるのでそちらにも対するコメントでもあります。 言語が良いコードを書けるようサポートする事はできると思います。しかし、言語だけによって良いコード（安全なコード、メンテナンスし易いコードなど）が書けるようにはならないのではないでしょうか? 言語だけでは不十分だからです。 「どの言語で書いてもおかしなコードを書く奴は書く」とは昔から言われてきた事です。同じ人がおかしなコードを書きつづける場合もあるとは思いますが「どの言語のユーザでもおかしなコード（危険なコードであったり、メンテナンスが難しいコード、無駄が多いコード）を書く人はいるものだ」の意味で使われていると思います。
yohgaki's blog - いろいろ変わったXSSがありますが...
(Last Updated On: 2007年10月12日)私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。 <script> 123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>); </script> 好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。 日本語訳 http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html 原文 http://www.ecma-international.org/pu
yohgaki\'s blog - iptables：間違ったDoS対策
エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。Webシステムを対象としたセキュアコーディング／セキュアプログラミング、SAMM、ソースコード検査、Webシステム開発、パフォーマンスチューニングの技術支援、コンサルティング、セミナー開催、書籍などの執筆、PROVE for PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。 ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。 氏名：大垣 靖男 私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。 ご依頼・ご相談は info@es-i.jp まで。
CSRFに脆弱なルータはWHR-G54Sだけではないはず
(Last Updated On: 2018年8月14日)BaffaloのWHR-G54S http://buffalo.jp/products/catalog/item/w/whr-g54s/ にCSRF脆弱性とレポートされています。海外製品のレポートは見かけますが、日本製のSOHOルータのレポートは記憶にないです。よくある脆弱性なので日本製のレポートは初めてではないと思いますが、個人的には初物なので書きました。 WHR−G54SはCSRF対策がない（足りない?）ので認証状態にあればFirewall設定を変更できるようです。 SOHOルータはよくターゲットにされるので管理ページにログインしたら、ログオフしてブラウザを終了させた方が良いと思います。ログオフ機能が無くても普通はログオフするとセッション情報は消去されるはずです。ログオフ機能が付いていてもブラウザを終了させるのは、ログオフ機能の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
