Security of server-side code?

Back in the innocent days of the last century, I would have used a
mailto link in my web page to allow people to cancel me. In the era of
mass harvesting of addresses by spammers and other criminals, that is
no longer prudent. I'd like to write a small CGI that will mail a
message without exposing my address to web spiders. The question is
whether the code for the CGI can still be retrieved via HTTP. Any
information would be appreciated.

BTW, am I reinventing the wheel?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

re: Security of server-side code?

In article <412603b5$13$fuzhry+tra$mr2ice@news.patriot.net> ,
spamtrap@library.lspace.org.invalid enlightened us with...[color=blue]
> Back in the innocent days of the last century, I would have used a
> mailto link in my web page to allow people to cancel me. In the era of
> mass harvesting of addresses by spammers and other criminals, that is
> no longer prudent. I'd like to write a small CGI that will mail a
> message without exposing my address to web spiders. The question is
> whether the code for the CGI can still be retrieved via HTTP. Any
> information would be appreciated.
>
> BTW, am I reinventing the wheel?
>
>[/color]

Mailto is bad for a variety of reasons, the least of which is spam
harvesting.
Spiders will not find the mailer addy because it's in server-side code. The
server passes out html to the requester, be it a browser or a spider. The
address isn't IN the html. It's in the params to the mailer.

Yes, you ARE reinventing the wheel. ;)
If you have CGI, use Formmail.pl or similar. If you're using ASP, use CDONTS.
If JSP, JavaMail.

--
--
~kaeli~
Every calendar's days are numbered.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

re: Security of server-side code?

In <MPG.1b900b8ff50d244e98a082@nntp.lucent.com>, on 08/20/2004
at 02:23 PM, kaeli <tiny_one@NOSPAM.comcast.net> said:
[color=blue]
>Spiders will not find the mailer addy because it's in server-side
>code.[/color]

Are you saying that there's no way for them to access anthing in
public_html/cgi-bin via HTTP, or just that their spamware doesn't
normally do so?
[color=blue]
>If you have CGI, use Formmail.pl[/color]

doesn't it have security issues?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

re: Security of server-side code?

On Sun, 22 Aug 2004 00:07:26 -0300, Shmuel (Seymour J.) Metz
<spamtrap@library.lspace.org.invalid> wrote:
[color=blue][color=green]
>> If you have CGI, use Formmail.pl[/color]
>
> doesn't it have security issues?
>[/color]


Use the NMS version. It's as secure as you can get AFAIU.

re: Security of server-side code?

On Sun, 22 Aug 2004 00:07:26 -0300, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:
[color=blue]
>In <MPG.1b900b8ff50d244e98a082@nntp.lucent.com>, on 08/20/2004
> at 02:23 PM, kaeli <tiny_one@NOSPAM.comcast.net> said:
>[color=green]
>>Spiders will not find the mailer addy because it's in server-side
>>code.[/color]
>
>Are you saying that there's no way for them to access anthing in
>public_html/cgi-bin via HTTP, or just that their spamware doesn't
>normally do so?[/color]

If the server is correctly configured it is not possible for anyone
external to access cgi-bin. If it is incorrectly configured,
address-harvesters still wouldn't find the address unless someone has
linked to the file concerned.

[color=blue][color=green]
>>If you have CGI, use Formmail.pl[/color]
>
>doesn't it have security issues?[/color]

The original Matt Wright version does; there are other versions around
with a better reputation.

Actually spam harvesters are not very sophisticated. There was an
investigation done a while ago (a year?) which concluded that you could
adequately hide your address just by replacing a character or two in the
address (especially the '@') by its numeric equivalent.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

re: Security of server-side code?

Stephen Poley <sbpoleySpicedHamTrap@xs4all.nl> wrote:
[color=blue]
>Actually spam harvesters are not very sophisticated. There was an
>investigation done a while ago (a year?) which concluded that you could
>adequately hide your address just by replacing a character or two in the
>address (especially the '@') by its numeric equivalent.[/color]

http://www.cdt.org/speech/spam/030319spamreport.shtml

--
Spartanicus

re: Security of server-side code?

I seem to be missing a message from this thread, so apologies if I've
missed something important.

Stephen Poley wrote:
[color=blue]
> "Shmuel (Seymour J.) Metz" wrote:
>[color=green]
>> kaeli said:
>>[color=darkred]
>>> Spiders will not find the mailer addy because it's in server-side
>>> code.[/color]
>>
>> Are you saying that there's no way for them to access anthing in
>> public_html/cgi-bin via HTTP,[/color]
>
> If the server is correctly configured it is not possible for anyone
> external to access cgi-bin.[/color]

This doesn't make any sense. If the public cannot access /cgi-bin/,
what purpose can it serve?
[color=blue]
> If it is incorrectly configured, address-harvesters still wouldn't
> find the address unless someone has linked to the file concerned.[/color]

There will always be at least one reference to a formmail script from
the html page that contains the form. You could use rewrite to hide even
that reference, but ultimately, there must be a cgi script, it must be
accessible via http, and you must grant read and execute privelages to
all. You can, however, hide the cgi script's configuration files outside
of the document root, and only place email addresses, and sensitive
server info, in those configuration files.

BTW, I don't know of any spider that tried to look at cgi scripts for
addresses. But, if configured correctly, this should not be an issue.
[color=blue][color=green][color=darkred]
>>> If you have CGI, use Formmail.pl[/color]
>>
>> doesn't it have security issues?[/color]
>
> The original Matt Wright version does; there are other versions
> around with a better reputation.[/color]

Namely, NMS Formmail. You can also consider NMS TFmail. Lots more options.

http://nms-cgi.sourceforge.net/

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

re: Security of server-side code?

Stephen Poley wrote:
[color=blue][color=green]
>> If the server is correctly configured it is not possible for anyone
>> external to access cgi-bin.[/color][/color]

Brian <usenet3@julietremblay.com.invalid> posted:
[color=blue]
> This doesn't make any sense. If the public cannot access /cgi-bin/,
> what purpose can it serve?[/color]

I think he meant that the public can't access the files themselves in
there, merely interact with them. i.e. They can't read the program code,
just send it data and see the results.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

re: Security of server-side code?

In article <1gebs93k6an7j$.4a5xt3h1pk9x$.dlg@40tude.net>,
tim@mail.localhost.invalid enlightened us with...[color=blue]
> Stephen Poley wrote:
>[color=green][color=darkred]
> >> If the server is correctly configured it is not possible for anyone
> >> external to access cgi-bin.[/color][/color]
>
> Brian <usenet3@julietremblay.com.invalid> posted:
>[color=green]
> > This doesn't make any sense. If the public cannot access /cgi-bin/,
> > what purpose can it serve?[/color]
>
> I think he meant that the public can't access the files themselves in
> there, merely interact with them. i.e. They can't read the program code,
> just send it data and see the results.[/color]

Exactly.

Just like people can see the RESULTS of my JSP pages, but they can't read the
actual Java code that produced them. They can type in the URL and they'll see
a page, but that page has nothing on it for the client except HTML. Yet the
JSP page on the server has all kinds of beans and tags. Neat, eh? ;)


--
--
~kaeli~
The definition of a will?... (It's a dead giveaway.)
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

re: Security of server-side code?

Tim wrote:
[color=blue]
> Stephen Poley wrote:
>[color=green][color=darkred]
>>> If the server is correctly configured it is not possible for
>>> anyone external to access cgi-bin.[/color][/color]
>
> Brian posted:
>[color=green]
>> If the public cannot access /cgi-bin/, what purpose can it serve?[/color]
>
> I think he meant that the public can't access the files themselves in
> there, merely interact with them. i.e. They can't read the program
> code, just send it data and see the results.[/color]

Oh, right. Apologies to M. Poley, I lost my head. Still, I prefer to put
the script in a publicly accessible place with little or no sensitive
information. I keep that outside of the document root.


-- home -- www files -- foo (scripts, no passwords etc.)
| |--bar (scripts, no sensitve info)
|
|
--config files for scripts, *outside* of document root



--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

re: Security of server-side code?

"Brian" <usenet3@julietremblay.com.invalid> a écrit dans le message de
news:10ik1a5hhf16r7f@corp.supernews.com[color=blue]
> Still, I prefer to
> put the script in a publicly accessible place with little or no
> sensitive information. I keep that outside of the document root.[/color]

That's a pretty good habit indeed... But not always possible to do that,
paticularly when you're not hosted on a dedicated server and ou must share
it with lots of other web sites : in these conditions, you've got only one
place for you files.

re: Security of server-side code?

Pierre Goiffon wrote:
[color=blue]
> "Brian" a écrit dans le message de news:
>[color=green]
>> I prefer to put the script in a publicly accessible place with
>> little or no sensitive information. I keep that outside of the
>> document root.[/color]
>
> That's a pretty good habit indeed...[/color]

Thanks. I'm quite pleased when I come up with a vaguely good idea on my
own. It happens rather infrequently, you know. ;-)
[color=blue]
> But not always possible to do that, paticularly when you're not
> hosted on a dedicated server and ou must share it with lots of other
> web sites :[/color]

I guess I'm lucky. As much as I hate my hosting company, they do provide
space outside of the document root. Really, it is the smart thing to do
for the hosting company. Less attacks on clients means less headaches
for tech support.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

re: Security of server-side code?

In article <10ik2v7lgm05h49@corp.supernews.com>, usenet3
@julietremblay.com.invalid enlightened us with...[color=blue]
>
> I guess I'm lucky. As much as I hate my hosting company, they do provide
> space outside of the document root. Really, it is the smart thing to do
> for the hosting company. Less attacks on clients means less headaches
> for tech support.
>[/color]

I love my hosting company, and they DO have space outside the document root.
I don't know what you're looking for or what you need to have, but I try to
plug my guys whenever I can, since they've been very good to me. They have
great tech support.
Anyway, if you want a recommendation, I'll post the link. Or you can just
whois my domain and look at the nameserver.

--
--
~kaeli~
God was my co-pilot... but then we crashed in the mountains
and I had to eat him.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

re: Security of server-side code?

In <10ih9ir7bde5p3f@corp.supernews.com>, on 08/22/2004
at 09:57 AM, Brian <usenet3@julietremblay.com.invalid> said:
[color=blue]
>This doesn't make any sense. If the public cannot access /cgi-bin/,
>what purpose can it serve?[/color]

It runs on the server, so the public has no legitimate need to access
it. The public can access the HTML that links to it.
[color=blue]
>You can, however, hide the cgi script's configuration files outside
>of the document root, and only place email addresses, and sensitive
>server info, in those configuration files.[/color]

Thanks. I should have thought of that :-(
[color=blue]
>Namely, NMS Formmail. You can also consider NMS TFmail. Lots more
>options.
>http://nms-cgi.sourceforge.net/[/color]

Thanks.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

re: Security of server-side code?

In <knjgi01as24hkt4lqvph64fv0b4170iesp@4ax.com>, on 08/22/2004
at 09:57 AM, Stephen Poley <sbpoleySpicedHamTrap@xs4all.nl> said:
[color=blue]
>If the server is correctly configured it is not possible for anyone
>external to access cgi-bin. If it is incorrectly configured,
>address-harvesters still wouldn't find the address unless someone has
>linked to the file concerned.[/color]

But the whole point of a CGI program is to link to it.
[color=blue]
>The original Matt Wright version does; there are other versions
>around with a better reputation.[/color]

Thanks.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

re: Security of server-side code?

Stephen Poley <sbpoleySpicedHamTrap@xs4all.nl> said:
[color=blue][color=green]
>> If the server is correctly configured it is not possible for anyone
>> external to access cgi-bin. If it is incorrectly configured,
>> address-harvesters still wouldn't find the address unless someone has
>> linked to the file concerned.[/color][/color]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> posted:
[color=blue]
> But the whole point of a CGI program is to link to it.[/color]

Yes, they can refer to the resource. They can send it data, and see the
results, but they can't see what's written inside the CGI program itself.

If you had something like /cgi-bin/myscript.pl and tried to load that file
directly in the browser, you wouldn't get the source code for it, you'd get
whatever the program does when it's RUN without input data (probably an
error message). But normally you get whatever the program does when it's
run with input data.

If you look at something like the NMS alternative to Matt's form mail
script, you can see a better way of offering mail forms. Rather than your
HTML form containing recipient addresses, where they're there for all to
see and and harvest, it contains ambiguous references (aliases). Inside
the script there's a table of what addresses those references should be
used to deliver to. Nobody else on the internet can read into the contents
of that file and harvest the addresses.

e.g. It works in this fashion:

In your HTML form you'd have something like:

<input type="hidden" name="recipient" value="me">

In the formmail script, you'd have data that correlates "me"
to an address to send the form data:

%recipient_alias = (
'me' => 'tim@example.com',
'you' => 'johndoe@example.com',
)

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.