この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak

memcachedを安全に運用するポイント 2010年8月10日のスラッシュドット・ジャパンにて「Memcached に潜むセキュリティホール」としてmemcachedの脆弱性に関する記事が上げられました。記事の内容をまとめると以下の2点となります。 bit.ly や Globworld、Gowalla といったサイトではインターネットから memcached へのアクセスが可能であった アクセスしたmemcached上にユーザーのログイン ID / パスワードが格納されており参照可能だった http://slashdot.jp/security/article.pl?sid=10/08/10/0052240 ここには2つの問題があったと考えます。1つ目はmemcachedをインターネットから接続可能な状態で設置してしまったこと、もう1つはキャッシュ上に置かれている必要はなさそうなパスワー

世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン

前回に引き続き、Think IT上の連載「SQLインジェクション大全」の第4回：ケース別、攻撃の手口を読んで感じたことを書きたい。 まず、この記事は以下のような書き出しから始まっている。 本記事は、システムを防御するにはまず敵を知らなければならない、という意図の下に、攻撃手法を紹介する。 dfltweb1.onamae.com – このドメインはお名前.comで取得されています。 この趣旨に異論があるわけではないが、しかしこの表現は誤解を生みやすいものだと思う。 というのは、「敵」(攻撃方法)を知ったからと言って、防御の方法が導き出せる訳ではないからだ。例えば、開発者が「最近のSQLインジェクションの自動化攻撃にはT-SQLのDECLARE文が用いられる」という情報を得て独自に対策を考えた場合、DECLAREという単語をチェックしてエラーにしたり、単語を削除することを考えがちだと思う。現に

Oracle、IBM DB2、Microsoft SQL Server、Sybaseに対応したデータベース脆弱性スキャナ「Scuba by Imperva」が無料でダウンロードして利用できるようになりました。パッチが適用されているかどうか、危険なプロセスおよび弱いパスワードはないかどうかなど、何百もの欠点を見つけてくれるとのこと。日本語のマニュアルも付いてきます。 Windows 98/NT/2000/XP、Sun Java JRE ver.5.0以上で動作します。 ダウンロードは以下から。 無償データベース脆弱性スキャナ | Scuba（スキューバ） by Imperva 製品情報 ダウンロードには無料のユーザー登録が必要で、起動する際にも情報の登録が必須です。 起動するとこんな感じ レポートはHTMLファイルで出力可能です MySQLなどにも対応してくれているとよかったのですが、将来的

木村 真幸　DTS　ネットワーク事業本部 プロジェクトマネージャ , 窪田 康大　豆蔵　BS事業部　開発技術チーム　コンサルタント Part3では，「不規則に発生する不正な動作」「SQLインジェクション」「パフォーマンス不足」「チェックボックスのおかしな挙動」「メモリー不足のエラー」の五つを取り上げて，その問題点と解決方法を説明します。 トラブル1　たまにおかしな動作をする！ Webブラウザからユーザー名などのデータを送信して結果を出力するといったWebアプリケーションで，たまにおかしな結果を出力することがあります。同じように操作をして正しく動くこともあるので，間違いに気づかないこともあります。しかも，おかしな動作に気づいてデバッグしてもソースコードに間違いを見つけられないことが多く，初級者の方ではどこを直せばよいか見当もつかないといった場合があります。 このような現象は，シングルスレッド

最近，「SQLインジェクション」の危険性について語られる機会が増えているが，SQLインジェクションの正体，その問題点，そしてそれを防ぐための方策について詳しく理解している人はまだ多くない。ここでは，SQLインジェクションとは何かを明確に定義し，どのようにして行われるかを説明し，SQLインジェクションから組織を守る方法を読者に伝えることによって，この状況を改善したい。 SQLインジェクションとは何か SQLインジェクションとは，アプリケーションに含まれるコーディング・エラーが原因となって引き起こされるぜい弱性，または欠陥である。SQLインジェクションは，ユーザーが入力したデータを使ってアプリケーションがSQLステートメントを作成し，それをSQL Serverに送信して実行する場合に発生する。この欠陥が及ぼす影響は，コーディング・エラーの性質によって様々である。 具体的に言うと，その影響は，エ

SQLインジェクション（SQLの挿入）は，Webアプリケーションへの攻撃手法の一つです。Webサーバーに対して特殊なデータを送ることで，アプリケーション開発者が想定していないSQL文を実行させます。この攻撃に対する対策を怠ると，データベース内の情報を不正に取得されたり，削除されたりする危険性があります。 SQLインジェクションに対するぜい弱性は，クライアントから受け取ったデータをもとにしてデータベースへのアクセスを実行するSQL文を組み立てる個所で発生します。例えばアプリケーションのプログラム中に，SQL文で操作対象のレコードを絞り込むWHERE句を組み立てる“WHERE userid='$uid'”のようなコードが書かれているとします。プログラマは，変数$uidにはクライアントから受け取ったユーザーIDを格納することを想定しています。 ところが，悪意のあるユーザーが“' OR 1=1--

【関連記事】 本内容についてのアップデート記事を公開しています。あわせてご確認ください（編集部） Security&Trustウォッチ（60） 今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた http://www.atmarkit.co.jp/fsecurity/column/ueno/60.html Webアプリケーションに対する攻撃手法の1つであるSQLインジェクションの存在は、かなり広く知られるようになった。しかし、その対策はまだ本当に理解されていないように思える。フォームから渡された値の特殊文字をエスケープしたり、PHPのmagic_quotes_gpcといった自動エスケープ機能をオンにするだけで対策したつもりになっていないだろうか。 基本はもちろん、セカンドオーダーSQLインジェクションやマルチバイト文字を利用したSQLインジェクションの攻撃パターンや、その対