in reply to Re: Does fatalsToBrowser give too much information to a cracker?
in thread Does fatalsToBrowser give too much information to a cracker?

Another reason why I always remove -w (use warnings) in production systems ... is that I don't want to confront users with errormessages they won't understand or won't be able to do anything against.

How does removing -w aid that? Warnings (even with fatalsToBrowser, since warnings by their very nature aren't fatal) only appear in the server error log, which isn't going to be seen by users.

In deployed code there shouldn't be any warnings generated, but should something of a dubious nature occur surely it's better for the warnings to be available in the log than not at all?

Replies are listed 'Best First'.
Re: Re: Does fatalsToBrowser give too much information to a cracker?
by doran (Deacon) on Apr 10, 2002 at 22:35 UTC
    Actually, warnings produced by -w can often be viewed in the raw data returned by the HTTP server. It won't display in the browser, but is visible with GET (or is it HEAD?) or with a util such as curl or Sam Spade. These errors can reveal paths and filenames, which may or may not be a problem. I tend to use a BEGIN{} block to skip stupid errors ("$xxx used only once...") and/or carpout() to redirect the errors to a file.
[reply]
      Actually, warnings produced by -w can often be viewed in the raw data returned by the HTTP server. It won't display in the browser, but is visible with GET (or is it HEAD?)

      Are you sure? I've just tried creating a script which causes an unitialized value warning. Whenever it's run as a CGI script it indeed spews said warning to the server error log. But I can't provoke the server into yielding the warning in any headers.

      I've tried telnetting directly to port 80 on the server and using both HEAD and GET (though I'm fairly sure it would violate the HTTP spec for those two to return different sets of headers) and don't see any warnings.

      What do they look like when you see them — what HTTP header do they use? I'm just getting Date:, Server:, Connection:, and Content-Type:, exactly the same as I do with warnings turned off.

      Smylers

[reply]
[d/l]
[select]
        Here's a sample. (Yes, I've xxx'd out the server ip address and changed the actual directory names, but otherwise it's untouched, honest) 
        #!/usr/bin/perl -Tw
use strict;
$|++;
use CGI;

my $q = new CGI;
$q->import_names('STUFF');

print $q->header(),
      $q->start_html();

if ($STUFF::username eq 'rocky'){
    print "Where's the moose?\n";
}
else{
    print $q->startform();
    print "Who goes there?<br>\n";
    print $q->textfield(-name=>'username');    
    print $q->endform;    
}

print $q->end_html();
exit();

        [download]
        Using HEAD produces: 
        200 OK
Date: Thu, 11 Apr 2002 16:21:23 GMT
Server: Microsoft-IIS/3.0
Content-Type: text/html; charset=ISO-8859-1
Client-Bad-Header-Line: Name "STUFF::username" used only once: possibl
+e typo at C:\inetsrv\path\to\files\test.cgi line 13.
Client-Date: Thu, 11 Apr 2002 16:21:22 GMT
Client-Peer: xxx.xxx.xxx.xxx:80
Title: Untitled Document

        [download]
        And GET gives us: 
        <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html
        PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"><head><title>U
+ntitled Document</title>
</head><body>Use of uninitialized value in string eq at C:\inetsrv\pat
+h\to\files\test.cgi line 13.
<form method="post" action="/test.cgi" enctype="application/x-www-form
+-urlencoded">
Who goes there?<br>
<input type="text" name="username"  /></form></body></html>

        [download]

        Granted, this isn't the way I'd write a real CGI script, but it shows what I was talking about.

        Now, it wouldn't surprise me if this is an IIS thing. I haven't tried it on Apache, only on various versions of IIS. Also, it's quite possible to be a "feature" of the CGI module. I don't remember if I've ever tried this when not using CGI to handle forms.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom