Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Railsエンジニアのためのウェブセキュリティ入門

14.604 visualizaciones

Publicado el

銀座Rails#8 における講演資料 #ginzarails
https://ginza-rails.connpass.com/event/121889/

Publicado en: Tecnología
  • Sé el primero en comentar

Railsエンジニアのためのウェブセキュリティ入門

  1. 1. Railsエンジニアのためのウェブセキュリティ入門 EGセキュアソリューションズ株式会社 代表取締役 徳丸 浩
  2. 2. アジェンダ • 3分間クッキングデモ • OSコマンドインジェクション • クロスサイトリクエストフォージェリ(CSRF) • クロスサイトスクリプティング(XSS) • SQLインジェクション • パスワードの保護 • プラットフォームの脆弱性対応 • 参考文献 Copyright © 2017-2019 Hiroshi Tokumaru 2
  3. 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – EGセキュアソリューションズ株式会社 代表 https://www.eg-secure.co.jp/ – 独立行政法人情報処理推進機構 非常勤研究員 https://www.ipa.go.jp/security/ – 著書「体系的に学ぶ 安全なWebアプリケーションの作り方」(2011年3月) 同 第2版が 2018年6月21日発売 「徳丸浩のWebセキュリティ教室 」(2015年10月) – 技術士(情報工学部門) Copyright © 2017-2019 Hiroshi Tokumaru 3
  4. 4. 基本的なこと • Ruby on Railsは基本的な脆弱性(SQLインジェクション、XSS、CSRF 等)はデフォルトで対応している • Ruby on Railsでアプリケーションを開発していて脆弱性になるパター ンは以下の通り – Ruby on Railsが対応していない脆弱性 • 実装レベルもの…Railsが対応できない例外的なもの • 設計に依存するものや、脆弱な仕様…これはRailsと言えども救いようがない – Ruby on Railsのルールに従わずに書いた場合 Copyright © 2017-2019 Hiroshi Tokumaru 4
  5. 5. 3分間クッキングデモ • 極小のブックマークアプリを作ります $ rails new bookmark_app $ cd bookmark_app $ rails generate scaffold bookmark site:string url:string $ rails db:migrate • Viewを修正して、リンク表示になるよう link_to メソッドを使う Copyright © 2017-2019 Hiroshi Tokumaru 5
  6. 6. 作ったアプリを脆弱性診断してみましょう! Copyright © 2017-2019 Hiroshi Tokumaru 6
  7. 7. クロスサイトスクリプティング検査をしてみる Copyright © 2017-2019 Hiroshi Tokumaru 7 <a href="http://&quot;&gt;&lt;script&gt;alert(1)&lt;/script&gt;"> &quot;&gt;&lt;script&gt;alert(1)&lt;/script&gt;</a>
  8. 8. よさそうじゃないですか! Copyright © 2017-2019 Hiroshi Tokumaru 8
  9. 9. でも、抜けがあります Copyright © 2017-2019 Hiroshi Tokumaru 9
  10. 10. JavaScriptスキームによるXSSは可能 Copyright © 2017-2019 Hiroshi Tokumaru 10 <a href="javascript:alert(1)">xss</a>
  11. 11. バリデーションで対処してみましょう Copyright © 2017-2019 Hiroshi Tokumaru 11
  12. 12. バリデーションをコントローラに追加 Copyright © 2017-2019 Hiroshi Tokumaru 12
  13. 13. バリデーションでXSSを防ぐ Copyright © 2017-2019 Hiroshi Tokumaru 13
  14. 14. よさそうじゃないですか! Copyright © 2017-2019 Hiroshi Tokumaru 14
  15. 15. でもだめです Copyright © 2017-2019 Hiroshi Tokumaru 15
  16. 16. バリデーションを突破するパターン Copyright © 2017-2019 Hiroshi Tokumaru 16 javascript:alert(1)/* 【改行】 http://example.jp/*/
  17. 17. なぜ駄目なのか? Copyright © 2017-2019 Hiroshi Tokumaru 17
  18. 18. 正規表現の ^ $ は「行の先頭末尾」を示す • Rubyに限らず、正規表現の ^ と $ は「行の」先頭と末尾 • でも、PHPやPerlでは問題になりにくい – PHPやPerlの場合、データ内の改行を無視して「一行のデータ」として扱う – Rubyの場合、データ内の改行が有効化して、複数行のデータとして扱う • その結果、以下のようになる javascript:alert(1)/* http://example.jp/*/ ← こちらが、 /^http:/// にマッチ Copyright © 2017-2019 Hiroshi Tokumaru 18 行の先頭
  19. 19. でも、そもそもコントローラに独自バリデー タを実装するのはよくないよね Copyright © 2017-2019 Hiroshi Tokumaru 19
  20. 20. Railsの機能でモデルにバリデータを書こう Copyright © 2017-2019 Hiroshi Tokumaru 20
  21. 21. モデルにバリデータを記述 Copyright © 2017-2019 Hiroshi Tokumaru 21
  22. 22. 以下のエラーが表示される Copyright © 2017-2019 Hiroshi Tokumaru 22 この正規表現は複数行のアンカー(^または$)を使用 しているため、セキュリティ上のリスクが生じる可能性 がある。 Aと zを使うつもりだったか、または :multiline => trueオプションを追加するのを忘れた か?
  23. 23. エラーメッセージに従い、^ を A に修正し ましょう Copyright © 2017-2019 Hiroshi Tokumaru 23
  24. 24. 今度は大丈夫 Copyright © 2017-2019 Hiroshi Tokumaru 24
  25. 25. ここまでのまとめ • マイクロブックマークアプリを作った • Ruby on Railsの機能により、SQLインジェクション対策やHTMLエス ケープ処理はなされていた • Javascriptスキームを用いたXSSは対策されていなかった • 正規表現によるバリデーションを追加したが、行頭一致の ^ を使った ために脆弱性が残った • Ruby on Railsのバリデータで ^ $ を使うとエラーになる • ^ の代わりに A を使うと、脆弱性は解消された • 教訓: 自己流でやらずにRailsの流儀に(レールに乗る)従う方が安全 性が高い Copyright © 2017-2019 Hiroshi Tokumaru 25
  26. 26. ウェブアプリケーションセキュリティ入門 Copyright © 2017-2019 Hiroshi Tokumaru 26
  27. 27. 本日使用する脆弱なアプリケーション Copyright © 2017-2019 Hiroshi Tokumaru 27 山田 祥寛 (著) Ruby on Rails 5 アプリケーションプログラミング 技術評論社 (2017/4)と Rails Tutorialのサンプルに 脆弱性を加えましたw ※オリジナルに脆弱性があるわけではありません
  28. 28. OSコマンドインジェクション Copyright © 2017-2019 Hiroshi Tokumaru 28
  29. 29. OSコマンドインジェクションとは何か? • シェル(/bin/sh)呼び出し可能な機能を悪用して 攻撃者が勝手にコマンドをサーバー上で 実行できる脆弱性 Copyright © 2017-2019 Hiroshi Tokumaru 29
  30. 30. Open3#capture3 のマニュアルにOSコマンドインジェクションのヒントが… 30https://docs.ruby-lang.org/ja/latest/method/Open3/m/capture3.html
  31. 31. シェルにおける ; の意味は? Copyright © 2017-2019 Hiroshi Tokumaru 31 Open3.capture3("echo a; sort >&2", :stdin_data=>"foo¥nbar¥nbaz¥n") ; sort は echo コマンドに続けてsort コマンドを実行するという意味 Open3.capture3("cmd #{params[:p]}", :stdin_data=>"foo¥nbar¥nbaz¥n") params[:p] に ; xxx を入れたら、xxxコマンドが実行できる
  32. 32. シェルにおける ; の意味は? Copyright © 2017-2019 Hiroshi Tokumaru 32 Open3.capture3("echo a; sort >&2", :stdin_data=>"foo¥nbar¥nbaz¥n") ; sort は echo コマンドに続けてsort コマンドを実行するという意味 Open3.capture3("cmd #{params[:p]}", :stdin_data=>"foo¥nbar¥nbaz¥n") params[:p] に ; xxx を入れたら、xxxコマンドが実行できる Open3.capture3("echo a; sort >&2 "
  33. 33. シェルにおける ; の意味は? Copyright © 2017-2019 Hiroshi Tokumaru 33 Open3.capture3("echo a; sort >&2", :stdin_data=>"foo¥nbar¥nbaz¥n") ; sort は echo コマンドに続けてsort コマンドを実行するという意味 Open3.capture3("cmd #{params[:p]}", :stdin_data=>"foo¥nbar¥nbaz¥n") params[:p] に ; xxx を入れたら、xxxコマンドが実行できる Open3.capture3("echo a; sort >&2 "#{params[:p]} ここを変数にすると OSコマンドインジェクション脆弱性
  34. 34. OSコマンドインジェクションの原理 • 以下の脆弱なスクリプト system("/usr/sbin/sendmail <mail.txt #{mail}"); • mail として下記を設定する場合 mail = 'a@example.jp; cat /etc/passwd'; • 実行されるコマンドは下記となる /usr/sbin/sendmail <mail.txt a@example.jp; cat /etc/passwd • セミコロン「;」は二つ以上のコマンドを続けて実行するとい う意味なので、sendmailに続いて、 cat /etc/passwdが実行されてしまう Copyright © 2017-2019 Hiroshi Tokumaru 34
  35. 35. OSコマンドインジェクションの影響と対策 • 影響 – 任意のコマンドが実行されてしまうので影響は非常に大きい – wgetコマンド等を利用して攻撃スクリプトを外部からダウロードされる – 外部からは攻撃できないが、内部からは攻撃できる脆弱性による権限昇格(Local Exploit) → root 権限の奪取 – ファイルの更新(改ざん)、削除、作成 – システムの停止 – 外部のサーバーに対する攻撃(踏み台) • 対策:以下のいずれかを実施する – 外部コマンドを起動する実装を避ける – シェルの呼び出し機能のある関数を避ける Open3.capture3(‘command’, parameter, …) # コマンドとパラメータを分離する Kernel#open() や File.read() (Ruby 2.6未満)はパイプ記号でコマンドを起動できる 例: File.read("|cat /etc/passwd") – 外部からのパラメータをコマンドラインに渡さない 例: sendmailコマンドの –t オプション 35Copyright © 2017-2019 Hiroshi Tokumaru
  36. 36. クロスサイト・リクエストフォージェリ(CSRF) Copyright © 2017-2019 Hiroshi Tokumaru 36
  37. 37. 37 https://piyolog.hatenadiary.jp/entry/ 20121008/1349660951より引用
  38. 38. クロスサイト・リクエストフォージェリの原理 Copyright © 2017-2019 Hiroshi Tokumaru 38 POST /45/45-003.php HTTP/1.1 Referer: http://example.jp/45/45-002.php Content-Type: application/x-www-form-urlencoded Host: example.jp Cookie: PHPSESSID=isdv0mecsobejf2oalnuf0r1l2 Content-Length: 9 pwd=pass1 POST /45/45-003.php HTTP/1.1 Referer: http://trap.example.com/45/45-900.html Content-Type: application/x-www-form-urlencoded Host: example.jp Cookie: PHPSESSID=isdv0mecsobejf2oalnuf0r1l2 Content-Length: 9 pwd=pass1 正常系のHTTPリクエスト CSRF攻撃時のHTTPリクエスト Referer 以外は変 わらない
  39. 39. CSRFはなぜ危険か? • CSRFとは… – FORMのACTIONってクロスドメインで指定できるよね – だから、FORMを踏ませる罠が作れるよね – 投稿、パスワード変更、購入、設定変更… – 攻撃者はFORMの実行結果は見られないので、DB更新や削除などが問題となる • 最悪ケースの危険性は、SQLインジェクションやXSSほどではない • 脆弱性のあるページの機能の悪用にとどまる • 脆弱性の発見が容易 • 脆弱性の悪用が容易 • 実際に悪用されている Copyright © 2017-2019 Hiroshi Tokumaru 39
  40. 40. CSRF対策の方法は? • Ruby on RailsはGET以外のリクエスト全てにトークンを要求する • 素直にRuby on Railsを使う限り、CSRF脆弱にする方が難しいw • 脆弱性が混入する主なパターン – トークンのチェックを無効化してしまった – Railsの流儀に従わずに処理を書いた(例: GETメソッドで更新処理を受け取る) – わざとCSRFチェックを無効化する protect_from_forgery :except => :create # デモを見よう Copyright © 2017-2019 Hiroshi Tokumaru 40
  41. 41. クロスサイト・スクリプティング(XSS) Copyright © 2017-2019 Hiroshi Tokumaru 41
  42. 42. クロスサイトスクリプティング(XSS)とは何か? • クロスサイトスクリプティング(XSS)は、 攻撃者が、攻撃対象のページに JavaScriptを勝手に埋め込める脆弱性 Copyright © 2017-2019 Hiroshi Tokumaru 42
  43. 43. Ruby on RailsでXSS脆弱にする方法 • 3分間クッキングで説明したように、基本的にRuby on Railsで開発し たアプリケーションはXSS対策がなされている – …が、例外もある – URLを指定する href 属性や src 属性に javascript: スキームを入力する – その他、後述の状況 • 以下を使えば、HTMLエスケープされないのでXSS脆弱になる – <%== 文字列 %> – <% raw 文字列 %> – <% 文字列.html_safe %> Copyright © 2017-2019 Hiroshi Tokumaru 43
  44. 44. Demo Copyright © 2017-2019 Hiroshi Tokumaru 44
  45. 45. XSSのデモ • 先ほどのCSRF対策済みの掲示板でなりすまし書き込みをやってみよう • 実行するスクリプトは下記のもの Copyright © 2017-2019 Hiroshi Tokumaru 45 var s = document.body.innerHTML; if (s.indexOf('<h1>徳丸' + '浩</h1>') >= 0 && s.indexOf('〇〇小学校を襲撃して' + '皆殺しにしてやる') < 0) { var token = document.getElementsByName('authenticity_token')[0].value; var req = new XMLHttpRequest(); req.open('POST', '/microposts'); req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); data = 'utf8=%E2%9C%93&commit=Post&micropost%5Bpicture%5D=&micropost%5Bcon tent%5D=〇〇小学校を襲撃して' + '皆殺しにしてやる&authenticity_token='+encodeURICo mponent(token); req.send(data); }
  46. 46. XSSはなぜ危険か? • XSSは、 – 利用者(被害者)のブラウザ上で – 攻撃対象のドメイン(オリジン)で – 攻撃者が自由にJavaScriptを実行できる • これって、ウイルス? – ウイルスではないが、結果としてウイルスと同じような被害 – XSSを悪用したウイルス(ワーム)はいくつかある • ブラウザを乗っ取られたのと同じ – 影響範囲はXSS脆弱性のあるページと同じドメイン(オリジン) – 同一オリジン上はすべてのページが影響を受ける ※オリジン=ホスト名+スキーム+ポート番号 Copyright © 2017-2019 Hiroshi Tokumaru 46
  47. 47. クロスサイトスクリプティングの影響 • 攻撃を受けた人のパソコンが遠隔操作される – なりすまし投稿 – なりすましの買い物 – 情報漏えい • 影響は、脆弱性のあるサイト全体に及びます – 「重要でない」ページに影響があっても、個人情報漏洩なども起こりえる • 他のサイトには直接影響はない • 攻撃を受けた人(サイトを閲覧した人)のみに影響は限られる Copyright © 2017-2019 Hiroshi Tokumaru 47
  48. 48. XSSの対策 • 基本的にRuby on Railsの流儀に従えば大半の箇所を対策してくれる • 以下に注意 – src属性、href属性等URLを受け取る属性 → URLのバリデーション – JavaScriptの動的生成(とくに文字列リテラル) – DOM Based XSS Copyright © 2017-2019 Hiroshi Tokumaru 48
  49. 49. JavaScript(イベントハンドラ)を一部動的生成 Copyright © 2017-2019 Hiroshi Tokumaru 49 ボタンを押してください <input type="button" value="Go" onclick="foo('<%= @msg %>')"> <p id="msg"></p> <script> function foo(msg) { $('#msg').text(msg); } </script>
  50. 50. イベントハンドラ動的生成XSSの原理 • onclick="foo('<%= @msg %>')" にて以下を指定 @msg = "');alert('Cracked!')//" • HTMLとしては以下が生成される onclick="foo('');alert('Cracked!')//')" • JavaScript処理系にはHTMLエスケープをデコードしてから渡される foo('');alert('Cracked!')//') Copyright © 2017-2019 Hiroshi Tokumaru 50
  51. 51. イベントハンドラ動的生成XSSの対策 • 原因 – イベントハンドラ内の文字列リテラルは、JavaSriptとしてのエスケープをして からHTMLエスケープしなければならないが、JavaScriptとしてのエスケープが 抜けている • 対策(以下のいずれか) – JavaScriptの動的生成をせずに、カスタムデータ属性経由にパラメータを渡す <div id="main" data-msg="<%= @msg %>"> <!-- データ定義 --> $('#msg').text($('#main').data('msg')); // データ参照 – JSON形式でデータを渡す onclick="foo(<%= @msg.to_json %>)" <!-- クォートしない --> Copyright © 2017-2019 Hiroshi Tokumaru 51
  52. 52. Dom Based XSS Copyright © 2017-2019 Hiroshi Tokumaru 52 <body> <script> window.addEventListener("hashchange", chghash, false); window.addEventListener("load", chghash, false); function chghash() { var hash = decodeURIComponent(window.location.hash.slice(1)); var color = document.getElementById("color"); color.innerHTML = hash; } </script> <a href="#赤">赤</a> <a href="#緑">緑</a> <a href="#青">青</a> <p id="color"></p> </body> 脆弱な例: フラグメント識別子を表示するだけのスクリプト
  53. 53. DOM Based XSSの攻撃例 • Script要素による攻撃は有効にならない <script>alert(1)</script> など • img 要素のonerror属性などは攻撃に使える <img src=# onerror=alert(1)> • 上記を含むHTMLをinnerHTMLに挿入すると、JavaScriptが実行される • document.writeであれば、script要素でも攻撃可能 Copyright © 2017-2019 Hiroshi Tokumaru 53
  54. 54. 対策: Dom Based XSS • 『DOM Based XSS』に関するレポート に詳しい • document.writeやinnerHTMLの使用を避ける • DOM操作APIを用いる or 適切なエスケープ処理 • jQueryを用いる場合は html()メソッドではなく、text()メソッドを用いる function chghash() { var hash = window.location.hash; var color = document.getElementById("color"); // color.innerHTML = decodeURIComponent(window.location.hash.slice(1)); // 脆弱 color.textContent = decodeURIComponent(window.location.hash.slice(1)); // 対策 } Copyright © 2017-2019 Hiroshi Tokumaru 54
  55. 55. SQLインジェクション Copyright © 2017-2019 Hiroshi Tokumaru 55
  56. 56. SQLインジェクションとは何か? • 攻撃者が ウェブアプリケーションが利用するSQL文の意味を変更したり 追加のSQL文を勝手に実行できる脆弱性 Copyright © 2017-2019 Hiroshi Tokumaru 56
  57. 57. 脆弱なスクリプト例 • Ruby on Ralisを正しく使っていればSQLインジェクションは防げる • だめな例1 whereメソッドの引数に値を埋め込んでいる – @books = Book.where("price >= #{params[:price]}") • だめな例2 演算子として外部パラメータを埋め込み – @books = Book.where("price #{params[:op]} ?“, params[:price]) • だめな例3 orderメソッドに外部パラメータを指定 – @books = order ? Book.order(params[:order]) Copyright © 2017-2019 Hiroshi Tokumaru 57 Demo
  58. 58. SQLインジェクションはなぜ危険か? • 攻撃対象サーバーのデータベースについて、攻撃者が自由にSQL呼び 出しができる • データベースの中身の漏洩、改ざんが起こる • 脆弱性のあるテーブルだけでなく、データベース内のすべてのデータ が漏洩できる。場合によっては改ざんも • 使い勝手の良い攻撃ツール(SQL注入工具:名目は診断ツール)が安価 で流通している • SQL注入工具はExcel使うより簡単だよ Copyright © 2017-2019 Hiroshi Tokumaru 58
  59. 59. SQLインジェクション対策 • Ruby on Railsの機能を素直に使うこと(原則) • 以下に注意 – whereメソッドはプレースホルダを使う – whereメソッドの式に外部からの値を含めない Book.where("price <= ?", price) – 演算子等はバリデーションか、配列参照で – orderメソッドにも注意(以下のいずれか) • 列名のバリデーション • 列名をシンボルに変換する(シンボルだと列名としてエスケープされる) ※to_symによる対策の妥当性について意見をください! Copyright © 2017-2019 Hiroshi Tokumaru 59
  60. 60. パスワードの保存 Copyright © 2017-2019 Hiroshi Tokumaru 60
  61. 61. 情報漏えい対策、大丈夫?=専門家「自己防衛を」-宅ふぁいる便の不正アクセス 大阪ガス子会社オージス総研(大阪市)が提供するファイル転送サー ビス「宅ふぁいる便」の会員情報約480万人分が、不正アクセス被害 を受けて流出した。暗号化されていない状態のパスワードなども含まれ ることから、同社の情報管理の甘さを指摘する声がある一方、専門家は 「パスワードの使い回しをやめるなど自己防衛も心掛けて」と利用者に 対しても注意を促している。 宅ふぁいる便は、画像や動画などメールで送れない大量データを転送 するサービス。無料で利用でき、仕事で使っている人も多いとみられる。 退会者を含む会員の名前や生年月日に加え、ログインに必要なメール アドレスやパスワードも流出した。パスワードは暗号化されずに管理さ れており、ITジャーナリストの三上洋氏は「かなり古い仕組み。ここ 15年くらいで一番ひどい被害だ」と指摘する。 61 https://www.jiji.com/jc/article?k=2019020100206&g=soc より引用
  62. 62. 宅ふぁいる便 – パスワードは平文保存だった 62 https://www.filesend.to/faq.html より引用
  63. 63. パスワードリスト攻撃の脅威 63Copyright © 2017-2019 Hiroshi Tokumaru
  64. 64. どうして暗号化ではなくてハッシュなの? • 暗号化の場合、鍵の管理が難しい • アプリケーションは鍵を使わなければならないが、攻撃者には鍵を見せたくない • PSNの事件では、権限昇格されたことになっているので、暗号鍵も盗まれている と想定せざるを得ない • ハッシュだと鍵を使わないので、鍵管理のわずらわしさがない • パスワードをサイト管理者にも知られたくないというニーズも – 暗号化されたパスワードだと、サイト管理者やヘルプデスク担当者がパスワードを知り得るの が嫌だ – ヘルプデスクに見せないようにするには、サポート用画面の機能次第で可 – 管理者の悪事は総合的な対策が必要で、パスワードの問題だけではない • PCI-DSS2.0 8.4項には「8.4 強力な暗号化を使用して、すべてのシステムコンポー ネントでの伝送および保存中のすべてのパスワードを読み取り不能にする」とあ り、ハッシュを求めてはいない © 2016-2018 EG Secure Solutions Inc.
  65. 65. ハッシュで保存されたパスワードは本当に安全なの? • 一般的に、(暗号論的)ハッシュ値から平文を「復元する」ことはできない – 「password」のMD5ハッシュ: 5f4dcc3b5aa765d61d8327deb882cf99 • しかし、パスワードの場合は特別な事情がある • 例:4桁の暗証番号をハッシュ値で保存している場合 – 全ての可能性は1万通りしかないのだから、総当たりで確認すれば、平文の暗証番号はすぐに 判明する – 参考: https://z.tokumaru.org/2014/02/6php025.html • 原理は8桁パスワードでも同じ • ハッシュ保存の場合、アルゴリズムは攻撃者が知っている前提で安全な設計とす る – 平文パスワード以外は、すべて「ばれている」想定を置く • 攻撃者にとって未知であることが保証された情報があれば、それを鍵として暗号 化すればよい。現実にはそのような保証がないから暗号化を用いない © 2016-2018 EG Secure Solutions Inc.
  66. 66. 650万件のパスワードハッシュのうち540万件が1週間で解読 http://securitynirvana.blogspot.jp/2012/06/final- word-on-linkedin-leak.html より引用 https://twitter.com/jmgosney/statuses/213212108924522496 より引用 Surviving on little more than furious passion for many sleepless days, we now have over 90% of the leaked passwords recovered.
  67. 67. 25GPUのモンスターマシン(パスワード解析用!) http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用
  68. 68. Saltってなに? • ソルト(Salt)とは、ハッシュの元データ(パスワード)に追加する文字列 • ユーザ毎にソルトを変えることで、パスワードが同じでも、異なるハッ シュ値が得られる – ソルトがない場合、パスワードの組み合わせ回数分ですむが、ソルトがあると、× ユーザ数 に試行回数が増える – LinkedInの場合は、試行回数が 650万倍に ! • ソルトの要件 – ある程度の長さを確保すること – ユーザ毎に異なるものにすること • ソルトには乱数を用いることが多いが、乱数が必須というわけではない • ソルトは秘密情報ではない。ソルトは、通常ハッシュ値と一緒に保存する © 2016-2018 EG Secure Solutions Inc.
  69. 69. Stretchingってなに? • ストレッチング(Stretching)とは、ハッシュの計算を繰り返すこと • ハッシュの計算を遅くすることにより、辞書攻撃や総当たり攻撃に対抗する • 1万回ストレッチすると、「 GPUモンスターマシンで20分掛かる」が20万分にな る計算 – 20万分 = 139日 … • 「悪い」パスワードまで救えるわけではない – 「password」というパスワードをつけていたら、100万回ストレッチしてもすぐに解読されて しまう • 十分長いパスワードをつけてもらえば、ストレッチングは必要ない – 1文字パスワードを長くすることは、約90回のストレッチングに相当する。パスワードを2文字 長くしてもらえば… – ストレッチングは、「弱いパスワード」の救済の意味がある • ストレッチングはメリットとデメリットがあるので、導入の有無と回数をよく検 討すること © 2016-2018 EG Secure Solutions Inc.
  70. 70. 対策 • Ruby on Railsはパスワードの安全なハッシュ保存機能がある • Rails Tutorialを勉強しましょう…余計なことはしない方が無難です 70 https://railstutorial.jp/chapters/modeling_users?version=5.1#sec-a_hashed_password
  71. 71. プラットフォームの脆弱性対応 Copyright © 2017-2019 Hiroshi Tokumaru 71
  72. 72. OS(Linux等)のパッチ適用を忘れずに Copyright © 2017-2019 Hiroshi Tokumaru 72 181 packages can be updated. 99 updates are security updates.
  73. 73. Ruby や Ruby on Railsの脆弱性も https://gist.github.com/mala/bdcf8681615d9b5ba7814f48dcea8d60 より引用 73
  74. 74. プラットフォームの脆弱性対応 • 使用ソフトウェアのサポートライフサイクルポリシーを確認する – 例: RHEL/CentOSは10年サポート、Debian/Ubuntu(LTS)は5年サポート – CentOS6 : 2020年11月30日まで – CentOS7 : 2024年6月30日まで • OSのアップデート $ sudo yum update # or yum upgrade $ sudo apt upgrade • Ruby on Railsのアップデート $ sudo bundle update Copyright © 2017-2019 Hiroshi Tokumaru 74
  75. 75. 参考資料 Copyright © 2017-2019 Hiroshi Tokumaru 75
  76. 76. 76https://railstutorial.jp/
  77. 77. 77 https://railsguides.jp/security.html
  78. 78. Rails SQL Injection Examples 78 https://rails-sqli.org/
  79. 79. 79

×