log

安全なwebアプリケーションの作り方 119-157

あとで調べる
  • SQLインジェクション
    • SQLの呼び出し方がヤバイと起こる
    • 行動者が能動的にサーバーを攻撃出来る
      • DB内の情報を盗める
      • 内容書き換えができる
      • 認証回避
      • ファイルR/W/run
    • 影響が大きすぎるので、絶対に起こらないコーディングをする。確実な対策は、「静的プレースホルダを利用してSQLを呼び出す」こと。
    • 些細な情報に対するSQL呼び出しに脆弱性があって、DBの任意の情報が取れるから、ヤバイ
    • エラーメッセージの内部エラー情報をそのまま表示するのもヤバイからちゃんと隠す（前もやったね）
    • UNION SELECT を使った攻撃
      • UNION SELECT：2つのSQL文の和集合を求める
      • union select id, pwd, name, … from users みたいなことが出来るから、一度で大量の情報が漏れる
    • 認証回避
      • よくあるBasic認証のやつで、パスワード欄に’ or ‘a’ = ‘aって入れると、SELECT * FROM users WHERE id = ‘yamada’ AND pwd =‘’ OR ‘a’=‘a’ みたいな感じになってWHEREが常に成立し、ログイン出来てヤバイ
    • データ改ざん
      • update なんたらかんたら — で改ざんできる。-- 以降はコメントなので、無視されるからやばい
      • HTMLタグが有効になるので、iframeとかscript埋め込めるから、マルウェア感染させられたりしてやばい。
    • ほかにも OSコマンドの実行/ファイルの読み書き/他サーバの攻撃が出来る場合がある
    • DB内にどんな表や列があるかは、INFORMATION_SCHEMAの中のtablesやcolumnsで見られる

SQL中に、後に可変値を埋め込みたい場所を「$1」「$2」あるいは「?」などの特別な文字列、すなわちプレースホルダで確保しておき、ここに埋め込む値はSQL本体とは分離して渡す、というのが根本的な考え方です。これらを別々に渡すことで、SQLサーバは、パラメータの内容はあくまでも「値」として解釈し、たとえその値にSQLとして解釈できる文字列が記述されていても、それをSQLとして実行することはしない、という仕組みです。

指定されたエンコーディングへの変換の前にエスケープ処理を行っており、適切なエスケープ処理ができていなかった。
⇒その結果、エスケープ処理をバイパスしてSQLインジェクションが成立する形になっていた。

  • ワイルドカード文字のエスケープを怠る != SQLインジェクション
  • p.135のサンプルコードの意味がわからん
  • SQLインジェクションの保険的対策
    • 万が一なんか起きた時、被害を軽減するときのためのやつ
    • 詳細なエラーメッセージを表示しない（前もやった！）/入力値の検証（前もやった！）/DBの権限設定
    • DBの権限：最低限のアクセスだけ許可する！
  • プレースホルダが使えないけど対策したいとき
    • 記号文字のエスケープ：quoteメソッドとかがある
    • 数値リテラルは数値以外の文字を入れない：キャストor正規表現
  • 重要な処理（クレカとかログインとかメールとか）にある脆弱性：Cross-Site Request Forgeries; CSRF
  • 利用者の意図したリクエストか確認しないと、物品購入/退会/書き込み/id, pass変更などの影響がある
  • この脆弱性では情報盗むことは出来ない。でもやばいから、利用者の意図したリクエストか確認する！
  • 攻撃の手法としては、iframe のXSSと似た感じ、罠サイト用意して通信する感じだけど、CSRFと反射型XSSは途中から違う。HTMLの改変、スクリプト実行がXSSで、不正操作するのがCSRF
  • XSSはブラウザ上で出来ることはなんでもできるから（ん？）、これのほうが脅威大きいんだけど、CSRFは設計段階で対策する必要がある/認知度が低いから対策進んでないのでちゃんと気をつけよう！
  • 確認画面から実行画面の間にクッションがあっても、hiddenパラメータとかセッション変数とかで攻撃出来る
  • iframe を2つ使って、時間差で呼び出したりしてPOST→セッション変数に保存みたいなことが出来る。原理的にはどれだけ多段でもiframe増やせば攻撃出来る🙆
  • CSRF脆弱性が生まれる原因：form > action にはどのドメインでもOK/クッキーに保存されたセッションIDは対象サイトに自動的に送信される
    • ふつうのとCSRF攻撃のリクエストではRefererだけが違ったりするんだけど、気をつけない限りチェックしないから脆弱性が生まれる👶
    • 🍪以外にも自動で送信されるパラメータを使ってセッション管理してるサイトはヤバイ。HTTP/SSLクライアント/携帯ID認証使ってるところもヤバイ🙅
  • 対策：CSRF対策の必要なページを区別する
    • 購入ページ、パス変更、個人情報変更するところとか
  • 意図したリクエストかチェックする
    • トークンの埋め込み：実行ページの直前に！POSTじゃないとダメ！
    • パス確認：最終実行ページで！意思を念押し確認！正規利用者か確認！
    • Refererチェック：送信しない設定してるとダメ！漏れとかもある！前方一致検索で絶対URLをチェック、スラッシュのあとも確認！でも他に比べて実装が楽だから、社内システムとかはこれでもいいかも〜
  • CSRFへの保険的対策
    • 「重要な処理」実行後に、利用者に通知メール送る。でもこれ来るのめんどいよね、わかるけど
    • XSSでなりすまされたときも気づけるからメリット大きい
    • メールは平文で送るから、ヤバイ情報載せちゃダメー🙅　詳細見せたかったらログイン必要なページでするべき
  • ログイン後のCSRF対策はしてるけど、ログイン前はどうしてるの？？？あとで調べる　thanks
  • ログイン機能がない掲示板で自分が意図してない書き込みを、URL踏むだけでされるのは嫌だよね？