Railsアプリケーションの
脆弱性動的自動検査
2019-08-29 Cookpad 夏季就業型インターン成果発表会 成果報告
@hakatashi
(最終成果報告)
@hakatashi
- 大学4年生
- インターン (高難易度技術コース, ~8/30)
- Webエンジニア
- フロントエンド得意マン
- 趣味
- ルービックキューブ
- 小説
- CTF
- アイマス
- Twitter: @hakatashi
- GitHub: @hakatashi
- hakatashi.com
脆弱性に対処する
- 脆弱性を生まない
- 適切なフレームワークを使う
- 脆弱性を発見する
- 人間が頑張る
- エンジニアが頑張る
- 報奨金制度
- 自動で脆弱性を見つける
- 静的検査
- 動的検査 ←今回のターゲット
- 人間が頑張る
動的脆弱性解析
動的脆弱性解析
実際に動いているアプリケーションに対して
攻撃を仕掛け、脆弱性が存在するかどうか
確認する
動的解析の利点
-
実際に攻撃が通ったかまで検証できるので、
偽陽性を極力少なくすることができる- 逆に、偽陰性は増える
- つまり、動的解析で発見された脆弱性は
「確実に直さないとヤバい」
欠点
- 到達不能なアドレスは検知できない
- 到達不能なパラメーターは検知できない
- 重い
Ruby on Rails に特化した
動的脆弱性検査
インターンでの成果物
動的解析の欠点に対応
- 到達不能なアドレスは検知できない
- →Railsならroutes.rbを見れば一発
- 到達不能なパラメーターは検知できない
- →静的解析を組み合わせて対処
- 重い
- →Controllerのメソッド単位の呼び出しで
オーバーヘッドを最小限に
- →Controllerのメソッド単位の呼び出しで
対象の
Railsアプリ
DB
③アクセス
を監視
ファイル
システム
攻撃
スクリプト
②攻撃
ペイロード
①静的解析でURLと
パラメーターを取得
④実際に攻撃が発火したか
確認する
レスポンス
(XSSなどを検証)
脆弱性レポート
デモ
やりきれなかったこと
- paramsの抽出をもう少し詰める
- SQLi以外の脆弱性の検知
- XSS検知は現状だいぶお粗末
- 各種特殊ケースのハンドリング
ありがとう
ございました!
おまけ (時間があれば)
URLパラメーターの抽出
残念ながらRailsのURLパラメーターは
統一的なインタフェースでアクセスできない。
現在、パラメーターの抽出はRubyのコードをパースして
静的解析で抽出している。
一言で言うとparams変数を見るだけだが⋯⋯
if params[:hoge] == 'fuga'
# ここに脆弱なコードを入力
end
user = User.find_by(id: params[:user_id])
return not_found unless user.present?
# ここに脆弱なコードを入力
if params[:password] == params[:password_confirm]
# ここに脆弱なコードを入力
end
if params[:user][:password].present?
# ここに脆弱なコードを入力
end
class UserController
before_action :set_user
def show
# ここに脆弱なコードを入力
end
private
def set_user
@user = User.find_by(id: params[:user_id])
return not_found unless @user.present?
end
end
%i[user password].each do |keyword|
return bad_request if params[keyword].nil?
end
# ここに脆弱なコードを入力
class UserController
def show
parameters = user_params
# ここに脆弱なコードを入力
end
private
def user_params
params.require(:user).permit(:name, :email)
end
end
パターンが多くて大変!
→rspec-mockのdoubleみたいな手法で
paramsへのアクセスも動的に解析する?
パラメーターの抽出は今後の課題
おわり
Railsアプリケーションの動的脆弱性自動検査 (最終成果報告)
By Koki Takahashi
Railsアプリケーションの動的脆弱性自動検査 (最終成果報告)
2019-08-29 Cookpad 夏季就業型インターン成果発表会 成果報告
- 1,209