月別アーカイブ: 2010年9月

セキュリティの勉強してます。(その3)

最近仕事先のセキュリティの試験を受けるために勉強しているので、そのときのメモです。

—————————————–
セキュリティプログラミング
—————————————–

入力値チェックの考え方:
・ユーザの入力値はいっさい信用しない
・ホワイトリスト方式(許可するものだけ通過させる)でチェックする

入力値チェックの対象:
・フォーム入力
・Cookie
・HTTPヘッダ
・セレクトボックスやhiddenタグの内容もチェックする

クライアント側でのチェック:
・通常javascriptが使われる
・サーバや回線への負担が少ないが、ユーザに改ざんされる恐れがある
・信用してはいけない

入力値を出力する際に処理が必要な場面:
・HTMLの特殊処理
・javascriptに出力する場合
・SQL文を生成する場合
・OSコマンドを利用する場合
・URLを生成する場合
・HTTPヘッダを生成する処理
・メールを送信する処理
・ファイル名を生成する処理

HTML内に出力する場合:
・特殊な意味をもつ文字を変換する→<、>、”、&、’の5つ
・変換を怠った場合、XSSなどの攻撃を受ける可能性がある
・ユーザ入力を画面に表示する場合は必ずHTMLエンコードを行う

HTMLタグの属性値として入力値を利用する場合:
・属性値はダブルクォートで括っておく
・入力値内のダブルクォートとHTMLエンコードする

javascriptに入力値を利用する場合:
・出力自体を避ける
・DOMを利用する(ブラウザ側が必要なエンコードを行ってくれる)

SQLに入力値を利用する場合:
・prepared statementを利用する(DBMS側が必要なエンコードを行ってくれる)

OSコマンドに入力値を利用しない:
・動的にコマンドを生成する処理は避ける

URLに入力値を利用する場合:
・URLがhttp://かhttps://で始まっているかチェックする

HTTPヘッダに入力値を利用する場合:
・改行文字を削除する
・エンコードする

メールヘッダに入力値を利用する場合:
・改行文字を削除する
・エンコードする

ファイル名に入力値を利用する場合:
・ファイル名の指定自体をしない
・指定できるファイルを限定する

文字コードの指定:
・ブラウザが認識できる文字コード指定が無い場合、ブラウザが文字コードを誤って認識し、UTF-7を使ったXSSの危険性等がある
・Contentsヘッダ、mimeヘッダの文字コードを必ず指定する

ブラウザが認識できる文字コード:
・HKCR¥Mime¥Database¥Charaset以下にあるもの
・HKEY_CLASSES_ROOT¥Mime¥Database¥Charaset(レジストリ)

マルチバイト文字を使った攻撃:
・入力文字列の文字コードをチェックし、妥当でない場合はエラーとする
・壊れた文字を削除してから使うことは危険
・壊れた文字を削除する性質を持ったモジュールは、コードの妥当性チェックに使える(mb_convert_stringなど)

IEのContent-Type無視問題対策:
・text/plain→HTMLエンコードを行ったHTMLとして表示することで誤認を避けることができる
・BMPファイルをHTMLと誤認する場合がある→画像はBMP以外の形式に変換する

エラーメッセージの抑制:
・エラーメッセージから漏れる情報→モジュールやライブラリの情報、アプリケーションの物理パス、ソースコードやSQLの断片、エラー画面自体に脆弱性のある場合もあり
・エラーメッセージをユーザに見せない→ログに書き出す、デフォルトエラー画面をカスタマイズする

バックドア、デバッグモード:
・不要な機能は削除する
・管理者、開発者のみが利用できるようにする(認証必須)

HTMLページやアプリケーションソース内のコメント:
・攻撃者にとって非常に有効な情報となる場合があるので、必ず削除する

セキュリティの勉強してます。(その2)

最近仕事先のセキュリティの試験を受けるために勉強しているので、そのときのメモです。

—————————————–
セキュリティ設計
—————————————–

認証の実装方法:
・パスワード
・IPアドレス→プロキシは使えない
・SSL証明書→不特定多数向けではない

パスワードの保存:ハッシュ化して保存する。ハッシュ化することで、漏洩時の危険性を回避可能

アカウントロック:総当たり攻撃・辞書攻撃の回避に必要

パスワードリカバリ(秘密の質問など):便利だがセキュリティの強度を下げるので注意が必要

パスワードの発行方法:
・ブラウザに表示するのは危険(パスワードリカバリを悪用された場合など)。
・メールで通知する(この場合もフリーメールのアドレスだと別人に再取得されたりする問題がある。定期的にアカウントをチェックさせたりすることが有効)

セッションに整理番号のようなものを付けることによって、ステートフルのような通信を行うことができる。

セッションの実装方法:
・hidden:最も安全
・cookie:最も一般的、XSS、CSRF対策が必要
・URLに付加:ログやブラウザから漏洩する。携帯のみ。

セッションフィクセーション対策:
・認証が成功してからセッションを開始する

CSRF対策:
・攻撃者が推測できない情報を含める(パスワード、トークン)
・正規の画面遷移を経ているか追跡する、refererをチェックする

特定のユーザーにアクセスさせたい動画、PDF、Flashなども同様の対策が必要

アドレスバー、ステータスバーは表示させる:
・URLや、HTTPSで保護されているかどうかの確認が困難になる
・フィッシングなどの危険性がある

フレームは使用しない:
・表示している画面のURLなどが確認しづらい

HTTPの問題点:
・平文で送信され、途中で改ざんされる恐れがある。
・DNSやhostsファイルが汚染されていた場合に、別のサーバにつながる恐れがある。

HTTPSとは:
・データが暗号化される。
・証明書による認証が行われる
・改ざんを検知することができる

HTTPS使用時の注意点:
・信頼された証明機関の証明書を使用する
・フレームは使用しない
・HTTPと比べてサーバへの負荷が高い

データ送信先だけではなく入力フォームもHTTPSで保護する

低 SSLv2→SSLv3→TLSv1 高
低い暗号強度のものは使わない

リダイレクト:
・リダイレクトされたことが分かる画面を表示して安心感を与える。

リダイレクタの悪用:
・攻撃者が作ったサイトにユーザを誘導する

リダイレクタの設計:
・遷移先を限定する
・URLの変更ができないようにする

データファイル、パスワードファイル:
・データファイル、パスワードファイルはWebサーバのドキュメントルート以外のところにおく
・ディレクトリのパーミッションをWebユーザアプリケーションに限定する
・スクリプトとは別ファイルで管理する

セキュリティの勉強してます。

最近仕事先のセキュリティの試験を受けるために勉強しているので、そのときのメモです。

——————————–
Webに対する攻撃14種
——————————–

■Webアプリケーションに依存しない
・既知の脆弱性
ソフトウェアの既知の脆弱性(セキュリティホール)を攻撃する

・製品の誤設定
HTTPサーバやアプリケーションパッケージの設定みすを攻撃する

・パスワード攻撃
総当りまたは辞書攻撃で有効なパスワードを探し当てる

・バッファオーバーフロー
スクリプトに対して大量の入力データを送信し、誤作動を誘う

■設定や構成の不備
・強制ブラウズ
URLを直接指定して、リンクされていないページを覗く

・情報の意図せざる流出
システムが返すエラーメッセージから、本来公開する必要のない情報が漏洩

・不十分なエラー処理
エラーの処理において、攻撃者に有益な情報が表示される

・バックドアやデバッグモード
裏口やデバッグモードを探し出して不正にそれを使う

■プログラミングの不備
・ステルスコマンド操作(os,sqlインジェクション)
不正なOS、SQLコマンドを実行させる

・クロスサイトスクリプティング
第三者のコードを混入させ、サイトのユーザを攻撃する

・HTTPヘッダインジェクション
HTTPレスポンスを偽造し、サイトのユーザを攻撃する

■設計の不備
・セッションハイジャック/リプレイ
他人が確立しているセッションを奪う、または強制的に再現する

・セッションフィクセーション
攻撃者が指定したセッションIDをWebアプリケーションに使わせる

・クロスサイトリクエストフォージェリー(CSRF)
正規ユーザを誘導し、強制的に特定の処理を実行させる

XP祭り2010 ~ アジャイル学園祭~ 2010/09/04

昨日「XP祭り2010」というイベントに参加して、アジャイル開発に関する話を聞く機会があったので、その時に話を聞きながらつけていたメモを公開させていただきます。聞き違いの部分もあるかもしれませんがその点はご容赦ください。

XP祭り2010は企業などが行うカンファレンスと違い有志の方が行われているイベントだったのですが、来場されている方もとても多く、活気のあるイベントでした。話を聞き終わった後、早速書店でアジャイル開発の本を購入しました。

———————————–
オープニング ~XP入門
———————————–

XP→優れたソフトを開発すること

  ソフト開発の多くはカイゼンである

  人が大切
  最もよい自己になるためのプロセス

焦点
* プログラミング技術
* コミュニケーション
* チームワーク

ニコニコカレンダーもXP

価値とプラクティスの隔たりを埋める

カイゼン:少しずつ良くしていく、できることから良くしていく

紹介されていた書籍:XPエクストリーム・プログラミング入門

———————————–
招待講演 ~アジャイル×テスト開発プロセスを考える
———————————–

コンテキストを意識する
→雑誌や他人のうまく行ったやり方がそのままうまく行くことはない。

※コンテキストとは:デバイスが使われている状況を意味する。例えばある時点で
 デバイスを使用しているユーザーなど。
参考:ウィキペディア

ウォーターフォールかアジャイルかで
品質の有利/不利はない。

ウォーターフォールがうまく行かない原因→人災
 上流工程で矛盾が発生すると、下流工程では直しづらい
 組織・体質的なものもある

目標となる品質:
計画において定義し、共有することが大切

Wモデルに沿って、テストモデルを構築するためのプロセスが必要

※Wモデルとは:
Vモデルの改良版開発モデル。Vモデルの作り込みプロセス(要求定義、要求仕様、アーキテクチャ設計、詳細設計)内で、各プロセスに対応する試験を設計・レビューすることで、素早いフィードバックを得ながら開発を行う。
参考:
http://log2remember.blogspot.com/2009/08/w.html

テスト設計を早期に行うことによって設計のもれなどに気づくことができる

開発にあわせてテストモデルを育てていく、質を上げていく

———————————–
アジャイル開発の現在・過去・未来
~今を知り、源流を訪ね、先を見据える~
———————————–

XP(エクストリーム・プログラミング)→アジャイル

既存のウォーターフォールモデル:
・ITに関わる人はシステムのことだけ考えがち
・システムには使われない機能が多く存在している

ウォーターフォールの欠点:
・開発しているうちに市場のニーズが変化している

アジャイル型開発:
・ビジネスとITが一体化
・戦略を作りながら進む
・短いサイクルで分析、設計、実装、テストを並列に行う
・ホールケーキを小さく切ってショートケーキをいくつか作るのではなく、最初からショートケーキをいくつも作っていくイメージ

アジャイル:本を読んで覚えるのは難しい
      コンテキストが現場によって大きく違う

アジャイルの元になったもの:
・リーン(トヨタシステムが源流)
・スクラム
・XP

アジャイル現状の課題:
・大規模化
・組織改革
・UX(ユーザーエクスペリエンスデザイン:ユーザーがある製品やシステムを使ったときに得られる経験や満足など)

注目を浴びているもの:
・kanban

アジャイルを採用している企業:
・セールスフォース
・富士通
・リクルート
・良品計画

業務とシステムは表裏一体

kanban:アジャイルからのスピンオフ
 説明のできるような形でアジャイルを推進する
 価値を一つずつ後の工程に流していく

kanban:1日で1個完成させることを365日繰り返す 仕掛かり小
ウォーターフォール:365日で1個完成させる 仕掛かり大

kanban→WIPとリードタイムを少なくする

※WIPとは:Work In Progress、仕事・開発の進行状況
※リードタイムとは:作業の着手から終了までに要する時間のこと

アジャイル失敗の原因:経験不足+カルチャー
           経験者がいた方が良い

アジャイルでよく使われるツール:エクセル

スクラム方式で実践しているところが一番多い

スクラム憲章、アジャイル宣言というものがある

紹介されていた書籍:アート・オブ・ディベロプメント

アジャイルは海外ではとても活気がある