2011年12月7日水曜日

第1回岡山PHP勉強会に参加しました。

第1回岡山PHP勉強会に参加してきたので、そのメモを残しておきます。

システム構築事例の話(…?)

  • 突発的なアクセスの増加
  • Yahooアタック
    • Yahooのトピックスにリンクが付くと…
    • 動画への直接リンクはやばい
  • PHPを選んだ理由
    • 簡単
    • みんな使っている
    • 自由度が高い
    • サーバ設定が簡単
    • 速い(?)
  • しかし
    • コードの統一性がない
    • セキュリティが最悪
  • フレームワークを活用することにした。
    • 開発時間の大幅短縮
    • ルールに従うと、コードが統一
    • DBとの連携が簡単
    • 表示が速い(ページキャッシュ機能)
  • PHP勉強法
    • 参考までに。
      • 目標を作る(アプリを1週間で作る。必ず日程を決めておく事。)
      • 入門書とリファレンスブックを購入
        • 作りたいものに近いサンプルがある本が良い
      • 説明を見ながらとにかく作る
      • リファレンスブックを見ながらソースコードを読む
      • 自作アプリケーションを作成する。
    • オープンソースを解読(バグ情報は便利)
    • 参加する
    • オープンソースを作る
    • 勉強会に参加する
  • TIPS
    • コードのガイドラインを決める
    • コードの最適化
    • セキュリティに気を使え!
      • サニタイズ処理だらけの関数等を通して無効化する。
    • 英語ができたほうが良い
    • 最新情報を得る(セキュリティ等)
    • 初級者こそフレームワークを使うべき
  • 3カ月以前の自分のソースコードを恥ずかしく思える様になること。
    • 常に精進しつづけましょう!
  • アイデアをお待ちしております!
  • 苦労した点
    • ロードバランサ
PHPフレームワーク入門
  • 無害化する方法(フレームワークを使わない場合)
    • htmlspecialchars()
    • mysql_real_escape_string()
  • いつも同じようなコードを書いている?
  • 以下のようなコードは…
    • ロジックとデザインがごちゃまぜになったコード
    • ルールが統一されていない
  • サーバを移したら動かなくなった。(PHPの場合)
    • バージョンの違い
    • 設定値の違い
    • ライブラリの不足
  • セキュリティが不安
    • いろいろな攻撃

  • フレームワーク(Framework)
    • 骨組み
    • 土台となるもの
    • 主な役割
      • 標準的な機能の提供
        • ライブラリ
        • ヘルパー関数
          • CakePHPのpr()
            • print_r()の結果を<pre></pre>で囲って出力する
      • MVCモデルの実現
        • Model
        • View
        • Controller
      • MVCモデルのメリット
        • 独立性の確保
          • 機能毎の役割が明確になる
        • 依存性の抑制
        • 保守性の向上
      • ORマッピング
      • ルールの制定
        • 命名規則
          • 変数名、テーブル名
          • ディレクトリ構成
          • コーディングスタイル
    • フレームワークのデメリット
      • 学習コスト
      • どれが良いかわからない
        • 色々なフレームワーク
          • 場合に応じて使い分ける
        • 選定基準
          • 実用性
            • 安定性
            • 機能、対応バージョン
          • 開発の継続性
          • ライセンス
          • 情報の入手しやすさ
    • CodeIgniter
      • 高速
      • 軽量
        • ソースの容量は(展開後で)1.2M
      • 低い学習コスト
      • 日本語のユーザガイドが完備
    • CodeIgniterのURL
      • index.phpがフロントコントローラ
        • URLは、index.php/fuga/piyo/paramなど。
          • class fuga extends CI_Controller {
            • function piyo($param) 
    • 便利な機能
      • active_record
      • form_validation
    • View
      • 共通部分はinclude

セキュリティについて考えてみよう
  • バグ、脆弱性
    • バグとは何か?
      • なるべきものが、そうならない。
    • 脆弱性とは何か?
      • バグと言えばバグ。
      • そのうち、セキュリティに関係するもの
        • 例)脆弱なOSで動作しているサーバがあっても、ファイアウォールで完全に隔離されていれば問題はない。
          • 外部から接続できないので。
      • セキュリティホール、脆弱性はバグの一部。
    • アプリケーションが正常に動作するように作ること。
      • 「一定の定義」に従って正常に動作するのであれば問題ない。
    • リスクを知り、対応する
      • 以下のような問題に対して
        • SQL Injectionでデータを取られた
        • SQL Injectionでページを書き換えられた
      • Webアプリケーションは「最もリスクがあるもの」
        • 全世界に向けて公開する前提だと。
        • 自分のサーバは人気がないから問題ないだろう。
          • クラックする人は、踏み台にするためにサイトの大小に関わらず攻撃してくる!
          • 従って、これは間違い。
    • リスクとは何か?
      • CVEというデータベースがある。
    • 入力、処理、出力
      • エコーバック問題?
      • 9割方、入力と出力の部分で対処がない。
      • 基本的に自分のアプリ以外は全て信用できない前提で考える。
        • 信頼境界線
      • 入力は「全てバリデーション」
        • 「サニタイズ」とは違う
          • ブラックリスト的考え方。(悪いものを弾く)
          • validationはホワイトリスト的考え方。(良いもののみを受け入れる)
      • 処理は「ベストプラクティスに従う」
        • 話をすると長くなるので省略
        • めんどくさい
      • 出力
        • エスケープを理解し、エスケープする
        • ヘルパーを理解し、ヘルパーを使う
          • 属性名をエスケープしないヘルパーがあるので、下手すると、そこがXSSの原因になる可能性も。
        • エスケープもヘルパーも使えないものはバリデーション
        • どうしようもないもの、絶対に安全だとわかっているもの
          • そのまま出力
    • アプリケーションが正しく動作することを担保する
      • 特にセキュリティに特化する場合
        • CIAを保証する
          • Confidential(機密性)
          • Integrity(統合性)
          • Availability(可用性)
      • セキュリティ対策に役立たないセキュリティ対策はない
    • セキュリティ対策とはリスクマネジメント
      • リスクを許容できれば、どんな対策でも構わない。
        • リスクを理解した上で、どこまでリスクを許容できるのか。
        • ただし、他人に迷惑はかけない
      • 例えば、文字エンコーディングのバリデーション
        • 入力時に文字エンコーディングをバリデーションする。
      • 適切な設計も必要
      • どれが優れたセキュリティ対策か?よりも、必要なセキュリティ対策か?が重要