SQLインジェクションを自分のプログラムで行う実験をしたいのですが、うまく出来ません
SQLインジェクションを自分のプログラムで行う実験をしたいのですが、うまく出来ません。 あまり知識がないので初心者向けで説明していただけるとありがたいのですが、実験で自分のJSPプログラムにSQLインジェクションを行うためにログインフォームから受け取ったユーザとパスワードでMYSQLにアクセスし指定のテーブルを表示するプログラムを作っています。 環境はもちろんローカル環境です。 以下はプログラムの一部です。 String user = request.getParameter("user"); String pass = request.getParameter("pass"); String url= "jdbc:mysql://" + sv+ "/" + db + "?user=" + user + "&password=" + pass + "&useUnicode=true&cha
妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション - ＊「ふっかつのじゅもんがちがいます。」withぬこ
繰り返しになりますが、妥当性検証は仕様の問題であってセキュリティ対策ではありません。 バリデーションは仕様の問題であってセキュリティ対策ではないとはどういうことか説明します。SQLインジェクションの対策は、1. SQLを文字列結合で作らない 2. プレースホルダを使う です。バリデーションは関係ありません。 簡単な例 Webアプリケーションで郵便番号を指定するフォームを考えましょう。 日本の郵便番号を指定するフォームの設計でよく見るものは大きく分けて2通りあり、上3桁と下4桁を別々に入力させるものと、1つのフォームにまとめて入力させるものです。住所から補完させる設計もありえますがここではおいておきます。 <input type="text" name="postal_code_1"> - <input type="text" name="postal_code_2"> <input typ
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
SQLの数値リテラルをシングルクォートでくくる手法について - とある技術屋の戯言
結論 セキュリティ対策の一環としてSQLの数値リテラル(が期待されるパラメータ)をシングルクォートでくくる(文字列扱いする)手法は使用すべきでない 理由 少なくともMySQLでは標榜されている通りの動作はしない上、意図しない副作用が発生する。 解説 数値リテラルをシングルクオートでくくる手法は、これを推奨する大垣氏によると次のような効果があるとされています。参考:なぜPHPアプリにセキュリティホールが多いのか? 第14回 減らないSQLインジェクション脆弱性 攻撃目的の入力が行われてもSQLインジェクションが発生しない 簡単に攻撃用の文字列が検出できる これらはどちらも数値型が期待されるパラメータに不正なデータが渡されるとクエリエラーが発生することが前提となっています。例として、 SELECT * FROM table WHERE id = $VALUE; --ここでidは整数型 というS
『よくわかるPHPの教科書』のSQLインジェクション脆弱性 - ockeghem's blog
このエントリでは、数値型の列に対するSQLインジェクションについて説明します。 以前のエントリで、たにぐちまことさんの書かれた『よくわかるPHPの教科書』の脆弱性について指摘しました。その際に、『私が見た範囲ではSQLインジェクション脆弱性はありませんでした』と書きましたが、その後PHPカンファレンス2011の講演準備をしている際に、同書を見ていてSQLインジェクション脆弱性があることに気がつきました。 脆弱性の説明 問題の箇所は同書P272のdelete.phpです。要点のみを示します。 $id = $_REQUEST['id']; // $id : 投稿ID $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id) $record = mysql_query($sql) or die(
Potential SQL Injection in Rails 3.0.x
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message There is a vulnerability in the limit() function in Rails 3.0.x. This vulnerability has been assigned the CVE identifier CVE-2011-0448.Versions Affected: 3.0.0-3.0.3 Not affected: Releases before 3.0.0 Fixed Versions: 3.0.4 Impact ------ All users running an affec
「Webアプリセキュリティ対策入門～あなたのサイトは大丈夫?」より、SQLインジェクションの対策
対策 SQL文のパラメータとなる入力が、数値型である場合は必ず数値型データであることを確認する。文字列型のデータである場合は必ずデータベースシステムにあったエスケープ方式で文字列をエスケープする。プリペアードクエリが利用できる場合は、プリペアードクエリを使用する。
第42回 PostgreSQL 9.0に見るSQLインジェクション対策 | gihyo.jp
PostgrSQL 9.0から追加されたエスケープ関数から、SQLインジェクション対策を再度解説してみたいと思います。 SQLインジェクション対策の4原則 基本的にはSQLインジェクション対策として以下の原則を守っていれば、SQLインジェクションに脆弱なアプリケーションを作ることはありません。 すべてのパラメータを文字列としてエスケープする すべてのパラメータをプリペアードクエリのパラメータとして処理する 文字エンコーディングの設定をAPIで行う パラメータとして処理できない文字列はバリデーションを行う 原則1と原則2は重複して適用する必要はありません。どちらかを行います。文字エンコーディングの設定やプリペアードクエリのエミュレーション・抽象化ライブラリのバグ等でSQLインジェクションが可能になる場合もありますが、通常であればこの原則を守っている限りSQLインジェクション脆弱性を作ることは
新しいタイプのWebサイト改ざんSQLインジェクション攻撃(続報) - Tokyo SOC Report
February 14, 2024 IBM® has big plans for the Power Virtual Server offering, which is IBM’s virtual machine as-a-se... February 13, 2024 Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announceme... February 12, 2024 IBM® Envizi™ is pleased to announce the release of additional functionality as we continue to bu...
ライザムーン(LizaMoon)攻撃に対してもWAFは有効 - ockeghem's blog
ライザムーン攻撃に対する行き届いた解説を読みました。 大規模インジェクション 「LizaMoon」攻撃について調べてみた。 - piyolog ここで紹介されている内容は素晴らしいと思うのですが、一点、WAFに関する以下の記述が引っかかりました。 SQLインジェクションであれば既知の攻撃手法でありWAFで防ぐことは出来るのではという考え方もありますが、例えばブラックリストタイプのWAFでこの数値リテラル型をつくSQLインジェクションを防ぐことが出来ません。HTTPリクエストとして受けた文字列だけで、最終的にデータベースに対して発行されるSQLでその文字列がどのような扱いになるか(数値リテラルになるのかどうか)判断することが出来ないためです。 本当にブラックリストタイプのWAFで防ぐことができないのでしょうか。IBMのレポートに紹介されている以下の攻撃で考えてみます。 /target.asp
第2回：SQLインジェクションを防ぐには｜株式会社トッパンシステムソリューションズ
ハッキングを行おうとする者にとって、エラー時に表示される情報は非常に有益です。 例えばDBが出力するエラーが直接表示されている場合、ハッカーに対して攻撃のための大きな手がかりを与えてしまうことになります。 まず、システムが出力するエラー情報をユーザに見せないようにしましょう。エラー発生時は、エラーが発生したことのみを画面に表示し、別途エラーログなどを出力することが懸命です。 その他、HTML内にSQLをコメントで出力したり、公開フォルダ内にエラーログを保管するといったことも避けるべきです。 テーブル名やカラム名など、SQL文を構成する要素をユーザに知られないように、可能な限り情報の隠蔽を心がけることが重要となります。 ユーザが画面からデータを入力でき、その値がSQL文の構成要素になる場合、SQLインジェクションが引き起こされる確率が高くなると言っていいでしょう。 水際対策として、ユーザの入
[重要] セキュリティアップデート Movable Type 5.04 および 4.28の提供を開始 | Movable Type ニュース
Movable Type 4 および Movable Type 5 で確認された複数のセキュリティ問題の修正バージョンとして、 Movable Type 4.28 および Movable Type 5.04 の提供を開始いたします。Movable Type 4 および Movable Type 5 のすべてのバージョンの、修正版へのアップグレードを強く推奨します。 概要 Movable Type 5.031 および 4.27 を含む以前のバージョンでは、アプリケーション上の入力項目の一部において、適切に入力エスケープ処理されないため、クロスサイトスクリプティング（XSS）および SQLインジェクションが発生する可能性があります。 想定される影響 遠隔の第三者により、当該製品で管理している情報を閲覧されたり、変更されたりする可能性があります。また、遠隔の第三者が特定の操作をおこなうことで、ユ
![[重要] セキュリティアップデート Movable Type 5.04 および 4.28の提供を開始 | Movable Type ニュース](https://cdn-ak-scissors.b.st-hatena.com/image/square/5cfc5bfad4f2ab6f23c139f85505e65d86f56dcc/height=288;version=1;width=512/https%3A%2F%2Fwww.sixapart.jp%2Fshare%2Fimages%2Fogimage-mt-news.png)
【SQLインジェクション】回避策として考えたのですが、どうなんでしょうか？？？ - SQLインジェクションの対策で悩んで... - Yahoo!知恵袋
フォームのデータを受け取った後に、エラーチェックをまずかけることです。 上記の流れで、ユーザ名を受け取った後何のチェックもしないでクエリに挿入してしまうと、たとえば「test'; update a_m_user set user_password = ''」なんて入力されると、すべてのユーザのパスワードがクリアされてしまうわけですね。 というわけで、ユーザ名に記号は使えないようにして、記号が入っていたらその時点でエラーとするとか、正しいエスケープ処理を行うとか（mysql_real_escape_string等）が必要になってくるわけですね。 とりあえず、SQLインジェクションについては、googleなどで検索すれば、その代表的な手法や防御手段はいくらでも出てきますので、ざっくり読んでみることです。 車輪の再発明にいそしむよりも、すでに確立されている対策をきちんととることが重要です。 ＃＃
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた
「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。 これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。 このドキュメント作成に協力したという、独立行政法人産業技術総合研究所 情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月
Threatpost | The first stop for security news
Researchers uncover a watering hole attack likely carried out by APT TA423, which attempts to plant the ScanBox JavaScript-based reconnaissance tool.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bugtraq
CSI:人材進化 - SQLインジェクション対策について - 井上創造研究室
セキュリティ通信｜セキュリティ関連ニュース サイト改ざん(2)ハウス食品、民主党、ローソンなど被害サイト23の改ざん状況
セキュリティ通信｜セキュリティ関連ニュース サイト改ざん(2)ハウス食品、民主党、ローソンなど被害サイト23の改ざん状況