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

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

アジェンダ
• 3分間クッキングデモ
• OSコマンドインジェクション
• クロスサイトリクエストフォージェリ(CSRF)
• クロスサイトスクリプティング(XSS)
• SQLインジェクション
• パスワードの保護
• プラットフォームの脆弱性対応
• 参考文献
Copyright © 2017-2019 Hiroshi Tokumaru 2

徳丸浩の自己紹介
• 経歴
– 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月)
– 技術士（情報工学部門）

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

3分間クッキングデモ
• 極小のブックマークアプリを作ります
$ rails new bookmark_app
$ cd bookmark_app
$ rails generate scaffold bookmark site:string url:string
$ rails db:migrate
• Viewを修正して、リンク表示になるよう link_to メソッドを使う

作ったアプリを脆弱性診断してみましょう!

クロスサイトスクリプティング検査をしてみる
<a href="http://"><script>alert(1)</script>">
"><script>alert(1)</script></a>

よさそうじゃないですか!

でも、抜けがあります

JavaScriptスキームによるXSSは可能
<a href="javascript:alert(1)">xss</a>

バリデーションで対処してみましょう

バリデーションをコントローラに追加

バリデーションでXSSを防ぐ

よさそうじゃないですか!

でもだめです

バリデーションを突破するパターン
javascript:alert(1)/* 【改行】
http://example.jp/*/

なぜ駄目なのか?

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

でも、そもそもコントローラに独自バリデー
タを実装するのはよくないよね

Railsの機能でモデルにバリデータを書こう

モデルにバリデータを記述

以下のエラーが表示される
この正規表現は複数行のアンカー（^または$）を使用
しているため、セキュリティ上のリスクが生じる可能性
がある。
Aと zを使うつもりだったか、または
：multiline => trueオプションを追加するのを忘れた
か?

エラーメッセージに従い、^ を A に修正し
ましょう

今度は大丈夫

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

ウェブアプリケーションセキュリティ入門

本日使用する脆弱なアプリケーション
山田祥寛 (著)
Ruby on Rails 5 アプリケーションプログラミング
技術評論社 (2017/4)と Rails Tutorialのサンプルに
脆弱性を加えましたw
※オリジナルに脆弱性があるわけではありません

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

OSコマンドインジェクションとは何か?
• シェル(/bin/sh)呼び出し可能な機能を悪用して
攻撃者が勝手にコマンドをサーバー上で
実行できる脆弱性

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

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

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

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が実行されてしまう

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

クロスサイト・リクエストフォージェリ(CSRF)

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

クロスサイト・リクエストフォージェリの原理
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
以外は変
わらない

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

CSRF対策の方法は?
• Ruby on RailsはGET以外のリクエスト全てにトークンを要求する
• 素直にRuby on Railsを使う限り、CSRF脆弱にする方が難しいw
• 脆弱性が混入する主なパターン
– トークンのチェックを無効化してしまった
– Railsの流儀に従わずに処理を書いた（例: GETメソッドで更新処理を受け取る）
– わざとCSRFチェックを無効化する
protect_from_forgery :except => :create # デモを見よう

クロスサイト・スクリプティング(XSS)

クロスサイトスクリプティング(XSS)とは何か?
• クロスサイトスクリプティング(XSS)は、
攻撃者が、攻撃対象のページに
JavaScriptを勝手に埋め込める脆弱性

Ruby on RailsでXSS脆弱にする方法
• 3分間クッキングで説明したように、基本的にRuby on Railsで開発し
たアプリケーションはXSS対策がなされている
– …が、例外もある
– URLを指定する href 属性や src 属性に javascript: スキームを入力する
– その他、後述の状況
• 以下を使えば、HTMLエスケープされないのでXSS脆弱になる
– <%== 文字列 %>
– <% raw 文字列 %>
– <% 文字列.html_safe %>

Demo

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);
}

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

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

XSSの対策
• 基本的にRuby on Railsの流儀に従えば大半の箇所を対策してくれる
• 以下に注意
– src属性、href属性等URLを受け取る属性 → URLのバリデーション
– JavaScriptの動的生成（とくに文字列リテラル）
– DOM Based XSS

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

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

イベントハンドラ動的生成XSSの対策
• 原因
– イベントハンドラ内の文字列リテラルは、JavaSriptとしてのエスケープをして
からHTMLエスケープしなければならないが、JavaScriptとしてのエスケープが
抜けている
• 対策（以下のいずれか）
– JavaScriptの動的生成をせずに、カスタムデータ属性経由にパラメータを渡す
<div id="main" data-msg="<%= @msg %>"> 
$('#msg').text($('#main').data('msg')); // データ参照
– JSON形式でデータを渡す
onclick="foo(<%= @msg.to_json %>)"

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>
脆弱な例: フラグメント識別子を表示するだけのスクリプト

DOM Based XSSの攻撃例
• Script要素による攻撃は有効にならない
<script>alert(1)</script> など
• img 要素のonerror属性などは攻撃に使える
<img src=# onerror=alert(1)>
• 上記を含むHTMLをinnerHTMLに挿入すると、JavaScriptが実行される
• document.writeであれば、script要素でも攻撃可能

対策: 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)); // 対策
}

SQLインジェクション

SQLインジェクションとは何か?
• 攻撃者が
ウェブアプリケーションが利用するSQL文の意味を変更したり
追加のSQL文を勝手に実行できる脆弱性

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

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

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

パスワードの保存

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

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

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

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

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.

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

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

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

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

プラットフォームの脆弱性対応

OS(Linux等)のパッチ適用を忘れずに
181 packages can be updated.
99 updates are security updates.

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

プラットフォームの脆弱性対応
• 使用ソフトウェアのサポートライフサイクルポリシーを確認する
– 例: 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

参考資料

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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Hiroshi Tokumaru

More from Hiroshi Tokumaru (20)

Recently uploaded

Recently uploaded (9)

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