セキュアコーディングを理解できていない例
(Last Updated On: 2019年1月9日)追記：解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。 セキュリティの専門家と呼ばれる人であってもセキュアコーディング／セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。 参考1：セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング／セキュアプログラミングの歴史は理解しておた方が良いかも知れません。 参考2：そもそも、原理的／論理的に入力対策を無視／軽視したセキュリティ対策は誤りです。 「出力対策だけのセキュリティ設計」が誤りである理由 参考3：前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利
IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない
(Last Updated On: 2019年2月1日) IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。 重大な誤りとは以下です。 CWE-20 – 出鱈目なデータを排除する検証（入力バリデーション）について一切記載がない コンピューターサイエンス／システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング／セキュアプログラミングの導入を要求しています。 ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題
実は標準の方が簡単で明解 – セキュリティ対策の評価方法
(Last Updated On: 2018年8月8日)なぜセキュリティ対策の区別が異なるのか？長年疑問だったのですが、その理由の一つが判りました。 以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか？と質問した時のツイートです。 @yohgaki どちらもセキュリティ上効果がありますが、WAFはセキュリティを主目的として、というよりセキュリティのためだけに導入するのに対して、バリデーションはセキュリティが *主目的ではなく* 元々実施すべきものだという主張です — 徳丸 浩 (@ockeghem) February 6, 2015 どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。 セキュリティ対策の評価方法 – 標準編 まず
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
(Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。
どの言語で書いてもおかしなコードを書く奴は書く
(Last Updated On: 2013年12月1日)# 書きかけです。後で編集予定 「Web屋のネタ帳」のどの言語で書いてもおかしなコードを書く奴は書くに対するコメントです。その記事にはRubyのまつもと氏のブログの引用もあるのでそちらにも対するコメントでもあります。 言語が良いコードを書けるようサポートする事はできると思います。しかし、言語だけによって良いコード（安全なコード、メンテナンスし易いコードなど）が書けるようにはならないのではないでしょうか? 言語だけでは不十分だからです。 「どの言語で書いてもおかしなコードを書く奴は書く」とは昔から言われてきた事です。同じ人がおかしなコードを書きつづける場合もあるとは思いますが「どの言語のユーザでもおかしなコード（危険なコードであったり、メンテナンスが難しいコード、無駄が多いコード）を書く人はいるものだ」の意味で使われていると思います。
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リクエストを
PRGパターンって不必要…
(Last Updated On: 2014年12月5日)PRGパターンって不必要…というより有害な気がします。 追記/訂正: 普通に実装するとこの後に書いている問題は発生しないので、別の実装が「戻る」ボタンで戻れない原因の様です。普通にリダイレクトすれば302でブラウザに返すので前のページまで戻ります。態々別のリダイレクトをしているPRGパターンが有害と言う事なのかも知れません。今度戻れないページにあったら調べてブログに書きます。（あまり突くと攻撃と見なされるかもしれないので問題ですけど… 役に立つ対策ではないですがもしかすると重複ポスト対策なのかも知れません。不特定多数向けアンケートなどだと安直にリダイレクトで制限だけしてOKとしているのかも知れません。幾つかのパターンがありそうなので調べてみる価値はありそうです）私はデータのやり取りが増え、かつGETを利用することにより汎用性が劣るこ
意図が伝わってないのかな？
(Last Updated On: 2018年8月13日)「なぜPHPアプリケーションにセキュリティホールが多いのか？」をテーマにした技術評論社のブログ風の記事を書いています。 一番新しい http://gihyo.jp/dev/serial/01/php-security/0008 ですが、自分で防いだつもりのセキュリティホールは実は防いだ事になっていなかった、アプリケーションが多く在りました。というより今でも作り続けられています。原因は「サニタイズ」による脆弱性の回避であるものが多いです。なので「サニタイズ」ではなく「バリデーション」と「適切なエスケープ」によって対策すべきです、と書きたかったのですが「エスケープ」の部分を書いてないですね。バリデーションの時に説明するつもりですが、確かに尻切れとんぼのような感じです。 編集の方からこんな感じなのですがどうなんでしょう？メールが来ていまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
