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

1. Railsエンジニアのためのウェブセキュリティ入門 EGセキュアソリューションズ株式会社代表取締役徳丸浩

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. 基本的なこと • Ruby on Railsは基本的な脆弱性（SQLインジェクション、XSS、CSRF 等）はデフォルトで対応している • Ruby on Railsでアプリケーションを開発していて脆弱性になるパターンは以下の通り – Ruby on Railsが対応していない脆弱性 • 実装レベルもの…Railsが対応できない例外的なもの • 設計に依存するものや、脆弱な仕様…これはRailsと言えども救いようがない – Ruby on Railsのルールに従わずに書いた場合 Copyright © 2017-2019 Hiroshi Tokumaru 4

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

18. 正規表現の ^ $ は「行の先頭末尾」を示す • Rubyに限らず、正規表現の ^ と $ は「行の」先頭と末尾 • でも、PHPやPerlでは問題になりにくい – PHPやPerlの場合、データ内の改行を無視して「一行のデータ」として扱う – Rubyの場合、データ内の改行が有効化して、複数行のデータとして扱う • その結果、以下のようになる javascript:alert(1)/* http://example.jp/*/ ← こちらが、 /^http:/// にマッチ Copyright © 2017-2019 Hiroshi Tokumaru 18 行の先頭

25. ここまでのまとめ • マイクロブックマークアプリを作った • Ruby on Railsの機能により、SQLインジェクション対策やHTMLエスケープ処理はなされていた • Javascriptスキームを用いたXSSは対策されていなかった • 正規表現によるバリデーションを追加したが、行頭一致の ^ を使ったために脆弱性が残った • Ruby on Railsのバリデータで ^ $ を使うとエラーになる • ^ の代わりに A を使うと、脆弱性は解消された • 教訓: 自己流でやらずにRailsの流儀に（レールに乗る）従う方が安全性が高い Copyright © 2017-2019 Hiroshi Tokumaru 25

30. Open3#capture3 のマニュアルにOSコマンドインジェクションのヒントが… 30https://docs.ruby-lang.org/ja/latest/method/Open3/m/capture3.html

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. シェルにおける ; の意味は? 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. シェルにおける ; の意味は? 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. 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. 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

37. 37 https://piyolog.hatenadiary.jp/entry/ 20121008/1349660951より引用

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. CSRFはなぜ危険か? • CSRFとは… – FORMのACTIONってクロスドメインで指定できるよね – だから、FORMを踏ませる罠が作れるよね – 投稿、パスワード変更、購入、設定変更… – 攻撃者はFORMの実行結果は見られないので、DB更新や削除などが問題となる • 最悪ケースの危険性は、SQLインジェクションやXSSほどではない • 脆弱性のあるページの機能の悪用にとどまる • 脆弱性の発見が容易 • 脆弱性の悪用が容易 • 実際に悪用されている Copyright © 2017-2019 Hiroshi Tokumaru 39

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

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

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. XSSはなぜ危険か? • XSSは、 – 利用者（被害者）のブラウザ上で – 攻撃対象のドメイン（オリジン）で – 攻撃者が自由にJavaScriptを実行できる • これって、ウイルス? – ウイルスではないが、結果としてウイルスと同じような被害 – XSSを悪用したウイルス（ワーム）はいくつかある • ブラウザを乗っ取られたのと同じ – 影響範囲はXSS脆弱性のあるページと同じドメイン（オリジン） – 同一オリジン上はすべてのページが影響を受ける ※オリジン=ホスト名+スキーム+ポート番号 Copyright © 2017-2019 Hiroshi Tokumaru 46

47. クロスサイトスクリプティングの影響 • 攻撃を受けた人のパソコンが遠隔操作される – なりすまし投稿 – なりすましの買い物 – 情報漏えい • 影響は、脆弱性のあるサイト全体に及びます – 「重要でない」ページに影響があっても、個人情報漏洩なども起こりえる • 他のサイトには直接影響はない • 攻撃を受けた人（サイトを閲覧した人）のみに影響は限られる Copyright © 2017-2019 Hiroshi Tokumaru 47

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. イベントハンドラ動的生成XSSの原理 • onclick="foo('<%= @msg %>')" にて以下を指定 @msg = "');alert('Cracked!')//" • HTMLとしては以下が生成される onclick="foo('');alert('Cracked!')//')" • JavaScript処理系にはHTMLエスケープをデコードしてから渡される foo('');alert('Cracked!')//') Copyright © 2017-2019 Hiroshi Tokumaru 50

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. 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. 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. 対策: 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

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. SQLインジェクションはなぜ危険か? • 攻撃対象サーバーのデータベースについて、攻撃者が自由にSQL呼び出しができる • データベースの中身の漏洩、改ざんが起こる • 脆弱性のあるテーブルだけでなく、データベース内のすべてのデータが漏洩できる。場合によっては改ざんも • 使い勝手の良い攻撃ツール（SQL注入工具:名目は診断ツール）が安価で流通している • SQL注入工具はExcel使うより簡単だよ Copyright © 2017-2019 Hiroshi Tokumaru 58

59. SQLインジェクション対策 • Ruby on Railsの機能を素直に使うこと（原則） • 以下に注意 – whereメソッドはプレースホルダを使う – whereメソッドの式に外部からの値を含めない Book.where("price <= ?", price) – 演算子等はバリデーションか、配列参照で – orderメソッドにも注意（以下のいずれか） • 列名のバリデーション • 列名をシンボルに変換する（シンボルだと列名としてエスケープされる） ※to_symによる対策の妥当性について意見をください! Copyright © 2017-2019 Hiroshi Tokumaru 59

61. 情報漏えい対策、大丈夫？＝専門家「自己防衛を」－宅ふぁいる便の不正アクセス大阪ガス子会社オージス総研（大阪市）が提供するファイル転送サービス「宅ふぁいる便」の会員情報約４８０万人分が、不正アクセス被害を受けて流出した。暗号化されていない状態のパスワードなども含まれることから、同社の情報管理の甘さを指摘する声がある一方、専門家は「パスワードの使い回しをやめるなど自己防衛も心掛けて」と利用者に対しても注意を促している。宅ふぁいる便は、画像や動画などメールで送れない大量データを転送するサービス。無料で利用でき、仕事で使っている人も多いとみられる。退会者を含む会員の名前や生年月日に加え、ログインに必要なメールアドレスやパスワードも流出した。パスワードは暗号化されずに管理されており、ＩＴジャーナリストの三上洋氏は「かなり古い仕組み。ここ１５年くらいで一番ひどい被害だ」と指摘する。 61 https://www.jiji.com/jc/article?k=2019020100206&g=soc より引用

62. 宅ふぁいる便 – パスワードは平文保存だった 62 https://www.filesend.to/faq.html より引用

64. どうして暗号化ではなくてハッシュなの? • 暗号化の場合、鍵の管理が難しい • アプリケーションは鍵を使わなければならないが、攻撃者には鍵を見せたくない • PSNの事件では、権限昇格されたことになっているので、暗号鍵も盗まれていると想定せざるを得ない • ハッシュだと鍵を使わないので、鍵管理のわずらわしさがない • パスワードをサイト管理者にも知られたくないというニーズも – 暗号化されたパスワードだと、サイト管理者やヘルプデスク担当者がパスワードを知り得るのが嫌だ – ヘルプデスクに見せないようにするには、サポート用画面の機能次第で可 – 管理者の悪事は総合的な対策が必要で、パスワードの問題だけではない • PCI-DSS2.0 8.4項には「8.4 強力な暗号化を使用して、すべてのシステムコンポーネントでの伝送および保存中のすべてのパスワードを読み取り不能にする」とあり、ハッシュを求めてはいない © 2016-2018 EG Secure Solutions Inc.

65. ハッシュで保存されたパスワードは本当に安全なの? • 一般的に、（暗号論的）ハッシュ値から平文を「復元する」ことはできない – 「password」のMD5ハッシュ: 5f4dcc3b5aa765d61d8327deb882cf99 • しかし、パスワードの場合は特別な事情がある • 例：4桁の暗証番号をハッシュ値で保存している場合 – 全ての可能性は1万通りしかないのだから、総当たりで確認すれば、平文の暗証番号はすぐに判明する – 参考: https://z.tokumaru.org/2014/02/6php025.html • 原理は8桁パスワードでも同じ • ハッシュ保存の場合、アルゴリズムは攻撃者が知っている前提で安全な設計とする – 平文パスワード以外は、すべて「ばれている」想定を置く • 攻撃者にとって未知であることが保証された情報があれば、それを鍵として暗号化すればよい。現実にはそのような保証がないから暗号化を用いない © 2016-2018 EG Secure Solutions Inc.

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. 25GPUのモンスターマシン（パスワード解析用!） http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用

68. Saltってなに? • ソルト（Salt）とは、ハッシュの元データ（パスワード）に追加する文字列 • ユーザ毎にソルトを変えることで、パスワードが同じでも、異なるハッシュ値が得られる – ソルトがない場合、パスワードの組み合わせ回数分ですむが、ソルトがあると、× ユーザ数に試行回数が増える – LinkedInの場合は、試行回数が 650万倍に ! • ソルトの要件 – ある程度の長さを確保すること – ユーザ毎に異なるものにすること • ソルトには乱数を用いることが多いが、乱数が必須というわけではない • ソルトは秘密情報ではない。ソルトは、通常ハッシュ値と一緒に保存する © 2016-2018 EG Secure Solutions Inc.

69. Stretchingってなに? • ストレッチング（Stretching）とは、ハッシュの計算を繰り返すこと • ハッシュの計算を遅くすることにより、辞書攻撃や総当たり攻撃に対抗する • 1万回ストレッチすると、「 GPUモンスターマシンで20分掛かる」が20万分になる計算 – 20万分 = 139日 … • 「悪い」パスワードまで救えるわけではない – 「password」というパスワードをつけていたら、100万回ストレッチしてもすぐに解読されてしまう • 十分長いパスワードをつけてもらえば、ストレッチングは必要ない – 1文字パスワードを長くすることは、約90回のストレッチングに相当する。パスワードを2文字長くしてもらえば… – ストレッチングは、「弱いパスワード」の救済の意味がある • ストレッチングはメリットとデメリットがあるので、導入の有無と回数をよく検討すること © 2016-2018 EG Secure Solutions Inc.

70. 対策 • Ruby on Railsはパスワードの安全なハッシュ保存機能がある • Rails Tutorialを勉強しましょう…余計なことはしない方が無難です 70 https://railstutorial.jp/chapters/modeling_users?version=5.1#sec-a_hashed_password

73. Ruby や Ruby on Railsの脆弱性も https://gist.github.com/mala/bdcf8681615d9b5ba7814f48dcea8d60 より引用 73

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

76. 76https://railstutorial.jp/

77. 77 https://railsguides.jp/security.html

78. Rails SQL Injection Examples 78 https://rails-sqli.org/

79. 79

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you

More from Hiroshi Tokumaru

Featured

Related Books

Related Audiobooks

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