«

Every now and then I see articles on introductory Web application
development that just leave me dumbfounded with their lack of attention
to security. There was one on PHP in an Aussie magazine last year that
paid no attention whatsoever to quoting user-entered data to guard
against SQL injection attacks. I was wondering how many readers would
have blithely copied the example code from that straight into their own
Web pages, leaving their sites wide open to malicious attacks.

I just came across another example, in the June issue of MacTech
magazine. MacTech just isn't what it used to be--in the early days it
was very much a hacker's publication, with articles on all kinds of
interesting ins and outs of the Mac OS, programming it, using it,
undocumented features etc. Since Apple's switch to OS X, it's become
more full of handholding tutorials for newbies unfamiliar with *nix ways
of doing things, like basic command-line concepts. Programmers who can't
handle basic command-line concepts!?

Anyway, the article that got my hackles up is about running a Web server
from home with a dynamic IP address. The technique the writer describes
involves an external minimal-function Web server with a static IP
address that knows how to redirect browsers to your home server. It gets
told which address your home server is on by periodic accesses to a
special Web page that records the address it was accessed from,
ip_to_file.pl (typed in from the article):

#!/usr/bin/perl -w
# Save IP address received from Home Server to file.

use CGI qw(:standard;

$ipfile = 'home_server_ip';
print header,start_html;
if(open IPFILE, ">$ipfile")
{
$ip = $ENV{REMOTE_ADDR};
print IPFILE $ip . "\n";
close IPFILE;
print "Wrote to file $ipfile: $ip";
}
else
{
print "Failed to open file $ipfile for writing.";
}
print end_html;

Can you begin to describe the stupidity of doing such a thing? Again
we're going to have scores of people blindly copying the code from this
article, and leaving their systems wide open to mischief from others.

The trouble is, there is only one Internet. There is no kiddie pool you
can start out in, the whole pool is the deep end. As soon as you put
something up on a Web site, the entire world is immediately free to take
a crack at it. The bad guys don't just attack the sites of those with
the skills to hold them off, they can attack anybody's site. I guess
people shouldn't be allowed to put up stuff like this without somebody
more experienced to oversee them.

Lawrence D'Oliveiro wrote:

> #!/usr/bin/perl -w
> # Save IP address received from Home Server to file.
>
> use CGI qw(:standard;
>
> $ipfile = 'home_server_ip';
> print header,start_html;
> if(open IPFILE, ">$ipfile")
> {
> $ip = $ENV{REMOTE_ADDR};
> print IPFILE $ip . "\n";
> close IPFILE;
> print "Wrote to file $ipfile: $ip";
> }
> else
> {
> print "Failed to open file $ipfile for writing.";
> }
> print end_html;
>
> Can you begin to describe the stupidity of doing such a thing?

Please begin to describe the stupidity of doing such a thing.
What exactly is the problem?

On Fri, 16 Sep 2005 23:33:24 +1000, Harry <> wrote:

>Lawrence D'Oliveiro wrote:
>
>> #!/usr/bin/perl -w
>> # Save IP address received from Home Server to file.
>>
>> use CGI qw(:standard;
>>
>> $ipfile = 'home_server_ip';
>> print header,start_html;
>> if(open IPFILE, ">$ipfile")
>> {
>> $ip = $ENV{REMOTE_ADDR};
>> print IPFILE $ip . "\n";
>> close IPFILE;
>> print "Wrote to file $ipfile: $ip";
>> }
>> else
>> {
>> print "Failed to open file $ipfile for writing.";
>> }
>> print end_html;
>>
>> Can you begin to describe the stupidity of doing such a thing?
>
>Please begin to describe the stupidity of doing such a thing.
>What exactly is the problem?

I can't understand the above code (in fact I skipped right over reading it), but
I assume what he means is that anyone can access that page and then pretend to
be the home server as it'll redirect all requests their IP.

A password secured dynamic IP service would be the better way to go, rather than
having your own www site work it out - unless you set up a password system on
your own server.

On Fri, 16 Sep 2005 23:51:36 +1200, Lawrence D'Oliveiro wrote:

>
> #!/usr/bin/perl -w
> # Save IP address received from Home Server to file.
>
> use CGI qw(:standard;
>
> $ipfile = 'home_server_ip';
> print header,start_html;
> if(open IPFILE, ">$ipfile")
> {
> $ip = $ENV{REMOTE_ADDR};
> print IPFILE $ip . "\n";
> close IPFILE;
> print "Wrote to file $ipfile: $ip";
> }
> else
> {
> print "Failed to open file $ipfile for writing.";
> }
> print end_html;


Using CGI.pm here is a complete waste of resources
the CGI.lite.pm may have been betterer, but by far and away the best way
is to print the header, start_html, and end_html manually
(That and the newbies would have seen whats really being done)


--
Hardware, n.: The parts of a computer system that can be kicked

The best way to get the right answer on usenet is to post the wrong one.

In article <>,
Craig Shore <> wrote:

>I assume what he means is that anyone can access that page and then pretend to
>be the home server as it'll redirect all requests their IP.

Correct. I posted the entire script just to make it clear what was
missing.

>A password secured dynamic IP service would be the better way to go...

I would use shared-secret authentication myself.

Lawrence D'Oliveiro wrote:
> Every now and then I see articles on introductory Web application
> development that just leave me dumbfounded with their lack of attention
> to security. There was one on PHP ....

Say no more.

PHP is a toy. It's not meant for secure server-side programming.

The effort needed to cover every possible exploit, and the uncertainty
about whether the crackers know an unannounced vulnerability in php
itself, plus the general hideous ugliness of the language, makes it an
insane and costly choice.

PHP is the BASIC of web programming. PHP's popularity and code inventory
aside, you gotta be crazy to choose PHP. I'd rather code up the
server-side in assembler than have to face another screenful of this
disgusting abomination of a language.

Better to use Perl, Python, Ruby, Java, even C or ASP.

--
Cheers
EB

--

One who is not a conservative by age 20 has no brain.
One who is not a liberal by age 40 has no heart.

In article <>, se says...
> I'd rather code up the
> server-side in assembler than have to face another screenful of this
> disgusting abomination of a language.

You'd certainly have some lightening fast web pages (server side, that
is). But the mind boggles if I try to imagine the number of lines
of code.

I discontinued writing assembler after I moved up from 6502 CPUs <g>.

-P.

--
=========================================
firstname dot lastname at gmail fullstop com

the number of web site vulnerabilities reported supports your statement very
strongly.
SANS reports many php site related issues every month.

I recommend subscribing to the list at www.sans.org if your are at all
interested.

E.G. from SANS - snipped content, includes others vulnerabilities - to see
the full list, please go to the site:
Web Application 25 (#5)

05.37.25 - MyBulletinBoard RateThread.PHP SQL Injection

05.37.26 - Sawmill Unspecified Cross-Site Scripting

05.37.27 - phpTagCool HTTP Header SQL Injection Vulnerability

05.37.28 - Mall23 Infopage.ASP SQL Injection

05.37.29 - PunBB Multiple SQL Injection Vulnerabilities 05.37.30 - PunBB
BBCode URL Tag HTML Injection

05.37.31 - PHPNuke Multiple SQL Injection Vulnerabilities

05.37.32 - Azerbaijan Development Group AzDGDatingLite Directory Traversal

05.37.33 - Subscribe Me Pro S.PL Remote Directory Traversal

05.37.34 - Handy Address Book Server Cross-Site Scripting

05.37.35 - Mail-it Now! Upload2Server Arbitrary File Upload

05.37.36 - Land Down Under Multiple SQL Injection Vulnerabilities

05.37.37 - ATutor Password_Reminder.PHP SQL Injection

05.37.38 - aMember Remote File Include

05.37.39 - Mimicboard2 Mimic2.Dat Unauthorized Access 05.37.40 - Mimicboard2
Multiple HTML Injection Vulnerabilities

05.37.41 - MyBulletinBoard Multiple SQL Injection Vulnerabilities

05.37.42 - PBLang Bulletin Board System SetCookie.PHP Directory Traversal

05.37.43 - PBLang Bulletin Board System HTML Injection Vulnerability

05.37.44 - Class-1 Forum SQL Injection

05.37.45 - Stylemotion WEB//NEWS Multiple SQL Injection

05.37.46 - MyBulletinBoard Forumdisplay.PHP Fid Parameter Cross-Site
Scripting Vulnerability

05.37.47 - phpCommunityCalendar Multiple SQL Injection Vulnerabilities

05.37.48 - phpCommunityCalendar Multiple Remote Cross-Site Scripting
Vulnerabilities



"Evil Bastard" <> wrote in message
news:...
> Lawrence D'Oliveiro wrote:
>> Every now and then I see articles on introductory Web application
>> development that just leave me dumbfounded with their lack of attention
>> to security. There was one on PHP ....
>
> Say no more.
>
> PHP is a toy. It's not meant for secure server-side programming.
>
> The effort needed to cover every possible exploit, and the uncertainty
> about whether the crackers know an unannounced vulnerability in php
> itself, plus the general hideous ugliness of the language, makes it an
> insane and costly choice.
>
> PHP is the BASIC of web programming. PHP's popularity and code inventory
> aside, you gotta be crazy to choose PHP. I'd rather code up the
> server-side in assembler than have to face another screenful of this
> disgusting abomination of a language.
>
> Better to use Perl, Python, Ruby, Java, even C or ASP.
>
> --
> Cheers
> EB
>
> --
>
> One who is not a conservative by age 20 has no brain.
> One who is not a liberal by age 40 has no heart.

Craig Shore wrote:

> On Fri, 16 Sep 2005 23:33:24 +1000, Harry <>
> wrote:
>
>>Lawrence D'Oliveiro wrote:
>>
>>> #!/usr/bin/perl -w
>>> # Save IP address received from Home Server to file.
>>>
>>> use CGI qw(:standard;
>>>
>>> $ipfile = 'home_server_ip';
>>> print header,start_html;
>>> if(open IPFILE, ">$ipfile")
>>> {
>>> $ip = $ENV{REMOTE_ADDR};
>>> print IPFILE $ip . "\n";
>>> close IPFILE;
>>> print "Wrote to file $ipfile: $ip";
>>> }
>>> else
>>> {
>>> print "Failed to open file $ipfile for writing.";
>>> }
>>> print end_html;
>>>
>>> Can you begin to describe the stupidity of doing such a thing?
>>
>>Please begin to describe the stupidity of doing such a thing.
>>What exactly is the problem?
>
> I can't understand the above code (in fact I skipped right over reading
> it), but I assume what he means is that anyone can access that page and
> then pretend to be the home server as it'll redirect all requests their
> IP.

It doesn't do anything like that at all.
It just saves an IP address in a file.
It doesn't redirect anything anywhere.

>
> A password secured dynamic IP service would be the better way to go,
> rather than having your own www site work it out - unless you set up a
> password system on your own server.

Lawrence D'Oliveiro wrote:

> In article <>,
> Craig Shore <> wrote:
>
>>I assume what he means is that anyone can access that page and then
>>pretend to be the home server as it'll redirect all requests their IP.
>
> Correct. I posted the entire script just to make it clear what was
> missing.

Wrong. It doesn't do any redirection whatsoever.
It just saves a remote IP address in a file.

>
>>A password secured dynamic IP service would be the better way to go...
>
> I would use shared-secret authentication myself.

But you cannot use a shared-secret authentication to save an IP
address in a file!