RE: active perl on IIS
Lynn, I've installed ActiveStates Perl a couple of times on Win 2K NT and each time, as part of the install, it allowed/prompted for the configuration of the ISAPI part which basically meant you can run perl as an active x scripting engine. SCRIPT LANGUAGE=perlscript runs fine then. I seem to remember that CGI still works fine and they had some sort of speedy up extra module to make it go faster - kinda like a mod_perl for IIS I suppose - anyway, that is an aside. Ok, back to the point. Oreilly do a WIN32 Perl book - I've found it very good. http://www.amazon.com/exec/obidos/ASIN/1565923243/qid=999111590/sr=8-1/ref=a ps_sr_b_1_1/102-3850428-7506526 Have you got any test perl scripts running on your IIS box? I THINK you need to: 1) create a folder to house the cgi-bin 2) mark that folder as executable 3) put your perl (.pl) program in that. Don't think you need the shebang in win32. Can you try a simple hello world cgi program? You can always convert to an ASP PerlScript? You know, the form submits to itself and the serverside code does whatever and the send HTML back Can you post your perl code, html, where you put them in respect to eachother on the webserver, execute permissions of the folders etc. regards joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 29 August 2001 19:38 To: [EMAIL PROTECTED] Subject: active perl on IIS Can anyone point me to a site or book with detailed information about configuring my W2K server IIS for perl and cgi? I have a form which I designed at work on Linux and Apache, and it works fine in that environment. I want to run it on my home W2K machine, but am baffled. My coworkers are no help because they all work on *nix machines. I installed activeperl and followed the configuration directions at the activeperl site but after clicking submit on my form I get the page cannot be displayed. The active perl example pages work correctly, but they have the perl script imbedded in the html page, unlike what I want to run which is a separate html file and perl script. I'm not expecting anyone in this group to walk me through it, unless you want to :), but can you point me to a helpful source? I did change the path in the form action tag, but there is probably something else simple I am forgetting in this port from unix to windows. On apache, I check error_log, is there an equivalent log file for W2K IIS? Thanks, Lynn -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
script not running
Hi there, I try to get the attached sript running on a Linux Apache Server 1.3.20. What I receive is a error 500 and the logged error message: (2)file or driectory not found: exec of /var/www/html/cgi-bin/ping012 failed Premature end of script headers: /var/www/html/cgi-bin/ping012 Another script - the demoscript printenv - is running just fine. Wher eis my problem or failure? Thanks peter PING012 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Win32 Apache and Perl
Hi all, I'm trying to set up a localhost Apache server to test my scripts on before launching on to the web, but am seeming always to need to put the win32 shebang (#!C:\perl\bin\perl.exe) at the start of scripts instead of the usual unix one (#!/usr/bin/perl) to make them work. Is there any way (I'm sure there is) to make my perl scripts run with the standard unix shebang instead? Thanks! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Win32 Apache and Perl
On Fri, 31 Aug 2001, Shannon Murdoch wrote: Is there any way (I'm sure there is) to make my perl scripts run with the standard unix shebang instead? Yes, use Unix. :-) If you are usig ActiveState, you have to use the Windows way of using pathnames. If you are using CygWin (which is a POSIX emulation layer for Win32), you can use the Unix-style shebang line with CygWin's version of Perl. -- Brett http://www.chapelperilous.net/ In the fight between you and the world, back the world. --Frank Zappa -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Win32 Apache and Perl
At 03:59 PM 9/1/2001 -0400, Brett W. McCoy wrote: On Fri, 31 Aug 2001, Shannon Murdoch wrote: Is there any way (I'm sure there is) to make my perl scripts run with the standard unix shebang instead? Yes, use Unix. :-) So helpful for the Operating System challenged. :) If you are usig ActiveState, you have to use the Windows way of using pathnames. If you are using CygWin (which is a POSIX emulation layer for Win32), you can use the Unix-style shebang line with CygWin's version of Perl. Brett, are you sure that this is the end of the story? The parsing of the shebang line is not purely a function of the Operating System layer (as you suggest using CygWin) but is also a function of Apache (specificially on Win32). I have tried and was successful with the following technique 3 years ago, but I do not know whether such a technique will still work. The premise is that Apache (on Win32 -- this is a special feature of Win32 Apache) already understands #!c:\perl\bin\perl.exe. It's actually a *really nice* feature because it allows you to enable warnings and taintmode without mucking about with the the file association registry stuff -- I could go off on a soapbox now about this but I won't. But, when I experimented with different things I found that Apache could interpret and understand by itself, the following things in Win32: a) #!c:\perl\bin\perl Taking of .exe works b) #!c:/perl/bin/perl switching the backslashes representation works. c) and a final experiment #!/perl/bin/perl Shows that Apache understood that it was also installed on the C: drive and therefore did not need the pointer to let it know to find Perl there. So this would lead us to figuring that #!/perl/bin/perl could be made to look like /usr/bin/perl. How? Easy enough I think. I basically installed Perl into c:\usr instead of c:\perl so that bin was under c:\usr\bin. And that worked for me. I can't say if this still works but if Apache is doing the interpretation I don't see why not. Note that this is an Apache feature -- this won't help you with brain dead web servers like IIS that make it really hard to set up CGI/Perl. But since the question was specifically about Win32 Apache, I've obliged to talk about it. One other note is that rather than going through another ActiveState Perl install into \usr, I think that you can simply make a copy of perl.exe in c:\usr\bin\ and keep your perl distro where it is as the registry or some other setting in windows actually knows that the Perl distro for that binary is in c:\perl and so this technique can be tried out in an even *easier* fashion than my first suggestion. Shannon, if you would be so kind, I would be interested to know this technique still works if you end up trying it. Good Luck, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it a security risk to use identical names for database fields and html forms?
At 02:29 PM 8/31/2001 +0100, yahoo wrote: nah! what difference does it make? I mean, if they guy gets access to your DB server then he's gonna find out the fieldnames anyway! If he can't get access to your DB then what has he got?, a few POSSIBLE DB field names (i mean, how does HE know the names are real?) for him to attempt to recreate fragments of the data model pah! best of luck... joel Joel, while I do think that this is a nice succinct reply to the thread, I am not sure that it really uncovers the entire problem. It's a bit hard to understand what you mean in your post as you don't really qualify the phrase access to the DB. Sure, if I have a TCP stream to mySQL, it's possible to get anything. But access to a database through exploiting CGI is not always perfect and therefore being able to glean extra information is helpful to any cracker on the system. I do firmly believe that restricting the information you give the user about your system will help security, but I also think it is a matter of diminishing returns and would rather the user who asked the question focus on the things I highlighted in my post yesterday (eg quoting issues, data validation, etc). If the SQL is exploitable, then mucking about with the fields whose values are obvious candidates for being sent to the database makes a difference. But further, it does make a difference to know about the field naming when it comes to extrapolating how to generate the rest of the query. Do you really think that this is inconceivable? The following URL is a well-written account of rain forest puppy hacking into a BBS forum software by exploiting it's error handling routines to gather some bits of information about how the queries are being created and exploiting that information through the CGI script. http://www.wiretrip.net/rfp/p/doc.asp?id=42iface=2 Since I read this article and then in reviewing the security of other CGI scripts, I have found exploitable SQL code in at least several places. I guarantee that bad SQL coding is a problem for sure in the latest CGI scripts. But the degree varies from application to application. Just as seeing one cockroach in a kitchen actually entails a million more behind the walls, since reviewing CGI security is not a full time job for me (just an occasional if someone asks me), the fact I have seen this much exploitable code is an indicator to me that the problem is currently quite huge. In summary, I would heartily encourage careful best practices for SQL coding in Perl as I indicated yesterday and as RFP describes in the URL I gave above. And I would agree that the form variable changing names is probably not that useful to avoid attack, but I would not agree that it's entirely useless. I think risk assessment is a reasonable thing for this person to have asked about on this list, and shows a smart attitude towards security. Especially this person questioning why his colleague suggested doing this. Implementing old wive's tales of security (eg knock on wood, don't walk under ladders, untaint all your form input) without understanding the why behind it is sometimes just as bad as not having implemented the solution at all. For example, as I pointed out yesterday, if you obfuscate your form, you'll make creation and subsequent maintenance of the program much harder because it will be yucky to constantly convert from obfuscated form variable to real database field. Unclear code leads to bugs, and by probability some bugs are security bugs. Anyway, I apologize if I misunderstood the intent of your reply to the thread, but I personally had found it sufficiently vague that I wasn't sure what you were really advocating or thinking was the risk here. Later, Gunther -Original Message- From: Michael R. Fahey [mailto:[EMAIL PROTECTED]] Sent: 31 August 2001 13:33 To: [EMAIL PROTECTED] Subject: Is it a security risk to use identical names for database fields and html forms? Hi, I was looking at a perl script where the developer used different names for the incoming parameters and the database field names. He told me that this was done for security reasons-- to ensure that malicious users would not be able to discover the field names in the database being updated or queried. How dangerous is this? I think it would be easier to work with a hash of parameters from the input form. I'm using cg.pm, DBI, and postgresql. Thanks. Michael Fahey -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ -- To unsubscribe,
Re: Win32 Apache and Perl
On Sun, 2 Sep 2001, Gunther Birznieks wrote: I can't say if this still works but if Apache is doing the interpretation I don't see why not. Note that this is an Apache feature -- this won't help you with brain dead web servers like IIS that make it really hard to set up CGI/Perl. But since the question was specifically about Win32 Apache, I've obliged to talk about it. I stand corrected then! Does Apache interpret the shebang line before running the script? I've had problems with Apache *requiring* the correct drive and pathname for other things in its configuration under Win32. -- Brett http://www.chapelperilous.net/ I'll burn my books. -- Christopher Marlowe -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Win32 Apache and Perl
Yes, Apache interprets the shebang line before running the script- the script needs to point to the OS-dependant path to Perl before it will run. -Shannon I stand corrected then! Does Apache interpret the shebang line before running the script? I've had problems with Apache *requiring* the correct drive and pathname for other things in its configuration under Win32. -- Brett http://www.chapelperilous.net/ I'll burn my books. -- Christopher Marlowe -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Win32 Apache and Perl and IIS
I set this up on a Win98 machine a few months ago, and I there is a place in the Apache httpd.conf to choose whether a shebang line is interpreted or if Perl's location is taken from the registry: #takes Perl location from registry: ScriptInterpreterSource registry #takes Perl location from shebang line ScriptInterpreterSource script Also, there were some grumblings about getting Perl to work with IIS. Simple solution: get Win32 Apache and use that as your home server. HTH Ryan - Original Message - From: Gunther Birznieks [EMAIL PROTECTED] To: Brett W. McCoy [EMAIL PROTECTED] Cc: Shannon Murdoch [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 01, 2001 11:05 PM Subject: Re: Win32 Apache and Perl At 11:16 PM 9/1/2001 -0400, Brett W. McCoy wrote: On Sun, 2 Sep 2001, Gunther Birznieks wrote: I can't say if this still works but if Apache is doing the interpretation I don't see why not. Note that this is an Apache feature -- this won't help you with brain dead web servers like IIS that make it really hard to set up CGI/Perl. But since the question was specifically about Win32 Apache, I've obliged to talk about it. I stand corrected then! Does Apache interpret the shebang line before running the script? I've had problems with Apache *requiring* the correct drive and pathname for other things in its configuration under Win32. I believe it does. But I am not sure what you mean by other things in its configuration. Are you talking about other things in httpd.conf or other things in your Perl script? If the httpd.conf, I can say that one thing that Win32Apache hates is spaces in directories. Or at least it did 3 years ago. I really haven't used Win32Apache recently. I tend to use Netscape under Windows because it is nicer than IIS and I can test both Velocigen and PerlEx for accelerated Perl. I used Linux and Solaris to test mod_perl and Speedy::CGI stuff. If you are talking about problems with the perl script running under Apache, then I would require more detail about what you meant by a problem before venturing a guess as to what might have been wrong. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
