Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

13,652 views

Published on

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

Published in: Technology
  • Be the first to comment

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

×