実は標準の方が簡単で明解 – セキュリティ対策の評価方法
(Last Updated On: 2018年8月8日)なぜセキュリティ対策の区別が異なるのか？長年疑問だったのですが、その理由の一つが判りました。 以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか？と質問した時のツイートです。 @yohgaki どちらもセキュリティ上効果がありますが、WAFはセキュリティを主目的として、というよりセキュリティのためだけに導入するのに対して、バリデーションはセキュリティが *主目的ではなく* 元々実施すべきものだという主張です — 徳丸 浩 (@ockeghem) February 6, 2015 どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。 セキュリティ対策の評価方法 – 標準編 まず
セッションアダプション脆弱性がないセッション管理が必要な理由
(Last Updated On: 2018年8月18日)徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。 まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。 セッションアダプションに脆弱なセッション管理機構で困る代表的な
PHP 5.3の名前空間仕様が変更されました
(Last Updated On: 2018年8月13日)名前空間に関する議論は5年以上も行われていたのですが、今度こそ結論が出たようです。 何故このようなエントリを書くかというと、Software Design（技術評論社）の11月号にPHPの最新情報としてα版PHP 5.3を紹介しているからです。入稿後に仕様変更があったので最新号の記事ですが既に内容が古くなってしまいました。 # とは言ってもまだ新しい仕様のPHPは無いですが α版なので仕様や機能が大きく変更される事もありますが大きな変更がありました。見本誌が刷り上がった頃に名前空間の区切り文字が”::”だと静的にメソッドを呼び出す場合やクラス定数を呼び出す場合に困る場合がある、とPHP開発者のMLで議論になり始めました。 ML上、IRC上、オフラインの打ち合わせが行われ、数週間におよぶ議論の結果が昨日MLに投稿されました。名前空間の
Fedoraプロジェクトがクラックされた原因 – RedHat系ユーザは早急に対応が必要
(Last Updated On: 2018年8月14日)追記：斜め読みで勘違いしていた部分を修正しました。RHのSSHのパッケージが全部更新されていたのでここに脆弱性があったと読んでいました。 8/22リリースされたエラータです。 Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its as
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
(Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。
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のまつもと氏のブログの引用もあるのでそちらにも対するコメントでもあります。 言語が良いコードを書けるようサポートする事はできると思います。しかし、言語だけによって良いコード（安全なコード、メンテナンスし易いコードなど）が書けるようにはならないのではないでしょうか? 言語だけでは不十分だからです。 「どの言語で書いてもおかしなコードを書く奴は書く」とは昔から言われてきた事です。同じ人がおかしなコードを書きつづける場合もあるとは思いますが「どの言語のユーザでもおかしなコード（危険なコードであったり、メンテナンスが難しいコード、無駄が多いコード）を書く人はいるものだ」の意味で使われていると思います。
宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！
(Last Updated On: 2008年1月24日)追記： いろいろ異論がある事は分かっていながら書きましたが、ぼんやりと考えていた事は正確には伝わっていないと思います。このエントリの続きとして責任あるDM送信者はどのようにメールを送信すべきかを書きました。こちらの方が分かりやすいと思います。要はスパマーでないDM送信側は受信側にもっと配慮すべきだと考えています。その方が両方にとって利益になると考えています。 — 「迷惑メールを報告」ボタンを押させるな！ http://japan.internet.com/wmnews/20080116/7.html によると以下が読者によって迷惑メールとして処理されてしまう代表的な原因としています。 1. 配信頻度が読者の忍耐を超えている頻度になっている 2. 内容に魅力を感じなくなり飽きている 3. 内容がミスマッチを起こしている 4. 第一印象
UPnPルータ+Flash=深刻なセキュリティ問題
(Last Updated On: 2008年1月18日)GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、 Hacking The Interwebs http://www.gnucitizen.org/blog/hacking-the-interwebs に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日本でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。 攻撃 Flashを利用したUPnPルータの攻撃シナリオは以下になります。 UPnPが有効なルータがある 悪意のあるFlashをWebブラウザで参照する UPnPルータの設定を変更するSOAPリクエストを
SquirrelMailのコードが改竄される
(Last Updated On: 2007年12月16日)追記: 攻撃が目的の改竄だった模様です。 http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1 —- http://squirrelmail.org/index.php によると、12/8にSquirrelMail 1.4.12のコードが改竄されていたようです。 While we believe the changes made should have little impact, we strongly recommend everybody that has downloaded the 1.4.12 package after the 8th December, to redownload the package. The code modifi
サーバシグニチャは隠すのが当たり前
(Last Updated On: 2007年9月4日)私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。犯罪者がどのように攻撃するか？を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。攻撃に使える情報は全て使わない訳がありません。 最新版を使っているから安全ではない事も明白です。サーバに0day攻撃の脆弱性が発見された場合どの情報を使います？公開または推測できるバージョン情報に決まっています。 フィンガープリンティングでかなりの確率で推測可能、という議論もあるとは思います。しかし、適切に運用／設定されているシステムなら細かいバージョン番号までは推測できない場合が多いと考えられます。 犯罪者が攻撃に利用している、利用する可能性が
mod_pythonの脆弱性
(Last Updated On: 2007年3月9日)MOPBでPHPの脆弱性ばかり書いているので他の脆弱性も書いておきます。 Miles Egan discovered that mod_python, when used in output filter mode, did not handle output larger than 16384 bytes, and would display freed memory, possibly disclosing private data. Thanks to Jim Garrison of the Software Freedom Law Center for identifying the original bug as a security vulnerability. 出典：USN-430-1
yohgaki's blog - なぜPHPアプリにセキュリティホールが多いのか?
(Last Updated On: 2018年8月13日)技術評論社の新サイトで「なぜPHPアプリにセキュリティホールが多いのか?」をテーマにブログ風の記事を掲載させていただく事になりました。第一回は「CVEでみるPHPアプリケーションセキュリティ」です。 http://gihyo.jp/serial/2007/php-security/0001 CVEをフォローしている方であればPHPアプリケーションの脆弱性レポートの多さが目立っていることはよくご存知と思います。何故CVEエントリが多いのか解説しています。よろしければご覧下さい。 技術評論社の須藤さんに編集していただいているので私が書いた文章より読みやすいです。 今、気が付いたのですが、SecurityForcusに次の様な記載がありました。 The problem is, PHP applications accounted for
JavaScriptのソースに重要なデータを埋め込むなんて….
(Last Updated On: 2007年1月3日)GmailでJavaScriptのソースとしてコンタクトリストデータを埋め込んでいたため、第三者がコンタクトリストを盗めてしまう、という問題が話題になっています。 まだ詳しく調べていませんがsrc属性に指定されたソースは誰でも（どのサイトからでも）取得できるブラウザの仕様を利用したものだと思います。 比較的早くからsrc属性で他のサイトのJavaScritpが指定できる仕様のリスクは指摘されていました。Gmailでさえ重要なデータをJavaScriptのソースに埋め込んでいるのですからAjaxアプリケーションの多くに同じ脆弱性があるような気がします… 手っ取り早く不完全な方法で修正するにはリファラチェック、きちんと修正するならJavaScriptのリクエストに鍵を付けてチェックする、といった方法で対策可能です。 http://exam
まちがった自動ログイン処理
(Last Updated On: 2018年8月20日)問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
プログラミング言語ベンチマーク
(Last Updated On: 2018年8月3日)RubyのMLを見てPython vs. Rubyのベンチマーク結果がRubyにとって良くないのでどう最適化するか?という旨のメール（件名はpython/ruby benchmark.）がありました。 RubyとPythonの比較 http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=python&sort=fullcpu PHPとRubyの比較 http://shootout.alioth.debian.org/benchmark.php?test=all&lang=php&lang2=ruby&sort=fullcpu PHPとPythonの比較 http://shootout.alioth.debian.org/benchmark.php
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
