読者です 読者をやめる 読者になる 読者になる

log

安全なwebアプリケーションの作り方 292-305

  • evalインジェクション
    • eval:与えられた文字列をスクリプトのソースとして解釈実行する機能
    • ちゃんと使わないとOSコマンドインジェクション攻撃と同じ被害を受ける(それはそう(それはそう))
    • 対策:eval相当機能を使わない/引数に外部からのパラメータを含めない/英数字に限定する

      • 思ったんだけど、脆弱性への対策として (1) 外部からのパラメータを使わない (2) どうしても使うときは英数字だけに限定する、っての多くない?いや、考えたら当たり前なんだけど、この2つを対策するだけである程度防げるのはすごいし、それでも防げてなくてこういう本で繰り返し言われているのも(色んな意味で)すごい
      • サンプル攻撃でデータのやりとりするときにBase64エンコードしてて、なんで?って思ったらこういうことらしい、なるほどなぁ…
      • https://ja.wikipedia.org/wiki/Base64

        Base64は、データを64種類の印字可能な英数字のみを用いて、それ以外の文字を扱うことの出来ない通信環境にてマルチバイト文字やバイナリデータを扱うためのエンコード方式である。MIMEによって規定されていて、7ビットのデータしか扱うことの出来ない電子メールにて広く利用されている。

    • 対策のevalに与えるパラメータを英数字に限定するってのは、スクリプト仕込むのに区切り文字(; / , / などなど、& とかもかな)使えなくなるからいい感じになるよ

    • evalはたしかに便利で強いけど、便利で強いものはそれだけ副作用があるし、脆弱性が入ったときの影響も大きいから使わないようにしたほうがよい

  • 競合状態の脆弱性
    • 共有資源:復数のものから同時に参照されるデータ。排他制御が不十分だと脆弱性の原因になる。
    • 別人の個人情報が画面に表示される/DBの不整合/ファイル内容の破損が起こる
    • 対策:共有資源使わない/排他制御ちゃんとする
    • 攻撃じゃなくて、ただの事故が起こる可能性もある。
    • 排他制御するとき、たとえば1件のリクエストで0.1sec待つとかしても、1e9件のリクエスト来たらめちゃくちゃ待たされるし、DoS攻撃が簡単に出来るようになるから、やっぱり共有資源は使わないべき。
    • どうしても必要なときは並行処理とかマルチスレッドプログラミングについて学ぼう!