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エンジニアのためのウェブセキュリティ入門

More Related Content

What's hot

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

More from Hiroshi Tokumaru

Recently uploaded

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