システム構築事例の話（…？）
- 突発的なアクセスの増加
- Yahooアタック
- Yahooのトピックスにリンクが付くと…
- 動画への直接リンクはやばい
- PHPを選んだ理由
- 簡単
- みんな使っている
- 自由度が高い
- サーバ設定が簡単
- 速い（？）
- しかし
- コードの統一性がない
- セキュリティが最悪
- フレームワークを活用することにした。
- 開発時間の大幅短縮
- ルールに従うと、コードが統一
- DBとの連携が簡単
- 表示が速い（ページキャッシュ機能）
- PHP勉強法
- 参考までに。
- 目標を作る（アプリを1週間で作る。必ず日程を決めておく事。）
- 入門書とリファレンスブックを購入
- 作りたいものに近いサンプルがある本が良い
- 説明を見ながらとにかく作る
- リファレンスブックを見ながらソースコードを読む
- 自作アプリケーションを作成する。
- オープンソースを解読（バグ情報は便利）
- 参加する
- オープンソースを作る
- 勉強会に参加する
- TIPS
- コードのガイドラインを決める
- コードの最適化
- コード最適化ベストプラクティス
- http://d.hatena.ne.jp/koto2/20080518/1211070116など
- セキュリティに気を使え！
- サニタイズ処理だらけの関数等を通して無効化する。
- 英語ができたほうが良い
- 最新情報を得る（セキュリティ等）
- 初級者こそフレームワークを使うべき
- ３カ月以前の自分のソースコードを恥ずかしく思える様になること。
- 常に精進しつづけましょう！
- アイデアをお待ちしております！
- 苦労した点
- ロードバランサ
- 無害化する方法（フレームワークを使わない場合）
- 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というデータベースがある。
- セキュリティ情報（脆弱性情報）を集めたもの。
- http://cve.mitre.org/
- 入力、処理、出力
- エコーバック問題？
- 9割方、入力と出力の部分で対処がない。
- 基本的に自分のアプリ以外は全て信用できない前提で考える。
- 信頼境界線
- 入力は「全てバリデーション」
- 「サニタイズ」とは違う
- ブラックリスト的考え方。（悪いものを弾く）
- validationはホワイトリスト的考え方。（良いもののみを受け入れる）
- 処理は「ベストプラクティスに従う」
- 話をすると長くなるので省略
- めんどくさい
- 出力
- エスケープを理解し、エスケープする
- ヘルパーを理解し、ヘルパーを使う
- 属性名をエスケープしないヘルパーがあるので、下手すると、そこがXSSの原因になる可能性も。
- エスケープもヘルパーも使えないものはバリデーション
- どうしようもないもの、絶対に安全だとわかっているもの
- そのまま出力
- アプリケーションが正しく動作することを担保する
- 特にセキュリティに特化する場合
- CIAを保証する
- Confidential（機密性）
- Integrity（統合性）
- Availability（可用性）
- セキュリティ対策に役立たないセキュリティ対策はない
- セキュリティ対策とはリスクマネジメント
- リスクを許容できれば、どんな対策でも構わない。
- リスクを理解した上で、どこまでリスクを許容できるのか。
- ただし、他人に迷惑はかけない
- 例えば、文字エンコーディングのバリデーション
- 入力時に文字エンコーディングをバリデーションする。
- 適切な設計も必要
- どれが優れたセキュリティ対策か？よりも、必要なセキュリティ対策か？が重要
0 件のコメント:
コメントを投稿