evalインジェクション

書籍を読んで

www.amazon.co.jp

こちらの書籍を読んでWebアプリケーションを作る際に重要な要点を自分用としてアウトプットします。

evalインジェクション

概要

構造をもったデータの例として、プログラムのソースコードを用いるケースがある。 最近よく用いられるJSONはJavaScriptのソースコードの形式を一部切り出したものが起源ですし、その他の言語でも、ソースコード解釈実行するevalと呼ばれる機能や関数があり、各言語のソースコードをデータとして扱うことができる。 evalの利用法に問題がある場合、外部から送り込んだスクリプトを実行される場合がある。 このような攻撃をevalインジェクション攻撃と呼び、そのような攻撃を受ける脆弱性をevalインジェクション脆弱性と呼ぶ evalインジェクションによる影響は以下の通り - 情報漏洩 - サイト改ざん - 不正な機能実行 - 他サイトへの攻撃(踏み台) - 暗号通貨の採掘(マイニング)

脆弱性が生まれる原因

• evalを用いることがそもそも危険である
• evalに与えるパラメータのチェックがされていない

対策

eval(同等機能を含む)を使わない

• シリアライズの目的である場合、以下の選択肢がある
  • implode/explode
    • implode関数は配列を引数としてとり、区切り記号をはさんで文字列にする関数
    • explodeはその逆を行う
    • 単純な配列のシリアライズには対応できる
  • json_encode/json_decode
    • 自由度と安全性のバランスから多くの場合に推奨できる方法
  • serialize/unserialize
    • serializeはさらに自由度が高く、オブジェクトのシリアライズが可能
    • しかし、「安全でないデシリアライゼーション」の原因になるので避けるべき
• シリアライズ以外の目的でも、evalなどを使わない実装を検討すべき
  • 多くの場合eval相当の機能を使わなくても、同等の処理は実装可能である
  • 例えば、e修飾子つきのpreg_replaceの代わりにpreg_replace_callbackを使うと安全である

    evalの引数に外部からのパラメータを指定しない

    evalを使った場合でも外部からパラメータを指定できなければ攻撃はできない。 ただし、スクリプトの注入経路はHTTPリクエスト経由だけとは限らず、ファイルやデータベース経由で注入できる場合もあるので、そのような注入経路の可能性がある場合は、この対策方法は使えない。

    evalの与える外部からのパラメータを英数字に制限する

    外部から与えるパラメータを英数字に限定できれば、スクリプトの注入に必要な記号文字(セミコロンのほか、コンマ、引用符など多種)が使えなくなるので、スクリプト注入はできなくなる。

まとめ

evalは強力な機能であるがゆえに、脆弱性が混入した場合の影響も甚大である。 世の中にはevalのない言語も多く存在するわけで、極力evalを使わない実装が推奨される。