セキュリテイについて

◇-セキュリテイについて-aa(7/31-20:55)No.33750
　┣Re:セキュリテイについて-Discovery(7/31-23:30)No.33756
　┣Re:セキュリテイについて-かず＠自宅(8/1-01:45)No.33771
　┗Re:セキュリテイについて  (注意：エセ回答です信用しないで・・・)-kei100(8/1-12:52)No.33791

「何か一言」を読む Facebookコメントができます

33750	セキュリテイについて	aa	7/31-20:55
OS名：Windows98 パソコン名：ソフト名：こんばんは。いつもお世話になります。私の会社でCGIを使ってある操作をお客様にやってもらおうと思っています。そこでメールでIDやパスワードをURLに埋め込んでそのアドレスにアクセスしてもらおうとしたところある人からセキュリティ上それはまずいといわれました。そこでダイアログボックスにID　パスワードを入力する方式にかえたのですが IDやパスワードをURLに埋め込むとどういった危険があるのでしょうか？教えてください。よろしくお願いします。

33756	Re:セキュリテイについて	Discovery	7/31-23:30
記事番号33750へのコメント aaさんは No.33750「セキュリテイについて」で書きました。 >OS名：Windows98 >パソコン名： >ソフト名： >こんばんは。いつもお世話になります。 >私の会社でCGIを使って >ある操作をお客様にやってもらおうと思っています。 >そこでメールでIDやパスワードをURLに埋め込んで >そのアドレスにアクセスしてもらおうとしたところ >ある人からセキュリティ上それはまずいといわれました。 >そこでダイアログボックスにID　パスワードを入力する >方式にかえたのですが >IDやパスワードをURLに埋め込むと >どういった危険があるのでしょうか？ >教えてください。 >よろしくお願いします。メールってテキストだよなこれ分かるな、で途中で見られる可能性も否定は出来んよな中継サーバーなんかでもな受信した後個人のパソコンでも席を離れた隙に人が見る可能性も否定は出来ん訳だで、埋め込むとそれを見た人は誰でもアクセス出来るわけだよなそれで、セキュリティ守れるかどうか考えてみたらどうだ

33771	Re:セキュリテイについて	かず＠自宅	8/1-01:45
記事番号33750へのコメント >そこでダイアログボックスにＩＤ　パスワードを入力する >方式にかえたのですが >ＩＤやパスワードをＵＲＬに埋め込むと >どういった危険があるのでしょうか？ >教えてください。 >よろしくお願いします。 > ＤＢを使うのはどう？予め、ＤＢにユーザー名とパスワードを入れておく。 IDやパスワードを入力すると、ＤＢにアクセスしに行って、認証する。認証されないならログインできない。業者に頼むなら、ＤＢに予め、ＩＤ：guest、パスワード：guest など登録して、使ってもらう。これなら、他のユーザーのＩＤやパスワードはわからないよね。（そのＤＢにアクセス（READ）権限とアカウントがあったら無駄ですが）

33791	Re:セキュリテイについて (注意：エセ回答です信用しないで・・・)	kei100 URL	8/1-12:52
記事番号33750へのコメントお久しぶりです、kei100@エセ回答人です aaさんは No.33750「セキュリテイについて」で書きました。 >OS名：Windows98 >こんばんは。いつもお世話になります。 >私の会社でCGIを使って >ある操作をお客様にやってもらおうと思っています。 >そこでメールでIDやパスワードをURLに埋め込んで >そのアドレスにアクセスしてもらおうとしたところ >ある人からセキュリティ上それはまずいといわれました。 >そこでダイアログボックスにID　パスワードを入力する >方式にかえたのですが >IDやパスワードをURLに埋め込むと >どういった危険があるのでしょうか？意味が沢山取れるのですがまず、メールで送る時点でDiscoveryさんの仰る問題がありますまた、もし http://www.hoge.page/cgi-bin/login?id=page&pass=page という実装だった場合 Refer(綴り怪しい)問題が危ないと思われます Referとは、httpの機能の1つで「閲覧者が直前まで見ていたページのアドレスを送信する」という機能だったはずですこれが意味するものは「閲覧者がどこかのリンクをクリックすると、idとpassがそのままどこかのサーバーのログに残る」ということですそれも、クリックした人には全くそんな意識はありませんしかも、refer(逆リンクとかRinkと呼ぶ方々も居られるようです) を収集＆見てみる行為は日常的に行われていますご注意くださいそういや、過去にIEのバグ(仕様?)で、post使っても引数?が暴露されるってのがあったようなまた、貧弱なCGIの実例としてどこかのインターネット通販の事例だったと思いますが http://hoge.page/cgi-bin/catalog?id=XXXXXX となっていて id=を適当に変えると他の人の注文も見れてしまうと言うお粗末な仕様の所もあるようですまた、cgi-bin 内にデータファイルを置いてしまうということも良くありますこの場合、httpdの設定が悪いと「http://hoge.page/cgi-bin/data/passwd.dat」なんてとこに置いてた場合、上記URLにアクセスするだけで「データを見れてしまい」ますたちが悪い事に「法律で侵入と見なされにくい」です理由ですが、公開される可能性がある場所に置いた時点で「そのデータは公開されたもの」と見なされるからでしょうその実例ですが「クレジットカード番号を先ほどの例のような場所に置いてあり」かつ「ロボット検索に見つけられてしまった」ということがありますこれが意味するのは「ロボット検索でそれらしい言葉を入れればそのお店を使った人々のカード番号を全て見れる」というかなり不味い事になりますまた、HTTPプロトコルもプレーンテキストです送受信する内容は全く保護されておりませんハイパーターミナル(もしくはTera Term Proとかで) 接続先をwww.yahoo.co.jpとしてポートを80にし GET /[Enter] [Enter] と打てばそのままデータが見えます EUCだから文字化けするかもしれないけど [Enter]は改行キーを押してネ、あと改行は「CR+LF」ですとりあえず、文中の「ある人」の意見を良く聞くことがベストでしょう・・・詳しいみたいですし・・・正攻法かどうかは知りませんが https+cookie+乱数のhiddenをセッション毎に発行というのが強力らしいです(噂だからね・・・あくまで) cookieだって詐称は簡単に出来るのであくまで補助にとどめたほうが・・・ # 間違ってもcookieで認証はしないほうが良いと思う・・・ # 特にユーザーIDだけで通しちゃうような実装はさて、色々書きましたが話半分で聞いてください言ってる本人も正しいかどうか解ってません(爆死) # エセ解答者と言われる所以ですなでは。

パソコントラブル解決・過去ログTOP > ログTOP > セキュリテイについて

何か一言(本ページで参考になったならないを含めて残してあります)
◎：解決　○：参考になった　×：参考にならなかった　！：アドバイスあり

参考	回数	投稿日時	何か一言
◎	初めて	2004/02/06/(金) 21:17:53	MSIE6/WinMe