セキュアなアプリケーションアーキテクチャ
セキュアなアプリケーションには共通したアーキテクチャがあります。基本的には防御的プログラミング(セキュアプログラミング)を行い、防御的プログラミングのテクニックの1つである契約プログラミングを実践したアーキテクチャがセキュアなアーキテクチャです。
アプリケーションのセキュリティ問題のほとんどはインジェクション問題です。インジェクション問題以外にもセキュリティ問題はありますが、ここではインジェクション問題のみを考慮します。
セキュアなアプリケーションには共通したアーキテクチャがあります。基本的には防御的プログラミング(セキュアプログラミング)を行い、防御的プログラミングのテクニックの1つである契約プログラミングを実践したアーキテクチャがセキュアなアーキテクチャです。
アプリケーションのセキュリティ問題のほとんどはインジェクション問題です。インジェクション問題以外にもセキュリティ問題はありますが、ここではインジェクション問題のみを考慮します。
記事を探すことができなかったのですが、少し前に元記事が英語で日本語訳された記事に「セキュアプログラミング・コーディングはハイプ(誇大な宣伝)である」とする記事がありました。これには全く賛同できません。
なぜセキュアプログラミング”だけ”でセキュアなプログラムが作らないのか?理由を考えてみたいと思います。
CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow として2/16に公開されたセキュリティ問題に対するアクセスが多いようですが、古いglibcのページがヒットするようなので簡単にまとめておきます。コードレベルで詳しくは見ていません。詳しい事は他の方がまとめてくれると思います。この検索してこのブログに来てしまった方向けに簡単に紹介します。
マイナンバーのチェックデジットを確認する必要があったのでPHP関数を作りました。
いつかは忘れるくらい前に正規表現のアルゴリズム自体を利用してDoS攻撃を行うReDoSが発表されていました。今まであまり気にしていなかったのですが、検索しても日本語のページが出てこないようでした。詳しく知るためのリンクなどを紹介します。
最近は標的型攻撃の話題で持ち切りですが、もし自分が自分に標的型攻撃を行うならどうするか?紹介します。
Webシステムには様々なリスクがあります。より安全に利用するためのTipsを紹介します。
他の方も普通にこれから紹介する方法を使ってWebシステムにアクセスしている、と思っていたのですがそうでもないようです。これから紹介する方法でリクエストフォージェリやクロスサイトスクリプティングなどのリスクを排除/軽減できます。
リクエストフォージェリを再考してみたいと思います。リクエストフォージェリには
などがあります。これらは「リクエスト」を「偽装」(フォージェリ)する攻撃です。名前からは直感的にどのような攻撃なのかよく解らないですが、「攻撃リクエストのインジェクション」と考えると解りやすいと思います。
インジェクション脆弱性の発生原理は簡単です。エンジニアではないマネージャー向けに作った資料を基に原理を紹介します。
インジェクション脆弱性は、その種類に関わらず原理は同じです。原理が同じということは、対策も同じです。一つ一つのインジェクション脆弱性がどのように作られ、攻撃されるのか?は少しずつ異なりますが、基本的な部分は同じです。別々に考えるより、一まとめに考えて理解した方が応用もでき、新しい仕組みなどが生まれた場合にも対応できます。
追記:平成29年度の講座の情報は
をご覧ください。
岡山大学大学院のビジネスマインド養成講座の講義資料を公開します。
http://www.slideshare.net/yohgaki/ss-50426869
PDFダウンロードはこちら
誤字脱字、誤りなどがあったらご指摘頂けると助かります。
セキュアプログラミングの啓蒙にも少々食傷気味ですが、今回もセキュアプログラミングの話題です。IPAのセキュアプログラミング講座Web編は削除予定であるとFacebookではお伝えしましたが、ブログではまだだったので合わせて紹介します。
ISO 27000がセキュアプログラミングついてどのように書いているのか紹介します。ISO 27000シリーズはISMS(Information Secuirty Management System – 情報セキュリティマネジメントシステム)認証の根幹となっている国際セキュリティ標準です。ISMS導入で自動的にセキュリティ問題に対応できる!といったモノではありませんが、体系的なセキュリティ導入にとても役立つ規格で2015年6月29日時点で4646組織の認証登録があります。
最初、書いた時はユーザーが一人だけと頭にあったので思いっきり誤解していました。確かに複数ユーザーの場合は真正性に問題があります。修正版の差分をアーカイブを更新しておきました。
全体的なセキュリティ対策やセキュリティ対策の基本的概念の話が続いたので、個々の脆弱性に対応するための効果的な方法を紹介します。前提知識なく、個々の脆弱性に対応するには、個々の脆弱性全て知る必要があります。
昨日、セキュリティの話をしていて当たり前のことですが見過ごしていた点を教えてもらいました。セキュリティ対策の必要条件と十分条件です。