in reply to What Does Microsoft Think of Perl?

They're saying that Perlscript is to be used client-side?!? Forgive me for being presumptuous, but isn't that how the vast majority of web-hacks occur, because developers put too much control client-side? So, now they want to give hackers the capability of doing all their client-side hacks, but allow them to have the power of Perl. This is not a "Good Thing"(tm). This is a "Bad Thing"(tm).

<CYNICAL>Plus, even though they say it's open-source right now, they'll eventually say "Well, we had so many people begging for a MS-approved version, so we just went ahead, bought the rights, and made one." I don't like that route. Anyone will cave with M$100 thrown at them. I know I would.</CYNICAL>

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
Re(2): What Does Microsoft Think of Perl?
by FoxtrotUniform (Prior) on Jul 19, 2002 at 16:49 UTC

    ObUsageFlame: s/hacker/criminal/g;

    Don't forget that Perlscript's probably going to end up in the HTML renderer, which makes the problem infinitely worse (in that everything using that component will be vulnerable, not just IE). On the other hand, it'd be a smart move on Microsoft's part, because features sell, and client-side Perlscript has a rather high shiny! coefficient. Throw together some slick demos, impress the lusers convention-goers, and add another bullet point to the back of the box. (Then sit back and watch BUGTRAQ go fucko bazoo.)

    Microsoft doesn't care about security, just about profits. Unfortunately for many of us, most of Microsoft's client base doesn't care about security, either.

    --
    The hell with paco, vote for Erudil!
    :wq

Re: Re: What Does Microsoft Think of Perl?
by simon.proctor (Vicar) on Jul 19, 2002 at 23:15 UTC
    Having used PerlScript on windows as they have mentioned, the article glosses over just exactly what steps are required to get PerlScript onto a Windows machine and of course, not everyone is going to go and download and install it.

    This article is really about trying to win more converts to its way of doing things by winning over elements of the Perl community. However considering the articles age (January 22, 1999) I think its clear to see it didn't (or wouldn't :P ) happen.

    Showing client Perl is not a way of making friends and influencing people and so I'd just ignore it for the futile feature it is. As for the whole document, who honestly read it and though - wow, maybe Microsoft like Perl after all! And who can honestly argue that point when there are so many arguments against it?

    Personally I've written a Perl ASP page and went back to plain Perl - there was just no point to it. I have to write ASP at work and using PerlASP is like buying a guard dog and neutering it with a hammer just before it goes on duty. The only use I, personally, can see is machine automation with WSH and thats exactly what I have done and will stick to.

    But of course thats just my opinion :)

    Update: added document age etc
Re: Re: What Does Microsoft Think of Perl?
by vladb (Vicar) on Jul 19, 2002 at 19:27 UTC
    dragonchild with all due respect, I would disagree and assert that there's no inherent ill in using client-side Perl script, as compared to any other scripting language. Perlscript is no less secure than Javascript, or VisualBasic for that matter.

    But I concur with your point that putting too much client-side code up may be a dangerous thing. There are a couple home-nodes here were you can find javascript that steals your cookies and reveals a bunch of other JavaScript holes. In the end however, the choise of proper balance is all left to developer(s) involved. There are a lot of cases where you simply can't go by without client-side scripting. Things that spring to mind are form input validation (prior to the form being submitted), some DHTML stuff, and so forth. These things are hardly prone to any exploits. The worst one could do with them is mess up webpage appearance... However, if I was presented with a choice, I'd go for PerlScript vs Javascript. ;-)

    Update 1: In a gesture that could be deemed as self-defense, let me clarify that I think client-side perl is going to be somewhat limited in it's faculties than it's server-side equivalent, just as is the case with Javascript now. So, there's no reason to be panicky about PerlScript being so immensely powerful as to open ways for new creative hacks ;-).

    _____________________
    # Under Construction
      (I am not a JScript or VBSCript guru, so I may be wrong in a few assertions below.)

      Perl isn't less secure. Perl is more powerful. You cannot access the operating system with JScript or VBScript. You cannot (easily) initiate a download from some other server and execute that code.

      Even more importantly, Acme::Bleach doesn't exist in anything but Perl. That alone makes security checking through regex impossible.

      My concern is that the increased power of Perl will not come with increased safeguards on the part of the browser manufacturers or the plugin manufacturers or the OS manufacturers. THAT is what I am scared $h!tless about.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        As is pointed out below, this is a fairly old article. In its current state, there is little (read no) likelyhood that PerlScript will be installed by default on Windows/IE.

        Of course, there are those that will install PerlScript (such as myself). At one point, this was fairly dangerous, as is mentioned here. PerlScript is too powerful (it lacks the "sandbox" of JavaScript) to be used for general web scripting at the moment. Testing on my own machine, I was able to use PerlScript in a web page to delete a file on my computer, without any sort of prompt whatsoever.

        However, the page linked to is out of date. It says that the only way to avoid this problem is to not browse the web or turn off scripting in the browser for any machine that has PerlScript installed. Looking at the current documentation for PerlScript, there is a registry setting that limits PerlScript to certain IE Internet zones. By default PerlScript only runs in the "local intranet", which means that a random site on the web cannot use it to attack your computer. It also means that a company can choose to use client-side PerlScript on their intranet web sites without severely comprimising the security of their users' computers.

        In short, the current default in every version of Windows is that PerlScript is not installed. If it is installed, a client's PerlScript will not be available to regular web sites. Even if a user decided to be stupid and enable PerlScript for the Internet zone in IE, it is unlikely that many malicious sites would bother targeting their attacks on that tiny group of people (which is presumably much smaller than the group of people that will just click "yes" and install any ActiveX control that the web site asks them to).