[情報SEC]第13回 Webアプリケーションの入力データを悪用した攻撃(2)

第13回　Webアプリケーションの入力データを悪用した攻撃(2)

SQLインジェクション
例えば、Webページに検索文字列入れてその情報にヒットする情報が表示されるシステム。
その情報はデータベースから持ってくるものとする。

SQLはこんな感じ。
SELECT * FROM members WHERE search='string';
で、この検索システムにこんな文字列を入力してみる。

string';DELETE FROM members='string
すると、結果的にこういうSQLを実行することになる。
SELECT * FROM members WHERE search='string';DELETE FROM search='string';

stringという文字列が入っているのレコードが削除されるわけだ。
同じ理屈でdrop table なんかできるし、全件画面に表示させることもうまく書けばできる。
これがSQLインジェクション。

破壊は、SELECT以外webサーバからの入力ではできないように
権限設定しとけば防げるけど、全件取得は同じSELECTなので防げない。
こまったの。

通常は、SQLで使える文字はエスケープ(\をつける)して使うなどの対応をとる。
ストアドプロシージャを使うのも有効とのこと。
水神はストアドプロシージャなるものは使ったことないので、なんとも言えませんが。

しくみ自体は確かにSQLインジェクションには有効だの。
未だにSQLインジェクションの被害も出てるしの。
カカクコムやられたのも確かこれだったし。

OSコマンドインジェクション
要するに、これもSQLと同じ問題だ。
OSのコマンドへの引数をWebからの入力とする場合に起こる。

とはいっても、OSのコマンドを直接使うことはあんまりないけどね。
Webページで言語と違う言語で書いたプログラム(コマンド)を呼び出すってことはある。
例えば、perlからjavaとか。

そういう場合は、問題になるかも。
例えば、java sql stringというコマンドを呼び出すとする。
stringがWebからの入力文字列。

stringの変わりに、string;ls とすると、java sql stringの実行結果に加え、
lsも実行され、ファイルの一覧(文字列)も戻ってくる。
プログラムが単純にこの結果を画面に表示してるのなら、ファイルの一覧も表示される。

...あんまり楽しくないの。
クラッカーさんはもうちょっと有意義なことを考えるんだろうけど。
対策は記号系(この場合は;)を省くとか、なんとかかな...これはあんまり意識したことないな。

まずいの。
今度から気をつけよう。
まあ、でもそんな危険なこと(入力文字列でコマンド実行)自体せんからいいか。