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

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

徳丸浩の自己紹介 • 経歴 – 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

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

http://example.jp/*/

17.

18.

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

19.

20.

21.

22.

23.

24.

25.

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

26.

27.

28.

29.

30.

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

https://docs.ruby-lang.org/ja/latest/method/Open3/m/capture3.html

31.

[beta]

シェルにおける ; の意味は?
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コマンドが実行できる

Copyright © 2017-2019 Hiroshi Tokumaru

31

32.

[beta]

シェルにおける ; の意味は?
Open3.capture3("echo a; sort >&2", :stdin_data=>"foo¥nbar¥nbaz¥n")
; sort は echo コマンドに続けてsort コマンドを実行するという意味

Open3.capture3("echo a; sort >&2

"

Open3.capture3("cmd #{params[:p]}", :stdin_data=>"foo¥nbar¥nbaz¥n")
params[:p] に ; xxx を入れたら、xxxコマンドが実行できる

Copyright © 2017-2019 Hiroshi Tokumaru

32

33.

[beta]

シェルにおける ; の意味は?
Open3.capture3("echo a; sort >&2", :stdin_data=>"foo¥nbar¥nbaz¥n")
; sort は echo コマンドに続けてsort コマンドを実行するという意味

Open3.capture3("echo #{params[:p]}
a; sort >&2
"
Open3.capture3("cmd #{params[:p]}", :stdin_data=>"foo¥nbar¥nbaz¥n")
ここを変数にすると
OSコマンドインジェクション脆弱性

params[:p] に ; xxx を入れたら、xxxコマンドが実行できる

Copyright © 2017-2019 Hiroshi Tokumaru

33

34.

[beta]

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 オプション Copyright © 2017-2019 Hiroshi Tokumaru 35

36.

37.

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

https://piyolog.hatenadiary.jp/entry/

38.

クロスサイト・リクエストフォージェリの原理正常系のHTTPリクエスト 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 CSRF攻撃時のHTTPリクエスト 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 Copyright © 2017-2019 Hiroshi Tokumaru Referer 以外は変わらない 38

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

41.

42.

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.

45.

[beta]

XSSのデモ
• 先ほどのCSRF対策済みの掲示板でなりすまし書き込みをやってみよう
• 実行するスクリプトは下記のもの
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);
}

Copyright © 2017-2019 Hiroshi Tokumaru

45

46.

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

47.

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

48.

49.

[beta]

JavaScript（イベントハンドラ）を一部動的生成
ボタンを押してください
<input type="button" value="Go" onclick="foo('<%= @msg %>')">
<p id="msg"></p>
<script>
function foo(msg) {
$('#msg').text(msg);
}
</script>

Copyright © 2017-2019 Hiroshi Tokumaru

49

50.

[beta]

イベントハンドラ動的生成XSSの原理
• onclick="foo('<%= @msg %>')"

にて以下を指定

@msg = "');alert('Cracked!')//"
• HTMLとしては以下が生成される
onclick="foo('&#39;);alert(&#39;Cracked!&#39;)//')"
• JavaScript処理系にはHTMLエスケープをデコードしてから渡される

foo('');alert('Cracked!')//')
Copyright © 2017-2019 Hiroshi Tokumaru

50

51.

[beta]

イベントハンドラ動的生成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.

[beta]

Dom Based XSS
脆弱な例: フラグメント識別子を表示するだけのスクリプト

<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>
Copyright © 2017-2019 Hiroshi Tokumaru

52

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.

[beta]

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

56.

57.

[beta]

脆弱なスクリプト例
• 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])

Demo
Copyright © 2017-2019 Hiroshi Tokumaru

57

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

60.

61.

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

62.

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

63.

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週間で解読 Surviving on little more than furious passion for many sleepless days, we now have over 90% of the leaked passwords recovered. http://securitynirvana.blogspot.jp/2012/06/finalword-on-linkedin-leak.html より引用 https://twitter.com/jmgosney/statuses/213212108924522496 より引用

http://securitynirvana.blogspot.jp/2012/06/final-

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を勉強しましょう…余計なことはしない方が無難です https://railstutorial.jp/chapters/modeling_users?version=5.1#sec-a_hashed_password 70

https://railstutorial.jp/chapters/modeling_users?version=5.1#sec-a_hashed_password

71.

72.

73.

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

https://gist.github.com/mala/bdcf8681615d9b5ba7814f48dcea8d60

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.

76.

https://railstutorial.jp/ 76