Introductory Web Programming Considered Harmful

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Sep 16, 2005.

  1. 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, Sep 16, 2005
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Harry Guest

    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?
    Harry, Sep 16, 2005
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    Craig Shore Guest

    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.
    Craig Shore, Sep 16, 2005
    #3
  4. Lawrence D'Oliveiro

    Shane Guest

    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.
    Shane, Sep 16, 2005
    #4
  5. 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, Sep 16, 2005
    #5
  6. Lawrence D'Oliveiro

    Evil Bastard Guest

    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.
    Evil Bastard, Sep 17, 2005
    #6
  7. 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
    Peter Huebner, Sep 17, 2005
    #7
  8. Lawrence D'Oliveiro

    Mercury Guest

    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.
    Mercury, Sep 17, 2005
    #8
  9. Lawrence D'Oliveiro

    Harry Guest

    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.
    Harry, Sep 17, 2005
    #9
  10. Lawrence D'Oliveiro

    Harry Guest

    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!
    Harry, Sep 17, 2005
    #10
  11. Lawrence D'Oliveiro

    Ron McNulty Guest

    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?

    Regards

    Ron

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:...
    > 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.
    Ron McNulty, Sep 17, 2005
    #11
  12. Lawrence D'Oliveiro

    Richard Guest

    Ron McNulty wrote:
    > 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.
    Richard, Sep 17, 2005
    #12
  13. 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

    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."
    Matthew Poole, Sep 18, 2005
    #13
  14. Lawrence D'Oliveiro

    Enkidu Guest

    Richard wrote:
    > Ron McNulty wrote:
    >
    >> 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.
    >

    Which is usually OK, since the mail will be retried. The
    problem comes if there is also a mail server at the old IP
    address.

    Cheers,

    Cliff

    --

    Barzoomian the Martian - http://barzoomian.blogspot.com
    Enkidu, Sep 18, 2005
    #14
  15. In article <>,
    Matthew Poole <> 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.
    Lawrence D'Oliveiro, Sep 18, 2005
    #15
  16. T'was the Sun, 18 Sep 2005 13:14:33 +1200 when I remembered Lawrence
    D'Oliveiro <_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.
    Waylon Kenning, Sep 18, 2005
    #16
  17. In article <>,
    Waylon Kenning <> wrote:

    >T'was the Sun, 18 Sep 2005 13:14:33 +1200 when I remembered Lawrence
    >D'Oliveiro <_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 = 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, 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 = P[S|H]P[H]

    Therefore,

    P[S|H] = P[S&H]/P[H]
    = P[H|S]P/P[H]

    But there are almost certainly more stupid people than there are PHP
    users, i.e.

    P > 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.
    Lawrence D'Oliveiro, Sep 18, 2005
    #17
  18. T'was the Sun, 18 Sep 2005 14:10:20 +1200 when I remembered Lawrence
    D'Oliveiro <_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.
    Waylon Kenning, Sep 18, 2005
    #18
  19. In article <>,
    Waylon Kenning <> wrote:

    >T'was the Sun, 18 Sep 2005 14:10:20 +1200 when I remembered Lawrence
    >D'Oliveiro <_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 is comparable to (or greater than)
    P[H]; if P 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.
    Lawrence D'Oliveiro, Sep 18, 2005
    #19
  20. Lawrence D'Oliveiro

    Evil Bastard Guest

    Matthew Poole wrote:
    > 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.
    >


    --
    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.
    Evil Bastard, Sep 18, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harvey Van Sickle

    Re: Is swallowing liquid laser printer cleaner harmful?

    Harvey Van Sickle, Jul 9, 2003, in forum: Computer Support
    Replies:
    0
    Views:
    431
    Harvey Van Sickle
    Jul 9, 2003
  2. Brian H¹©

    Re: Is swallowing liquid laser printer cleaner harmful?

    Brian H¹©, Jul 9, 2003, in forum: Computer Support
    Replies:
    1
    Views:
    455
    Shep©
    Jul 9, 2003
  3. Jj
    Replies:
    1
    Views:
    470
  4. Lawrence D'Oliveiro

    Spreadsheets Considered Harmful

    Lawrence D'Oliveiro, Mar 16, 2010, in forum: NZ Computing
    Replies:
    7
    Views:
    507
    Enkidu
    Mar 17, 2010
  5. Lawrence D'Oliveiro

    Table Lookup Considered Harmful

    Lawrence D'Oliveiro, Mar 24, 2010, in forum: NZ Computing
    Replies:
    5
    Views:
    394
    Enkidu
    Mar 25, 2010
Loading...

Share This Page