RE: active perl on IIS
Hi Lynn, Your FORM ACTION=c:\inetpub\scripts\sl3.pl doesn't look right; if 'scripts' is a root level (or virtual root) directory then then path would be =\scripts\s13.pl. make that change andd see what happens. regards Joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 03 September 2001 06:15 To: Gunther Birznieks; yahoo; Begginers CGI Subject: Re: active perl on IIS I spoke too soon. I thought this was just a minor tweak, which it probably is ;), but the tweak is not what I thought it was going to be ... When I click the button to submit the form, instead of running the perl script I get the File Download dialog. If I choose the run the file from this location radio button - what I thought was going to be the solution - all my STDOUT is in a DOS window, and my CGI param calls don't get anything that I filled in on the form. At the end of my script I have some CGI to display in the browser that it is done, but instead those lines show up as in the DOS window. Like I had double-clicked the pl file. If I type in the path to the sl3.pl file in my browser, it executes correctly and displays those I'm done lines in my browser. I stared at the activeperl directions for configuring IIS and don't see what I'm doing wrong. .pl is associated at the top level down with the full path including perl.exe followed by %s %s. And it works if I go straight there. These html and pl files work fine with IE browser on NT and linux apache web server at work, and I'm still using IE browser, so I know the problem is my IIS configuration. Yes, in my free time I will look into running apache instead of IIS. Why do I get a file download dialog box? My html file is like this: FORM ACTION=c:\inetpub\scripts\sl3.pl METHOD=POST ENCTYPE=multipart/form-data [snipped] INPUT TYPE=SUBMIT NAME=Button VALUE=SendP /FORM _ 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]
RE: active perl on IIS
Sorry Lynn, should have specified a bit more why your form action 'didn't look right' to me. Basically you put an absolute file path to the perl file - specifying the drive letter etc. web servers deal in urls http:// or / or myfolder/file etc. c:\inetpub\wwwroot is the default document root for IIS so \ refers to directory c:\inetpub\wwwroot and \testfolder refers to c:\inetpub\wwwroot\testfolder - see? if you code a form action (or anchor link etc) as file absolute c:\inetpub etc the page will 'work' when you browse the website using a browser on the same machine as the webserver - because the file paths are still valid. Many webdesigners hit this issue when they upload a site only to see lots of broken images - the URLs are no longer valid. Trying out a similar example on my win2k laptop I found that submitting to a valid, tested form handling perl cgi script using a file absolute path resulted in the cgi script being returned to the browser. Now YOU clicked on run but, of course, this is too late - you are now running it OUTSIDE of the context of the IIS webserver - your client application (IE) knows nothing about CGI, the form submission you attempted etc. The CGI program NEEDED to be run within the context of the webserver where form variables etc were available to it and it could alter the response back to the client (internet explorer). To remedy this situation change your form action to /scripts/sl3.pl. hope this helps regards Joel -Original Message- From: yahoo [mailto:[EMAIL PROTECTED]] Sent: 03 September 2001 09:20 To: Begginers CGI Subject: RE: active perl on IIS Hi Lynn, Your FORM ACTION=c:\inetpub\scripts\sl3.pl doesn't look right; if 'scripts' is a root level (or virtual root) directory then then path would be =\scripts\s13.pl. make that change andd see what happens. regards Joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 03 September 2001 06:15 To: Gunther Birznieks; yahoo; Begginers CGI Subject: Re: active perl on IIS I spoke too soon. I thought this was just a minor tweak, which it probably is ;), but the tweak is not what I thought it was going to be ... When I click the button to submit the form, instead of running the perl script I get the File Download dialog. If I choose the run the file from this location radio button - what I thought was going to be the solution - all my STDOUT is in a DOS window, and my CGI param calls don't get anything that I filled in on the form. At the end of my script I have some CGI to display in the browser that it is done, but instead those lines show up as in the DOS window. Like I had double-clicked the pl file. If I type in the path to the sl3.pl file in my browser, it executes correctly and displays those I'm done lines in my browser. I stared at the activeperl directions for configuring IIS and don't see what I'm doing wrong. .pl is associated at the top level down with the full path including perl.exe followed by %s %s. And it works if I go straight there. These html and pl files work fine with IE browser on NT and linux apache web server at work, and I'm still using IE browser, so I know the problem is my IIS configuration. Yes, in my free time I will look into running apache instead of IIS. Why do I get a file download dialog box? My html file is like this: FORM ACTION=c:\inetpub\scripts\sl3.pl METHOD=POST ENCTYPE=multipart/form-data [snipped] INPUT TYPE=SUBMIT NAME=Button VALUE=SendP /FORM _ 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] Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- 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?
Hi Gunther, yes, you are right - maybe my answer was a bit flippent - it was only meant to be a conversational addition to the thread rather than a definitive answer ;-) By access to the DB I meant a valid SQL login. I enjoyed reading that URL you posted. Seeing the SQL being returned to the web user for his/her inspection is certainly a most worrying situation! Once again it reinforces the golden rule that you should NEVER trust (or make unfounded assumptions about) user input. I think that dynamically created SQL statements (such as in the norm in MySQL) are very vulnerable to this kind of attack in contrasts to, say, using stored procedures. I enjoyed reading your post :-) joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 01:15 To: yahoo; [EMAIL PROTECTED] Subject: 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
Re: Re: active perl on IIS
Let me also add, unlike *nix, you may run scripts from virtualy any folder you see fit on Win (within wwwroot for the web of course). Everything is really governed by the permissions and etc... you set on the folder itself. In some cases it makes sense to name the cgi folder something less obvious like, wordfiles, oldapps or the like. Be creative. This way should the casual hacker break in you stand a chance of he/ she skipping the directory. At the very least, someone is sniffing your tranfers might not suspect your moving them into an executable dir. Just a thought. MB' -Original Message- From: Lynn Glessner[EMAIL PROTECTED] To: yahoo[EMAIL PROTECTED], Begginers CGI[EMAIL PROTECTED] Date: Sun Sep 02 14:59:37 PDT 2001 Subject: Re: active perl on IIS I haven't had a chance to work on it recently, but I think it will turn out to be the .cgi extension (I'll have to go back and see who suggested that). I have my scripts in a directory which was created automatically called scripts a subdirecctory of c:\inetpub - IIS has it configured for executables. However, all my perl scripts in this directory have the extension .cgi. Double-clicking one of the example files installed by ActivePerl (those files have a .pl extension) executes fine, but my .cgi files have a generic icon - can't believe I didn't think to check that. I have the O'Reilly CGI book, with the rat/mouse on the cover, it is very helpful for CGI and Perl. I have the working version at work, it's just the implementation at home on IIS that I'm struggling with after doing my development at work. :( Thanks very much for the suggestions, I hope to be able to tackle this tonight (after my 2 year old goes to bed - she doesn't have much patience for programming yet!). From: yahoo [EMAIL PROTECTED] Date: Sun, 2 Sep 2001 18:28:47 +0100 To: [EMAIL PROTECTED] Subject: RE: active perl on IIS Hi Gunther, I think Lynn said she was looking for a book which covered IIS PerlScript - the OReilly win32 book is good for that (going hand-in-hand with ActiveStates latest documentation of course!). I don't think IIS normally pre-creates a cgi-bin for you - none of my installations have one (here is an excerpt from the IIS 5 documentation) extract To install and configure CGI applications: Set up a directory for your CGI programs. For extra security, you should separate your CGI programs from your content files. You do not need to name the directory Cgi-bin, although you can do so if you want. See Creating Virtual Directories. /extract As I said in my original email, you need to mark the directory as allowing scripting for executables inorder to get the .pl file to run. I agree with what you say about the file extension; I did mention the .pl extension in my original response. Lynn, any updates on this problem? regards Joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 04:00 To: yahoo; [EMAIL PROTECTED] Subject: RE: active perl on IIS Joel, I could be wrong but based on the way Lynn describes the problem, it does not sound like she has a problem with Perl being installed as the PerlScript examples do work as she stated. Also, she should not have to create a cgi-bin. IIS has a pre-created cgi-bin typically. While I am a fan of OReilly, I am also not sure that Win32 Perl book from OReilly will help Lynn so much because it's about Perl first and foremost, CGI secondarily (not that much coverage), and I don't think it goes into server configs but I could be wrong. Anyway, I think what Lynn is describing sounds more like a file extension problem. ActiveState Perl does set up Perl for IIS if I remember correctly but it does it based on FILE EXTENSION. So an important factor here is that Lynn should figure out if her file extensions would run if she clicked on the script in Explorer. I would be interested to know what file extension she is using for her scripts. If her colleagues are on UNIX and writing web apps, it's highly likely that they might use .cgi as an extension? But ActiveState never sets up .cgi. It will set up .pl for Perl for example. I have a more detailed article on this topic located here: http://webcompare.internet.com/isapiperl/index.html With a page specific to providing hints for installing ActiveState Perl for IIS here. http://webcompare.internet.com/isapiperl/isapiperl_3.html Good Luck, Gunther At 08:23 PM 8/29/2001 +0100, yahoo wrote: 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,
Re: active perl on IIS
That did it - thanks :) I am slowly but surely getting this changed over. I changed FORM ACTION=c:\inetpub\scripts\sl3.pl to FORM ACTION=http://198.162.0.1/scripts/sl3.pl; (Obviously if I decided to make this public I would need a different IP or hopefully a DNS name.) I can't believe this is taking me so long, when the script WORKS on a different OS and web server, but hopefully once I have gone through this once I'll be able to do this again in the future (or just develop on the same platform, that would be nice!) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
At 09:07 AM 9/3/2001 -0700, Lynn Glessner wrote: That did it - thanks :) I am slowly but surely getting this changed over. I changed FORM ACTION=c:\inetpub\scripts\sl3.pl to FORM ACTION=http://198.162.0.1/scripts/sl3.pl; (Obviously if I decided to make this public I would need a different IP or hopefully a DNS name.) I can't believe this is taking me so long, when the script WORKS on a different OS and web server, but hopefully once I have gone through this once I'll be able to do this again in the future (or just develop on the same platform, that would be nice!) As an aside, you should consider that your action does not even have to be an absolute URL. Even if the form is in the HTML tree instead of the CGI tree, you can at least get away with just ACTION=/scripts/myscript.cgi isntead of the whole HTTP://etc.. If the form was generated by another scripts in the scripts directory, then you can get away with ACTION=myscript.cgi. And finally, if the script that generated the form is the same that is being posted to, you can leave off ACTION= entirely because the default action is to submit the data to the same exact script. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: active perl on IIS
At 08:36 AM 9/3/2001 -0700, Mark Bergeron wrote: Let me also add, unlike *nix, you may run scripts from virtualy any folder you see fit on Win (within wwwroot for the web of course). Everything is really governed by the permissions and etc... you set on the folder itself. In some cases it makes sense to name the cgi folder something less obvious like, wordfiles, oldapps or the like. Be creative. This way should the casual hacker break in you stand a chance of he/ she skipping the directory. At the very least, someone is sniffing your tranfers might not suspect your moving them into an executable dir. Just a thought. MB' I don't fully understand this advice. If the casual hacker has broken in, then it seems that they already have more or equal power than they would be able to gain through hacking a scripts directory. As for sniffing file transfers. I suppose that is a valid issue, although it seems to me that someone sniffing an FTP session would sooner be able to get your plaintext password and be able to search around themselves. Even if the directory in this case was renamed, the script itself is not. So something like formmail.pl would still be formmail.pl even if it is in an oddly named directory. I am not saying there is no case for it at all. But it doesn't seem that strong for the annoyance of dealing with an obfuscation in your own setup. I think a human reading the directories would be able to figure out where things are. However, I also think that script kiddies are certainly something to watch out for if you are afraid you might miss a Microsoft security patch one day. One thing to consider then is that renaming the scripts directory may prevent an automated hacking script from putting something in the defeault c:\inetpub\scripts directory. So perhaps if this directory were renamed to something that is not obfuscated to make it hard to manage, but still different (eg maybe call it scriptstuff) then the automated scriptkiddle script will be thwarted. This is similar in concept to the idea of renaming root (which seemed to be advocated at SANS even several years back, don't know if it still is) just to prevent some scripted attacks from being able to log on as root. But they didn't precisely advocate renaming root to something that is obfuscated -- just renamed enough to fool the scripts of that day. Anyway, I'd like to hear more evidence of how strong renaming the scripts directory really is against attacks as I could be wrong in my assumptions. Thanks, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
