- ベストアンサー
XSS、CSRF、SQLインジェクションについて
XSS、CSRF、SQLインジェクションをそれぞれ簡単に説明すると、 XSS・・・動的なWebサイトにおける入力フォームの脆弱性 CSRF・・・ユーザーになりすましてWebサーバーにリクエストすること SQLインジェクション・・・アプリケーションが実行するSQL文に変なものを注入して、意図しない 動作をさせる攻撃のこと で正しいですか？
- OBAKEI
- お礼率0% (7/4955)
- その他（プログラミング・開発）
- 回答数1
- ありがとう数0
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
そんな感じです
関連するQ&A
- SQLインジェクションについて質問です
よくSQLインジェクションの攻撃で、改竄されたWEBページからウイルスを仕込まれた。 等という話を耳にしますが、この攻撃でどうやって改竄するのですか？ 私が知ってる範囲だと、この攻撃では入力フォームに必ず条件マッチするようなSQLを入れて 情報を取り出したり、DBの情報を書き換えたり、情報を消したりくらいしか出来ない気がするのですが・・ あと、SQLインジェクションの紹介でよく見る、ログイン画面で「' 1=1;--」みたいな入力は誰でも思いつくと思うのですが、DBの情報を書き換えたり消したりするのって そのDBのカラム名とかが分からないとできないですよね。 攻撃者はこれらを推測して行っているのですか。 それともカラム名とかを知り得る攻撃手法があるのでしょうか。 また、SQLインジェクションとは関係ないのですがXSSという攻撃手法もありますよね。 こっちはクッキー情報を盗まれるのが一番大きな被害とありますが クッキー情報を盗まれると具体的に何がまずいのでしょうか。 サーバー側でクッキーに個人の名前とかメアドとかを入れてる場合があるという事ですか？
- 締切済み
- MySQL
- SQLインジェクションについて
SQLインジェクション対策についてご質問があります。 SQLを入力してそのまま実行するプログラムを作ろうとしています。 ユーザーが入力したSQLをプログラム側でSQLインジェクションを含むかどうかの判定が できるようにしたいのですが、可能なのでしょうか？ よろしくお願い致します。
- 締切済み
- その他（プログラミング・開発）
- SQLインジェクション対策
Webアプリにて入力フォームからのSQLインジェクション対策を行いたいと思っているのですが その１つとしてpreparedstatement SQLを使用することを考えています。 これを使用すればシングルクォーテーションを使った 悪意のあるSQL文を挿入されることが防げると思うのですが他に何か考慮することって あるのでしょうか。
- ベストアンサー
- Java
- SQLインジェクション
SQLインジェクション対策の為、DB(postgresql8.0.4)登録の際に今まではaddslashesを使用し実装していたのですが、それではwebサイトの脆弱性の為使われないと言う事で、pg_escape_stringを使い変更したのですが、pg_escape_stringは基本的にDBとconnectしていない限り使えないのでしょうか？
- ベストアンサー
- PHP
- SQLインジェクションの対策
SQLインジェクションの対策 いつもお世話になっております。 SQLインジェクションの対策についてお伺いいたします。 もともと↓のようなSQL文だったものを "select user_id from table where user_id='{$user_id}'" 以下のように変更しました。 "select user_id from table where user_id='" . mysql_real_escape_string($user_id) . "'" 以下のように実行されていたSQL文は select user_idfrom table where user_id='10001' and 'a'='a' ↓のようにエスケープ処理して実行されるようになりました。（入力値は「10001' and 'a'='a」） select user_id from table where user_id='10001\' and \'a\'=\'a' ですが、phpMyAdminで実行してみるとどちらのSQL文も同じ結果が取得できてしまいます。 これでは対策になっていないと思ったので、質問させていただきました。 （magic_quotes_gpcはoffに設定しています。） なにか他の方法がいいのでしょうか。 ご教示よろしくお願いいたします。 ＜環境＞ PHP 5.1.6 MySQL 5.0.45
- ベストアンサー
- PHP
- XSSの新たなタイプとは何というものでしょうか？
以下の文章が出ていました。 ------------------------------------------------------------ クロスサイトスクリプティング(XSS)の基本的な対策が行き届いていないウェブサイトも多く、届出の多さに繋がっている。 中には、ウェブサイトの本来の機能に関する部分では対策が行われつつも、エラーページなどに問題が残る例もある。 加えて2007年は、ファイル形式や文字コードをウェブブラウザに誤認させる方式の、新しい攻撃手法が知られるようになった。 このため、今まで脆弱性がなかったと思われていたウェブサイトにも、脆弱性が生まれてしまうこととなり、対策が必要なウェブサイトが出てきている。 ------------------------------------------------------------ この中の、 「加えて2007年は、ファイル形式や文字コードをウェブブラウザに誤認させる方式の、新しい攻撃手法が知られるようになった。」 という攻撃手法とは何というものでしょうか？
- 締切済み
- ネットワーク
- SQL インジェクションは PQexecParams で防げますか？
お世話になっております。商用のサーバーを運営しているものです。 最近私が運営しているサーバーでチャットをやることになっているのですが、できればワイセツなどの禁止用語以外は自由にしたいのですが、そうするとSQLインジェクションの心配があります。それで、ユーザーが入力した文字列を扱う部分を PQexecParams を使ってデータベースに入れようと思っているのですが、これだけで問題は解決できますか？ これでも危険な攻撃を受けるケースがあるならばお教えください。
- ベストアンサー
- PostgreSQL
- IIS７．０におけるＳＱＬインジェクション対抗策について教えてください
IIS７．０におけるＳＱＬインジェクション対抗策について教えてください 1ヶ月ほど前からデータベースに悪質なスクリプトが書き込まれるようになりました。 そこで、DBユーザー名もパスワードも変更しましたがそれでも書き込まれるので、データベースにUPDATEもしくはinsertしているファイルにエスケープ処理をしようとしていますが、ファイル数が多いので 一旦、それらのファイルに外部からアクセスできないようにIISで設定してしまいました。 ほとんどすべてのIPアドレスからのアクセスを拒否するようにマスクは0.0.0.0に設定しています。 アクセスしようとすると403エラーになります。 ところがそれでもスクリプトが書き込まれるのです。 こういう攻撃って可能なのでしょうか？ ファイルアクセス不可にも関わらず、テーブルに書き込みされるということは、ファイルにエスケイプ処理を施しても無駄だと思い、 とりあえずＤＢのすべてのユーザーにテーブル」への挿入・更新権限を拒否しました。 これでやっと書き込みがなくなりましたが、この設定ではWEB上から何らかのデータ操作をしようとする毎にＷＥＢサーバーにリモートデスクトップ等でアクセスして、ＳＱＬサーバーのユーザーに権限付与しなければならず、ＷＥＢアプリケーションとしての意味がなくなります。 対応策はあるのでしょうか 大変困っています。 サーバーへの解放ポートはport80のみで、当然、SQLポート1433どは閉じています
- 締切済み
- ネットワーク
- 会員数が少ないログイン後の会員エリアならば、Webアプリケーション脆弱性対策は過敏にならずとも？
会員数が少ないログイン後の会員エリアならば、Webアプリケーション脆弱性対策は過敏にならずとも良いのではと考えたのですが、妥当な考えでしょうか？ 会員サイトを制作しようとしておりますが、内製にするか外部プラットフォームを使うか？で思案しております。 プログラミングできる人間はたくさんいるので内製力はあるのですが(私はプログラミングはできません)、ただ、Webプログラミングでないプログラマーばかりなので、Webの方は不慣れです。 よって、Webアプリケーションの脆弱性対策の知識がまるで無い状況です。 XSS(クロスサイト・スクリプティング) CSRF(クロスサイトリクエストフォージェリ) SQLインジェクション OSコマンドインジェクション HTTP ヘッダ・インジェクション パス名パラメータの未チェック／ディレクトリ・トラバーサル バッファーオーバーフロー など、色々ありますよね。 このあたりのことを考えると、内製はやめて外部プラットフォームを利用するしかないのか、と思っていました。問題が起こっては大変なので。 Webアプリの脆弱性対策は日々新たな脆弱性が出てくるたびに対策を追加していかなければならないので大変そうで・・・・・ そういう中で気づいたのですが、Webアプリケーションの脆弱性を突く色んな方法がありますが、よくよく考えますと、会員エリアは会員しか入らないのだから、そんなに過敏に考えなくとも大丈夫なのではないか、と思い直したのです。 何せ会員数が少ないのです。 当初は10～30名程度、100名になるのもだいぶ時間がかかる感じですので。 会員しかもらえないログインID・パスワードでログインしたあとの会員エリアですから、ここの中の各入力フォームに悪いコードを入れる輩は会員か会員がID・パスワードを教えた第三者しかないわけで、本件のように会員数が極端に少ない場合なので、すぐ面が割れると感じる会員が悪いことをしづらいだろうと思ったのです。 質問ですが、 質問[1] 会員ログインページは非会員でも開けるので、このID・パスワードのinput textに対するWebアプリ脆弱性処置ができないことになる。 ここは会員だけ開くページでないため危険にさらされるわけだから、処置ができないと結局意味が無いでしょうか？ 質問[2] ログイン後の会員エリアであっても、知識のあるクラッカー(悪いハッカー)からすればURLを知ることはお手の物であり、会員しか入れないエリアの入力フォームのWebアプリ脆弱性対策ができていないと、いくらログイン後のページであっても関係なくどんどん突かれてしまうのでしょうか？ 以上です。 有識者の方の的確なお話を頂戴できればとてもありがたいです。 何卒宜しくお願いいたします。
- ベストアンサー
- その他（プログラミング・開発）
- SQLインジェクション事件について
私は一介の事務ユーザーにすぎませんが、職場で他にパソコンのことがわかる人がいないので、あれこれ頼られてしまい少々重荷の毎日です。 先般大きなニュースで一般市民にもすっかり有名？になってしまったSQLインジェクションのことについて、ちょっと教えて下さい。 他の掲示板サイトで、事件の原因はマイクロソフト製ウインドウズOSと、マイクロソフト製SQLサーバーの欠陥が相乗的に生み出したセキュリティホールだから、他社製品で組まれたシステムなら大丈夫だ、と教わりました。 私はSQLのことをよく知らないのですが、調べてみると言語としてSQLは標準化されていると解説されているので、どこのメーカーのシステムでもSQLサーバーは普遍的に対策が必要ではないかな？と思ってしまったのですが、本当にマイクロソフト製品だけの問題でしょうか？ （それとも、価格.comと静岡新聞サイトで犯人が使った「あの手口」に限ってマイクロソフトの欠陥責任だったのでしょうか？） 自分なりにIT関連のWEB記事バックナンバーを色々当ってみましたが、これについてweb上で報道されている物はちょっとみつかりませんでした。 どなたかどうぞよろしくおねがいします。
- ベストアンサー
- ネットワーク
