日本国内のウェブサイトにおける SQL インジェクションの脆弱性が、国内外から JPCERT/CC に複数報告されています。 日本国内のウェブサイトにおける SQL インジェクションの脆弱性が、国内外から JPCERT/CC に複数報告されています。 オー プンソースの SQL インジェクション脆弱性診断ツール sqlmap を使用して、日本国内のウェブサイトで動作するウェブアプリケーションの脆弱性を検出しようとする海外からのアクセスが発生しています。こうしたアクセスは組織規模の大小によらず、中小企業や個人のウェブサイトに対しても行われています。SQL インジェクションの脆弱性が存在するウェブサイトでは、ユーザや開発者の意図しない SQL 文が実行され、様々な影響を受ける可能性があります。 sqlmap は、おもに次の 5つの手法を使用します。 Boolean-based blind WH
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 海外の xkcd というサイトにこんな4コマ漫画が掲載されています。 英語ですが、じっくり読んでみてください。 きっと「あー、なるほど（苦笑）」と思うはずです。 えっ、わからない？？ じゃあ、日本語訳を載せましょう。 もしもし、小学校の者ですが。今ちょっとコンピュータのトラブルが起きてまして。 あら大変、うちの息子が何か壊しましたか？ / まあ、そんな感じですが・・・。 お母さん、あなたは本当に息子さんに "Robert'); DROP TABLE Students; --" という名前を付けたんですか？ / ええ、そうですよ。みんな「
http://blog.ohgaki.net/os-command-escape-shell-spec-command-implementation 「えすけーぷじゅうよう!!」を強調して言いたいからなのかシェルの理解が足りないからなのか、 意図がよくわからない文言やら説明が散見されますが、きりがないのでそれらはスルーします。 (シェルについては、なんで関係ない tcsh の話が出てくるんだとか、 位置パラメーター展開に $* 使うなとか、色々) 特に気になったのが以下の文章です。(強調は私によるもの) OSコマンドはOSが提供するシェルで実行されます。 シェルはテキストインターフェースを持ち、 テキストでコマンドとオプションを受け取り実行します。 例示した脆弱なPHPプログラムの場合、 ユーザーからの入力に対しセキュリティ処理を一切してないため、 簡単にサーバーを乗っ取られる可能性があり
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
Ruby on Rails(3.2.9, 3.1.8, 3.0.17以前)のfind_by_*メソッドにSQLインジェクション脆弱性が見つかりました(CVE-2012-5664)。このエントリではその概要と対策について説明します。 概要 Ruby on Railsのfind_by_*メソッドの引数としてハッシュを指定することで、任意のSELECT文を実行できる脆弱性があります。 検証 Ruby on Rails3.2.9の環境を用意して、以下の2つのモデルを用意しました。 $ rails g scaffold user name:string email:string $ rails g scaffold book author:string title:string モデルUserは個人情報を保持しており、自分自身の情報のみが閲覧できるという想定です。モデルBookは書誌データベースであ
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
第四企画 坂井 潔 ここではPHPでSQLインジェクション対策としてエスケープ・クォート処理を行うケースを説明します。なおSQLインジェクションの簡単な説明や、プレースホルダを用いてより効果的な対策を行うケースに関してはプレースホルダ編を参照してください。 エスケープとは？ それではエスケープ処理とはなんでしょうか？ 分かりやすいケースとして、文字列を扱う場合を説明します。 例えば「名前がO'Reillyの行をテーブルusersから取得する」あるいは「テーブルusersに、名前はO'Reilly、メールアドレスはo'reilly@example.comとo'reilly_mobile@example.netの２つを改行で繋げたデータを、行として挿入する」と言ったSQLをつくると、この命令文全体が１つ文字列になります。その命令文としての文字列の中に、値としての文字列を埋め込む場合には、それが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く