telnet.cgiについて
Tsuyoshi Okazaki
最近になって、会社の意向でサーバーをお客様にレンタルすることになりました。
そこで一つ気になるのがtelnet.cgiの事です。
お客様には、当然cgiを利用していただきますが、telnet.cgiはさすがに困ります。
これを防ぐことはできるでしょうか？
宜しくお願い致します
Koshiro Miura/三浦侯史郎
>最近になって、会社の意向でサーバーをお客様にレンタルすることになりました。
>そこで一つ気になるのがtelnet.cgiの事です。
>お客様には、当然cgiを利用していただきますが、telnet.cgiはさすがに困ります。
>これを防ぐことはできるでしょうか？
/bin/falseをシェルとして設定するのが一般的です。こうしておくとtelnetなど
を利用してアクセスし、ログインIDとパスワード入れて認証に成功しても、すぐ
にコネクションを切断されますので、ユーザーはシェルを利用できず安全な運用
ができます。（MkLinux ネットワーク構築術 山口亮 ナツメ社 Page 64）
=========================
Koshiro Miura
kos...@aqu.bekkoame.ne.jp
=========================
hinesuke
ソース読んでからCGI導入を許可するとか．
> /bin/falseをシェルとして設定するのが一般的です。こうしておくとtelnetなど
> を利用してアクセスし、ログインIDとパスワード入れて認証に成功しても、すぐ
> にコネクションを切断されますので、ユーザーはシェルを利用できず安全な運用
逆なような気がしますが．．．
telnet.cgiとやらから外部にtelnetされるのが嫌なのじゃないのですか？
ってゆーか，falseを使えば確かにクローズされると思いますけど，
他のアカウントはどうするんですか？
全てのアカウントがfalseですか？
それなら，in.telnetd自体が必要ないと思います．
安全な運用と言いますけど，特定ユーザのみにtelnet開けて置くのは安全な運用なの
ですか？
Tuyoshi Okazaki
すいません。説明が足りませんでした。
hinesukeさんの言われるとおり、telnet.cgiを使われる事がいや
なのです。
telnet自体は、port23を含め塞いでおります。
しかし、telnet.cgiをaliasにアップロードすると、誰でもtelnetが使える
様にになってしまいます。
> 出て行く23をふさぐとか．
> ソース読んでからCGI導入を許可するとか．
出ていく23を塞ぐとはどういう事でしょうか？
また、ソースを読んでCGIを許可するとは、httpd.confの設定では
無いですよね？
よろしくお願いいたします。
T.SHIOZAKI
塩崎です。
From: "Tuyoshi Okazaki" <oka...@iris-sys.gr.jp>
Subject: [linux-users:83360] Re: telnet.cgiについて
Date: Thu, 10 May 2001 20:56:22 +0900
Message-ID: <001c01c0d948$3bc4cd80$0300a8c0@camus>
> すいません。説明が足りませんでした。
> hinesukeさんの言われるとおり、telnet.cgiを使われる事がいや
> なのです。
> telnet自体は、port23を含め塞いでおります。
> しかし、telnet.cgiをaliasにアップロードすると、誰でもtelnetが使える
> 様にになってしまいます。
「telnet.cgi」では、これがどういうプログラムなのかわかりません。
なんとなく推測はできますが、次のうちのどれなのかがわかりません：
1. telnet.cgi を起動すると、そのサーバに telnet をかけてログインできる
2. telnet.cgi を起動すると、そのサーバから他のマシンに telnet をかけられる
3. それ以外の何か with 任意
で、hinesuke さんの言ってるのは 2 ですが、あなたのいう telnet.cgi は
どれでしょう?
ちなみに、任意の CGI を置くことを許可したら、
そのユーザ権限でできることは基本的に何でもできます。
私が悪意あるユーザだったら、このサイトは簡単に踏み台などに使えますし、
(純粋にソーシャルな面から判断して)おそらく root すらも取れるんじゃないか、
という気がしてきます。
ここで極力 root を取られないようにするノウハウはあるにはあるけど、
一朝一夕では無理なので高い金を払って外から人ごとノウハウを買うか、
時間かけて勉強する必要がありますし、それは一時的なものではなくて、
サーバを運用している間ずっと継続的なコストとしてかかってくることは
指摘しておきます。
> > 出て行く23をふさぐとか．
> > ソース読んでからCGI導入を許可するとか．
>
> 出ていく23を塞ぐとはどういう事でしょうか？
> また、ソースを読んでCGIを許可するとは、httpd.confの設定では
> 無いですよね？
つまり、自分の会社に「アップロード担当」を用意して、
検証してからアップロードする、ということです。
本当に厳格にセキュリティを守るには、
そういうローテクに落とさざるをえません。
それがセキュリティに伴う犠牲というものです。
だから、どこかでトレードオフが必要になります。
そのトレードオフの判断も、ノウハウが必要になりますな。
では。
--
Takuya SHIOZAKI / ASTEC Products, Inc.
paoneko
> 最近になって、会社の意向でサーバーをお客様にレンタルすることになりました。
> そこで一つ気になるのがtelnet.cgiの事です。
> お客様には、当然cgiを利用していただきますが、telnet.cgiはさすがに困りま
す。
> これを防ぐことはできるでしょうか？
具体的に何が困りますか？
telnet.cgiを置こうとするのは、そのお客様ってことになりますよね。困るとすれ
ば、置いたお客様本人になるはずです。
ちゃんとした設定さえすれば、サーバーそのものが困ることにはならないはずですけ
ど。
hinesuke
> > 出ていく23を塞ぐとはどういう事でしょうか？
> > また、ソースを読んでCGIを許可するとは、httpd.confの設定では
> > 無いですよね？
>
> つまり、自分の会社に「アップロード担当」を用意して、
> 検証してからアップロードする、ということです。
> 本当に厳格にセキュリティを守るには、
> そういうローテクに落とさざるをえません。
> それがセキュリティに伴う犠牲というものです。
> だから、どこかでトレードオフが必要になります。
> そのトレードオフの判断も、ノウハウが必要になりますな。
おっしゃる通りだと思います．
それが出来ないのであれば，CGI設置は許可すべきではないと思います．
どうしてもCGIをおきたい，でもtelnet.cgiは動かしたくない，いちいちソースを読
んでる暇がないというのなら，
Webサーバからインターネットに出て行くポート23のパケットを許さないという形も
あるのでは，
ということです．
あくまでもtelnet.cgiに関するとこだけですけど．
個人的には自分が書いたもの以外は自分のサーバでは置きたくないですけどね．
T.Kabu
こんにちは、蕪木＠ＢｉＧです。
okazaki> 最近になって、会社の意向でサーバーをお客様にレンタルすることになりました。
okazaki> そこで一つ気になるのがtelnet.cgiの事です。
okazaki> お客様には、当然cgiを利用していただきますが、telnet.cgiはさすがに困ります。
okazaki> これを防ぐことはできるでしょうか？
ＣＧＩを「www」権限で動かされるとかなり困るでしょうから、別の
ユーザー権限で起動させるというのはどうですか？
それができないなら（というかそんなにユーザーが信用おけないなら）
ＣＧＩなんて使わせないのが身のためです。
---
Takeshi Kaburagi
Mail Official : ka...@big.or.jp / Private : ka...@fwnet.or.jp
HomePage : http://www.fwnet.or.jp/~kabu/
Takashi SHIRAI
In Message-Id <v04210a00b720278ea9ba@[63.12.50.92]>
Koshiro Miura/=?iso-2022-jp?B?GyRCOzAxOjh0O0tPOhsoQg==?= <kos...@aqu.bekkoame.ne.jp>さんwrites:
> 侯史郎＠初心者.博多です。
> /bin/falseをシェルとして設定するのが一般的です。こうしておくとtelnetなど
> を利用してアクセスし、ログインIDとパスワード入れて認証に成功しても、すぐ
> にコネクションを切断されますので、ユーザーはシェルを利用できず安全な運用
> ができます。（MkLinux ネットワーク構築術 山口亮 ナツメ社 Page 64）
他の問題点はともかくとしても、false の実装手段は OS 依存な
ので「一般的」とは言い難いでしょう。
多くの Linux distribution では binary executable file にな
っていますが、単なる shell script で実装される場合もあり得ま
すので、もし何らかの理由でこの手法を使う場合は先に確認してか
らにしましょう。
Linux で共通なのは kernel とその周辺のみで userland 部分の
実装は共通している保証がありませんから、distribution 単位で
の確認が必要になってきます。
＃ 代りに /bin/nologin を作りましょう。「exit 1」なんて書い
＃てあるだけの /bin/false 使うくらいなら /dev/null 使った方
＃がまだ安全です。
しらい たかし
Tiki Tiki
----- Original Message -----
From: "paoneko" <pao...@e-game.co.jp>
To: <linux...@linux.or.jp>
Sent: Thursday, May 10, 2001 9:27 PM
Subject: [linux-users:83363] Re: telnet.cgiについて
>
> > 最近になって、会社の意向でサーバーをお客様にレンタルすることになりまし
Tsuyoshi Okazaki
ここで、telnet.cgiを載せてていいのか悪いのか、迷いましたが、
有名な物なので、みなさまもご存じと思い、載せる事にしました。
以下がそのコードです。作者情報などは削除させていただきました。
#!/usr/bin/perl
#
$ownname="http://$ENV{'SERVER_NAME'}$ENV{'SCRIPT_NAME'}";
$ENV{'PATH'} = '/bin'
. ':/usr/bin'
. ':/usr/ucb'
. ':/etc'
. ':/usr/etc'
. ':/usr/lib'
. ':/usr/local/bin'
. ':/usr/local/X11R6/bin'
. ':/usr/local/bin/mh'
. ':/usr/local/lib'
. ':/usr/local/lib/mh'
. ':/usr/local/sbin'
. ':/usr/local/libexec'
. ':/usr/local/canna/bin'
;
($dir,$cmd)=split('&',$ENV{'QUERY_STRING'}); # & で分離 dir=????&cmd=
$dir =~ s/dir=//;
$dir =~ s/%(..)/pack('c',hex($1))/ge;
$cmd =~ s/cmd=//;
$cmd =~ s/\+/ /g;
$cmd =~ s/%(..)/pack('c',hex($1))/ge;
$|=1;
print "Content-type: text/html\n\n";
print '<HTML><BODY>';
print "<PRE>\n";
chdir("$dir");
$wd=&pwd;
print "Curr Dir:$wd\n";
$cmdpr = $cmd;
$cmdpr =~ s/&/&/g;
$cmdpr =~ s/</</g;
$cmdpr =~ s/>/>/g;
print "\n<B>>$cmdpr</B>\n";
if ($cmd =~ /^cd(\s)*/ ) { # cd は、内部で処理する。
unless (chdir($')) {
print "cd $':not success.\n";
}
$dir=&pwd;
print "Curr Dir:$dir\n";
} else {
open(PROC,"$cmd 2>&1 |"); # 実行
while (<PROC>) { # 結果を読み出す
s/</\001/g; #
s/>/\002/g; #
s/(.)(\x08\1)+/<B>$1<\/B>/g; # 多重打ち : . 08h(BS)
.
s/_\x08(.)/<U>$1<\/U>/g; # アンダーライン : 5fh(_)
08h(BS)
s/o\x08\+/<S>X<\/S>/g; # リストマーク : 35h(o)
08h(BS) 2bh(+)
s/<\/(.)><\1>//g; # </TAG><TAG> を削除
s/&/&/g; #
s/\001/</g; #
s/\002/>/g; #
print $_;
}
close(PROC);
}
print "</PRE>\n";
print '<HR>';
print '<FORM ACTION="' . $ownname . '" METHOD="GET">';
print '<INPUT TYPE="hidden" NAME="dir" VALUE="' . $dir . '">';
print '<INPUT TYPE="text" NAME="cmd" SIZE=80 VALUE="' . $cmd . '">';
print '<INPUT TYPE="submit" VALUE="Send">';
print '</FORM>';
print '</BODY></HTML>';
exit;
sub pwd {
use Cwd;
$wd = Cwd::getcwd();
unless ($wd) {
$wd='/';
}
return $wd;
}
以上です。
ちなみに試した見ましたが、やはりほとんど事
（ファイルを消すなど）が可能です。
Inoue Hajime
> それが出来ないのであれば，CGI設置は許可すべきではないと思います．
> どうしてもCGIをおきたい，でもtelnet.cgiは動かしたくない，いちいち
> ソースを読んでる暇がないというのなら，
> Webサーバからインターネットに出て行くポート23のパケットを許さない
> という形もあるのでは，
> ということです．
> あくまでもtelnet.cgiに関するとこだけですけど．
> 個人的には自分が書いたもの以外は自分のサーバでは置きたくないですけどね．
telnet.cgi とは telnet 風に shell のコマンドを実行できる
cgi ということで、ポート23 は使わないと思います。
従ってポート23 を塞いでも無意味だと思います。
多分、telnet.cgi をブラウザで表示 → 表示されたフォームの
<input type="text" ...> にコマンドを入力して送信ボタンを
押す → telnet.cgi がコマンドを受け取って → shell に渡す
→ 処理経過・結果を pipe で受け取ってブラウザに返してくる
という仕組みなのではないでしょうか。
google で検索したページを見ると動作するプロバイダとしない
プロバイダがあるということなので、何か設定で回避できるのかも
しれません。
hinesuke
なるほど，私が勘違いしてた以上に単純にヤバイですね．
どうもすみませんでした．
この手のものを見ると，IISのセキュリティホールを思い出しますね．
Solarisに感染して，IISのセキュリティホールを突いて改ざんしまくるってワームが
発見されたらしいですけど．
すいません．
全く関係ない方向に話がそれました．
やっぱり，ちゃんとソース渡しにしてもらって(CもしくはC++なら自分でコンパイル
して)，
バッファ溢れる事が無いか，とか確認して，って言う方が良いと思うけどな．
それか，全く使わないか．
確かに蕪木さんのおっしゃる通り，別ユーザの権限で動かせば，
このtelnet.cgiのみに関しては有効だと思います．
でもperlなら，この手のものって大量生産できるから，
設定で防ぐって言うのは，管理が大変になるだけのような気がします．
paoneko
> ちゃんとした設定さえすれば、サーバーそのものが困ることにはならないはずです
け
> ど。
これだけじゃ、あまりにもなんで、もう少し。
chroot環境でWWWサーバー（Apache ?）を動かしてみましょう(^-^)
Tsuyoshi Okazaki
今、自宅から加入プロバイダのサーバーに
telnet.cgiをアップしてみました。
すると、動作はしたのですが、ルートディレクトリから上には
行けませんでした。
これであれば、取りあえずそんなに危険ではないと思うのですが、
設定が分かりません。
私なりに考えて、userをftpのみを許可してみましたが、
（ /etc/passwdのgroupidをftp専用アカウントにし、
/bin/bashを/dev/nullにした）
やはり、自由にコマンドが通りました。
どのようにすれば、プロバイダのような設定ができるのでしょうか？
Tomotada Ando
本題とは別の話。
Tsuyoshi Okazaki wrote in <006e01c0d94f$fb92f590$0300a8c0@camus>
>ここで、telnet.cgiを載せてていいのか悪いのか、迷いましたが、
>有名な物なので、みなさまもご存じと思い、載せる事にしました。
>以下がそのコードです。作者情報などは削除させていただきました。
そのソースに作者情報などが書かれていたということは、転載の許可などの
著作権情報や連絡先などがかかれているはずですので、確認をしないままの転
載はやはりまずいんじゃないでしょうか。
作者情報を削除した場合はソースの改ざんになる形ですので、多くの場合、作
者は許可していないと思います。
googleなどで情報が検索できるということなので、せめてポインタを示す程度
にとどめておいたほうがよかったと思います。
--
Tomotada Ando
mailto:t-a...@fsas.fujitsu.com
Takeaki Kato
Tomotada Ando <t-a...@fsas.fujitsu.com>さんは
<200105102352...@ns1.fsas.fujitsu.co.jp>で書きました
> Tsuyoshi Okazaki wrote in <006e01c0d94f$fb92f590$0300a8c0@camus>
> >ここで、telnet.cgiを載せてていいのか悪いのか、迷いましたが、
> >有名な物なので、みなさまもご存じと思い、載せる事にしました。
> >以下がそのコードです。作者情報などは削除させていただきました。
>
> そのソースに作者情報などが書かれていたということは、転載の許可などの
> 著作権情報や連絡先などがかかれているはずですので、確認をしないままの転
> 載はやはりまずいんじゃないでしょうか。
非常に問題かと。
どこかで配布されているとしたら、配布条件があるはずですが、再配布
可能と言う条件だったとしても、「作者情報」を削除しない事が、再配
布の条件になっている事が、ほとんどだと思います。
> 作者情報を削除した場合はソースの改ざんになる形ですので、多くの場合、作
> 者は許可していないと思います。
御意。
＃ふりーそふとって、著作者人格権を尊重してくれれば、著作権には寛
＃容にしてくれているものが多い訳なので、何が何でも、作者情報って
＃けずっちゃだめだと思うのよ。
＃それが、作者への感謝の意を表す事にもなる気がする。
---
加藤 丈明
富士通（株） ＩＡサーバ事業部 保証技術部
Tel:0559-24-7514 Fax:0559-24-6194
内線Tel:7551-3707 Fax:7551-3703
e-mail:ka...@qa.psd.cs.fujitsu.co.jp
Takeaki Kato
少し、言葉が足りなかったので、追伸です。
Takeaki Kato <ka...@qa.psd.cs.fujitsu.co.jp>さんは
<2001051100...@fs1.qa.psd.cs.fujitsu.co.jp>で書きました
> > 作者情報を削除した場合はソースの改ざんになる形ですので、多くの場合、作
> > 者は許可していないと思います。
>
> 御意。
今回の場合は、一番いい方法は、
Tomotada Ando <t-a...@fsas.fujitsu.com>さんは
<200105102352...@ns1.fsas.fujitsu.co.jp>で書きました
> googleなどで情報が検索できるということなので、せめてポインタを示す程度
> にとどめておいたほうがよかったと思います。
これだと思います。
＃ごめんなさい。編集中に、大事な所を消してしまって、そのまま、出
＃してしまいました。
Masahiro YAMAZAKI
やまざきです。
On Thu, 10 May 2001 23:19:25 +0900
"Tsuyoshi Okazaki" <oka...@iris-sys.gr.jp> wrote:
> 今、自宅から加入プロバイダのサーバーに
> telnet.cgiをアップしてみました。
> すると、動作はしたのですが、ルートディレクトリから上には
> 行けませんでした。
それはそういう設定がなされているサーバーだからですよね？
telnet では、ログイン先が / になるサーバーも、telnet.cgi から(正確には
httpd から)は、 /home/user/ とかになっちゃうサーバーもある。
この telnet.cgi が httpd と同じ権限で動いていますので、同一サーバーのCGI
が作ったファイルを消すことも可能なんですけど、これって telnet.cgi じゃな
くても適当なcgiを使えば同じことができます。
よって、telnet.cgi を使えないようにするのではなく、telnet.cgi を使われて
も大丈夫なサーバーを構築しなければならないですね。(suexec とか chroot と
かいろいろ使って)
--
Masahiro YAMAZAKI / ym...@wizvax.net
Takeaki Kato
なにをされるのが嫌なのか、明確にした方がいいのでは？
"Tsuyoshi Okazaki" <oka...@iris-sys.gr.jp>さんは
<00dd01c0d95c$368f3f30$0300a8c0@camus>で書きました
これは、プロバイダの設定ではなく、cd を、shell ではなく、cgi の
方で処理するように変えてあるからいけないだけで、４～５行書換えて
やれば、cgi の実行者のパーミッションで許されているディレクトリに
は自由に cd できますよ。
telnet.cgi だと、cgi の変更なしで任意のコマンドを実行出来るだけ
で、その都度 cgi を書換えれば、どんなコマンドでも叩けます。
（ls -al /etc だって出来る。いま、書いてみたけど、８行ぐらい。）
アカウントに、ログインシェルがなくても、ls.cgi だとか、cat.cgi
だとか、自分のやりたいコマンドの数だけcgiを準備すれば、
telnet.cgi は不必要で、cgi の実行者の権限のあるコマンドは、叩き
放題です。
Tsuyoshi Okazaki
> そのソースに作者情報などが書かれていたということは、転載の許可などの
> 著作権情報や連絡先などがかかれているはずですので、確認をしないままの転
> 載はやはりまずいんじゃないでしょうか。
>
> 作者情報を削除した場合はソースの改ざんになる形ですので、多くの場合、作
> 者は許可していないと思います。
> googleなどで情報が検索できるということなので、せめてポインタを示す程度
> にとどめておいたほうがよかったと思います。
そうですね・・・・
申し訳ない事を致しました。
作者に連絡を取ってみます。
ご迷惑をおかけしました。
Tsuyoshi Okazaki
> よって、telnet.cgi を使えないようにするのではなく、telnet.cgi を使われて
> も大丈夫なサーバーを構築しなければならないですね。(suexec とか chroot と
> かいろいろ使って)
なるほど、chrootコマンドを施せば、その上のディレクトリには影響が出ない
と言う事ですね。
ありがとうございます。
webmaster
> アカウントに、ログインシェルがなくても、ls.cgi だとか、cat.cgi
> だとか、自分のやりたいコマンドの数だけcgiを準備すれば、
> telnet.cgi は不必要で、cgi の実行者の権限のあるコマンドは、叩き
> 放題です。
変な質問をして申し訳ないのですが、cgiはnobody権限で動くのでは
無いでしょうか？
nobodyに権限のある危険なコマンドというのはどういうのがあるので
しょうか？
Noriyuki SATOH
たとえば、telnet.cgi で telnetを他のサイトに
% telnet mail.hoge.moge smtp
とかしてガツンとSPAM送るとかはどうですかね？(わらい
shellアカウント使えるってのは、結構、危険っすよ。
paoneko
From: "webmaster" <webm...@camus-net.co.jp>
> 変な質問をして申し訳ないのですが、cgiはnobody権限で動くのでは
> 無いでしょうか？
> nobodyに権限のある危険なコマンドというのはどういうのがあるので
> しょうか？
設定次第なので必ずnobodyで動くわけじゃありませんが、nobodyだったとしても、
suEXECやchrootされてない場合、/tmp や /var/tmp等にファイルを作ってディスクフ
ルにさせる。それでもしパーティションが適切に切られてなければシステムダウンの
可能性もあります。
また、/etc/passwdを見ることによって、何かにつけいるチャンスを与えるかも知れ
ません。（見られても必ずしもどうにかされるとは限りませんけど。）
どこかが適切な設定でない場合、他にも不適切な設定がある可能性もあるわけで、そ
いうのを見つけられるかもしれません。
Masahiro YAMAZAKI
やまざきです。
On Sat, 12 May 2001 16:13:52 +0900
"paoneko" <pao...@e-game.co.jp> wrote:
> 設定次第なので必ずnobodyで動くわけじゃありませんが、nobodyだったとしても、
> suEXECやchrootされてない場合、/tmp や /var/tmp等にファイルを作ってディスクフ
> ルにさせる。それでもしパーティションが適切に切られてなければシステムダウンの
> 可能性もあります。
/tmp や /var が分けられていないマシンありますね。分けたがために /var が
常にフルになってるマシンもあるけど。
/var や /tmp でなくても /home をフルにさせる危険性もありますね。ってこと
で suexec でユーザーを分け、ユーザーホームの容量制限をかけないと危ないっ
てことですね。
> また、/etc/passwdを見ることによって、何かにつけいるチャンスを与えるかも知れ
> ません。（見られても必ずしもどうにかされるとは限りませんけど。）
> どこかが適切な設定でない場合、他にも不適切な設定がある可能性もあるわけで、そ
> いうのを見つけられるかもしれません。
ユーザーに見つけられる前に自分で見つけることが、望ましいけど……
Sugiura Shiro
<2001051102...@fs1.qa.psd.cs.fujitsu.co.jp>の記事において
ka...@qa.psd.cs.fujitsu.co.jpさんは書きました。
>> （ls -al /etc だって出来る。いま、書いてみたけど、８行ぐらい。）
えっ? 4行じゃないんですか？
#!/bin/sh
echo Content-type: text/plain
echo
ls -al /etc
汎用性を持たせても7行(多少おしこんだ感あり)です。
#!/bin/sh
echo Content-type: text/html
echo
echo "<HTML><HEAD><TITLE>sh</TITLE></HEAD><BODY>"
echo "<FORM><input type=text name=c></FORM><PRE>"
eval `echo $QUERY_STRING | sed -e 's/c=//' -e 's/%3[Bb]/\;/g' -e 's/\+/ /g'`
echo "</PRE></BODY></HTML>"
使うのに苦労するけどそれなりに汎用性のある短いのなら4行。
#!/bin/sh
echo Content-type: text/plain
echo
eval $QUERY_STRING
シェルスクリプトで cgi 書く時に、いきなり eval $QUERY_STRING と書く
のは危険という話はもう昔話になってしまったのか。
--
すぎうらしろう(Sugiura Shiro) E-mail : sug...@kt.rim.or.jp
[ Never talk to me in English! ]
うちのコンピューターは12か国語対応ですが私が日本語以外は非対応です
Sugiura Shiro
<2001051413...@shell.rim.or.jp>の記事において
sug...@kt.rim.or.jpさんは書きました。
>> 汎用性を持たせても7行(多少おしこんだ感あり)です。
>>
>> #!/bin/sh
>> echo Content-type: text/html
>> echo
>> echo "<HTML><HEAD><TITLE>sh</TITLE></HEAD><BODY>"
>> echo "<FORM><input type=text name=c></FORM><PRE>"
>> eval `echo $QUERY_STRING | sed -e 's/c=//' -e 's/%3[Bb]/\;/g' -e 's/\+/ /g'`
>> echo "</PRE></BODY></HTML>"
すんません、ちょっと訂正。
eval `echo $QUERY_STRING | sed -e 's/^c=//' -e 's/%3[Bb]/\;/g' -e 's/\+/ /g' -e 's/%2[Ff]/\//g'`
か
eval `echo $QUERY_STRING | sed -e 's/^c=//' -e 's/%3[Bb]/\;/g' -e 's/\+/ /g' -e 's/%2[Ff]/\//g' -e 's/%20/ /g'`
じゃないと、いまいちですね。
# 長くなってしまった。