Introductory Web Programming Considered Harmful
Lawrence D'Oliveiro
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.
Craig Shore
>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.
Shane
>
> #!/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.
Lawrence D'Oliveiro
Craig Shore <craig...@paradise.net.nz> 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.
Evil Bastard
> Every now and then I see articles on introductory Web application
> development that just leave me dumbfounded with their lack of attention
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.
Peter Huebner
> 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
Mercury
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" <sp...@me.please> wrote in message
news:432b...@news.orcon.net.nz...
Ron McNulty
provide for free. Obviously they are open to the same malicious attack.
Does anyone have any insight into how secure providers like dyndns.com might
be?
Regards
Ron
"Lawrence D'Oliveiro" <l...@geek-central.gen.new_zealand> wrote in message
news:ldo-5ED084.2...@lust.ihug.co.nz...
Richard
> What you are describing here is very similar to what sites like dyndns.com
> provide for free. Obviously they are open to the same malicious attack.
>
> Does anyone have any insight into how secure providers like dyndns.com might
> be?
Firstly, you have a password for the updates.
Still does nothing to secure the fact that for a period of time after you
disconnect and someone else has the IP you had, that anything destined to you
will go there so there is the very real chance of them running a mail server
that will rightly reject mail that was supposed to go to your own mail server.
Matthew Poole
scrawl:
> the number of web site vulnerabilities reported supports your statement very
> strongly.
> SANS reports many php site related issues every month.
>
*SNIP* list of exploits in applications written in PHP
Talk about a tenuous link. Are you blaming C++ for all the flaws in
Microsoft products? Maybe blaming C (is it written in C?) for the flaws in
Firefox?
You can't blame the language for people doing silly things with it.
Yes the language can make it easier or harder to achieve certain aims, but
the end result of someone's coding is laid at the feet only of the coder.
--
Matthew Poole
"Don't use force. Get a bigger hammer."
Enkidu
problem comes if there is also a mail server at the old IP
address.
Cheers,
Cliff
--
Barzoomian the Martian - http://barzoomian.blogspot.com
Lawrence D'Oliveiro
Matthew Poole <sp...@stops.here> wrote:
>On Sat, 17 Sep 2005 23:33:19 +1200, someone purporting to be Mercury didst
>scrawl:
>
>> the number of web site vulnerabilities reported supports your statement very
>> strongly.
>> SANS reports many php site related issues every month.
>>
>*SNIP* list of exploits in applications written in PHP
>
>You can't blame the language for people doing silly things with it.
>Yes the language can make it easier or harder to achieve certain aims, but
>the end result of someone's coding is laid at the feet only of the coder.
But if a certain language seems to attract a community of coders whose
understanding of security seems a little underdeveloped, then whenever
you come across something using that language, there's a good chance
that you are seeing something created by one of those lax coders, is
there not?
For instance, while looking around recently for online comic strips, I
found one that only made a two-week sequence of episodes available
online, and these were delayed by a month. I noticed the site was done
in PHP, and that set the usual alarm bells ringing. I tried feeding
other dates to the form submission URL, and found that it was doing a
stupid referrer check. After bypassing that, what did I find but that I
was able to access episodes right up to the current day, and going back
over two years. I might have gone back further, but after my simple
shell script had collected over 660 episodes, I lost interest and went
on to something else.
Waylon Kenning
D'Oliveiro <l...@geek-central.gen.new_zealand> saying something like
this:
>But if a certain language seems to attract a community of coders whose
>understanding of security seems a little underdeveloped, then whenever
>you come across something using that language, there's a good chance
>that you are seeing something created by one of those lax coders, is
>there not?
Well surely you can't blame a language because there aren't so hot
coders doing stupid things? It's a bit like blaming petrol for the
fact it can cause fires when in the hands of wrong people.
--
Cheers,
Waylon Kenning.
Lawrence D'Oliveiro
Waylon Kenning <use.the.rep...@this.is.fake> wrote:
>T'was the Sun, 18 Sep 2005 13:14:33 +1200 when I remembered Lawrence
>D'Oliveiro <l...@geek-central.gen.new_zealand> saying something like
>this:
>
>>But if a certain language seems to attract a community of coders whose
>>understanding of security seems a little underdeveloped, then whenever
>>you come across something using that language, there's a good chance
>>that you are seeing something created by one of those lax coders, is
>>there not?
>
>Well surely you can't blame a language because there aren't so hot
>coders doing stupid things?
OK, let us define
P[S] = probability that someone is stupid.
P[H] = probability that someone uses PHP.
P[H|S] = probability that someone uses PHP, given they are stupid.
P[S|H] = probability that someone is stupid, given they use PHP.
P[S&H] = probability that someone is both stupid and uses PHP.
Empirical evidence indicates that P[S], P[H] and P[H|S] are all high:
there are a lot of stupid people around, PHP is very popular, and it's
popular among stupid people. Given this, what can we say about P[S|H]?
According to Bayes' Theorem
<http://en.wikipedia.org/wiki/Bayes%27_theorem>,
P[S&H] = P[H|S]P[S] = P[S|H]P[H]
Therefore,
P[S|H] = P[S&H]/P[H]
= P[H|S]P[S]/P[H]
But there are almost certainly more stupid people than there are PHP
users, i.e.
P[S] > P[H]
Therefore
P[S|H] > P[H|S]
Therefore if P[H|S] is high, then P[S|H] is higher.
So if you see someone using PHP, the odds that they are stupid are
pretty good.
Waylon Kenning
D'Oliveiro <l...@geek-central.gen.new_zealand> saying something like
this:
>So if you see someone using PHP, the odds that they are stupid are
>pretty good.
I'll admit that learning PHP is a pretty easy language, and all the
better for it I say.
What are the odds that if someone is speaking the English language,
odds are they're stupid? Cause I've seen some pretty stupid people
speak English, and that was before the election even:)
--
Cheers,
Waylon Kenning.
Lawrence D'Oliveiro
Waylon Kenning <use.the.rep...@this.is.fake> wrote:
>T'was the Sun, 18 Sep 2005 14:10:20 +1200 when I remembered Lawrence
>D'Oliveiro <l...@geek-central.gen.new_zealand> saying something like
>this:
>
>>So if you see someone using PHP, the odds that they are stupid are
>>pretty good.
>
>What are the odds that if someone is speaking the English language,
>odds are they're stupid?
You could use the same mathematical argument, just replace "PHP" with
"English".
The key assumption is whether P[S] is comparable to (or greater than)
P[H]; if P[S] is much elss than P[H], then the argument doesn't hold.
In this case, if the number of English-speaking people in the world is
much greater than the number of stupid people, then speaking English
isn't reasonable grounds for assuming you're stupid.
Evil Bastard
> You can't blame the language for people doing silly things with it.
You can, to an extent.
PHP's syntax and in-html semantics make it way harder to write secure
code than other langs. Also, it offers huge convenience incentives for
writing insecure code.
Humans are humans. When deadlines push hard, people will cut corners and
cross their fingers, leaving others to pay the price.
My personal favourite combo is Python with HtmlTemplate.
No buffer overrun exploits. No funnies with string interpolation. I
gotta try hard to write insecure code.
> Yes the language can make it easier or harder to achieve certain aims, but
> the end result of someone's coding is laid at the feet only of the coder.
>
--
Mercury
> Yes the language can make it easier or harder to achieve certain aims, but
> the end result of someone's coding is laid at the feet only of the coder.
it is paramount to use an appropriate language for the task at hand.
should you try to write an OS in cobol?
should you write a simple gui based app in C?
should you write a large scale package for volume international resale in
basic or assembler?
there are most definitely language attributes that should be considered when
starting a project. any language these days that still exposes the prospect
of memory leaks really needs to be reconsidered for any purpose. C for
example has limited applicability for this reason - there are still good
reasons and specific uses for C, but not mainstream programming. Some have
argued that it is a good language to learn for this very reason: to
knowabout bad aspects of a language so that when C++ is taught the
programmer has these finer points rammed home.
"You can't blame the language for people doing silly things "
A good language will stop people doing stupid things. Take a look for a
moment at OO languages, the features and benefits, why these features were
Designed In - to solve programmer problems (silly things).
No language can stop a programmer that fails to meet requirements.