Re^2: SMTP authentication misery

Thanks, pileofrogs.

I've now left for the day, but I'll try your suggestions tomorrow morning and report back then.

I suppose I'll need to raise the question of how to go about 'securing' my code in another post -- I really know nothing concerning how others hack into programs for use as spammers. The program I'm writing will be installed locally, run pretty much continuously on that single machine, and, triggered by a date/time stamp, send email to another address in the organization.

Again, I haven't a clue what security issues are involved or how to deal with them. I'd be happy for your input.

cypress

Update: What I'm writing isn't a CGI script (if I understand the term correctly), as it does not receive input from outside users (eg, via a webpage). The only time it connects with the outside world is when it sends email. Here, all I should need to be concerned with is the authentication password being snatched during this event. Uh, right?

Comment on Re^2: SMTP authentication misery

Replies are listed 'Best First'.
Re^3: SMTP authentication misery by pileofrogs (Priest) on Nov 20, 2009 at 22:39 UTC
Not accepting input from the outside world is definitely good for security, though you'll want to consider the risks from input from the inside as well. If it's not used by multiple humans, it's probably fine. The classic CGI security failure is a script that accepts the TO: address as one of the input variables, so anyone can use the script to send email to anyone else. The most important rule of secure coding is to always check that values are OK before you use them. Taint checking (see perlsec) goes a long way toward helping you do that. Also, you cannot trust input from web pages, even if you use java script to validate the input because anyone can bypass the javascript and the web form. You can surf the web from a telnet client just like you can send SMTP (HTTP is text based). Here's a fun thing to try run "telnet google.com 80" and then type "GET /" at the prompt. You can do any HTTP request, including POST or PUT or whatever, so an HTML form is just a "suggestion". You can put any value you want into the Referrer: header so, that's no help for security either. Users can really send any value they want. I know this isn't on topic but any chance to say this stuff is worth taking. --Pileofrogs	[reply]

Replies are listed 'Best First'.

Re^3: SMTP authentication misery
by pileofrogs (Priest) on Nov 20, 2009 at 22:39 UTC

Not accepting input from the outside world is definitely good for security, though you'll want to consider the risks from input from the inside as well. If it's not used by multiple humans, it's probably fine.

The classic CGI security failure is a script that accepts the TO: address as one of the input variables, so anyone can use the script to send email to anyone else.

The most important rule of secure coding is to always check that values are OK before you use them. Taint checking (see perlsec) goes a long way toward helping you do that.

Also, you cannot trust input from web pages, even if you use java script to validate the input because anyone can bypass the javascript and the web form. You can surf the web from a telnet client just like you can send SMTP (HTTP is text based). Here's a fun thing to try run "telnet google.com 80" and then type "GET /" at the prompt. You can do any HTTP request, including POST or PUT or whatever, so an HTML form is just a "suggestion". You can put any value you want into the Referrer: header so, that's no help for security either. Users can really send any value they want.

I know this isn't on topic but any chance to say this stuff is worth taking.

--Pileofrogs

[reply]