Scriptudviklere kan bedst lide PHP

Ny undersøgelse giver PHP topkarakter til udvikling af webapplikationer. Ruby er dog nemmere at bruge, og F# er det sikreste.

PHP-udviklere er mere tilfredse end brugere af andre scriptsprog herunder Ruby, Python, Perl, Javascript, Flex og VB script. Det fremgår af brugertilfredshedsundersøgelse lavet Evans Data.

Over 500 udviklere blev bedt om at vurdere elementer i de scriptsprog, de brugte, i 12 forskellige kategorier. PHP modtog den højeste samlede score, mens Ruby gjorde det bedst i brugervenlighed og undtagelseshåndtering. Python fik topkarakter i udvidelsesmuligheder og hukommelseshåndtering. Javascript var bedst til scripting på klientsiden, mens F# fik den bedste score for sikkerhed. PHP blev bedømt bedst i alt andet.

»Scriptsprog fylder godt i softwareudviklingslandskabet. Lidt over 60 procent af alle udviklere angiver, at de bruger et eller flere sprog i deres udviklingsprojekter,« siger John Andrews, adm. direktør for Evans Data i en pressemeddelelse.

Undersøgelsen konkluderede, at PHP var det bedste allround scriptsprog for webapplikationer med et stort community og masser af let tilgængelige værktøjer.

Ruby blev kåret som det letteste at bruge, selvom det lider under performance-problemer og et lille udviklersamfund, mens Python viste sig at være den bedst egnede til at skabe store og komplekse applikationer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anonym

Artiklen omhandler [b]script[/b] udviklere.

SVJH så kom script - 'tingene' frem i sidste ½-del af '90-erne fordi ingen hoster vile hoste rigtige programmer uden at have kildekoden til gennemsyn.

Så, med tanke i, at man ikke kan mere i dag, vil jeg nok kalde det '10 years after'.

Det paradoksale var, at argumentet var sikkerdshensyn, og den største sikkerhedsrisiko i dag er netop PHP.

  • 0
  • 0
Baldur Norddahl

Link til dokumentation?

Jeg har ikke noget link, men det er åbenbart at sprogets store tilgængelighed har bevirket at der er meget kode udviklet af nye programmører uden særlig kendskab til sikkerhed.

Der er altså ikke nødvendigvis noget galt med sproget. Der er bare en helt masse dårlig kode udviklet i netop det sprog.

  • 0
  • 0
Anonym

Link til dokumentation?

Kig i logfilerne, og lave en backtrace for hver gang der indgår http:// i 'querystring'.

Her er f.eks. en, der stadig er aktiv:
http : / / sasfriars.org/coppermine/xss
(blanke indsat aht. Version2)

Headers siger:
HTTP/1.1 200 OK
Date: Thu, 05 Mar 2009 15:53:05 GMT
Server: Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.7 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a
Last-Modified: Thu, 29 Jan 2009 08:21:45 GMT
ETag: "15dd9d9-542-49816719"
Accept-Ranges: bytes
Content-Length: 1346
Connection: close
Content-Type: text/plain

Hvordan tror du den fil er landet der?

  • 0
  • 0
Anonym

Så husker du forkert.

Nåh?

Og hvordan synes du muligheden for hosting af binær kode så ud i midt/slut 90'erne?

Eller i dag - jeg har en del ISAPI 'ting' liggende, hvor kan jeg få dem hostet?

Ja, i dag kan man leje en (virtuel) host, men i 90'erne?

  • 0
  • 0
Lars Balker

Script-sprogene har intet med webhosting at gøre, ikke hvorvidt compilerede programmer var nemme at få lagt op på webhosts.

Perl kom i 1987. TCL fulgte i 1990. PHP, Ruby, Python er alle senere "børn" af Perl.

Af dem er det kun PHP der har en direkte baggrund i web.

Lav lidt research.

  • 0
  • 0
Anonym

Script-sprogene har intet med webhosting at gøre

Snakker vi ikke om baggrunden for scriptsprogenes udbredelse på web?

Lav lidt research

Behøver jeg ikke, var der selv.

De systemer jeg har lavet siden '80 kan slet ikke laves med scriptsprog aht. performance.

Og da jeg undersøgte markedet for webhosting i 90'erne var det kke muligt at finde et webhotel, der ville hoste rigtige applikationer.

Det er muligt jeg ikke søgte hårdt nok, men jeg var ikke alene.

Hvis du mener performance ikke er et issue, så spørg PHK hvad han sidder og fedter med.

  • 0
  • 0
Morten Fangel

Sikkerhedshuller i PHP-scripts != sikkerhedshuller i PHP.

Ja, PHP gør det nemt at skyde sig selv i foden, hoppe over hvor gærdet er lavest og alt andet der ikke er godt. Det er derfor relativt nemt at kode et dårligt script der har dumme sikkerhedsfejl.
- Men det er altså ikke et krav!

Man kan sagtens kode PHP uden sikkerhedsfejl (også udover "hallo world", ja). Det kræver selvfølgeligt at man ved hvad man laver - men hvem vil ikke gerne vide det?

Alle sprog, især dem hvor man ikke ved hvad man laver, kan kodes så de indeholder sikkerhedshuller som XSS/SQL Injections.. Men det er jo ikke det samme som at sige at alle sprog indeholder sikkerhedshuller, vel?

  • 0
  • 0
Jan Keller Catalan

Snakker vi ikke om baggrunden for scriptsprogenes udbredelse på web?

Du gør ikke i din tidligere kommentar:

SVJH så kom script - 'tingene' frem i sidste ½-del af '90-erne fordi ingen hoster vile hoste rigtige programmer uden at have kildekoden til gennemsyn

Mht. 'dokumentation'

Kig i logfilerne, og lave en backtrace for hver gang der indgår http:// i 'querystring'.

Så kan jeg ikke se, hvad det har med PHP som sikkerhedsrisiko at gøre.

Jeg tilslutter mig Mortens kommentar om, at blot fordi der sidder klaphatte og ikke kan kode, så er det ikke en sikkerhedsrisiko i sproget.

Ellers må C være en endnu større sikkerhedsrisiko med alle de buffer overflows o.lign. man hører om dér.

  • 0
  • 0
Anonym

Jeg tror vi er enige, men det er nok et spørgsmål om ordvalg.

Jeg forholder mig til sætningen

Undersøgelsen konkluderede, at PHP var det bedste allround scriptsprog for webapplikationer

Når jeg skriver 'kom frem i', mente jeg 'begyndte at blive udbredt' på web.

Mht. hosting af 'rigtige' applikationer, altså kompileret kode, var den eneste mulighed for hosting at 'leje' en hel server.

Det var rasende dyrt i 90'erne, og ikke forbeholdt menigmand og mindre virksomheder.

Pointen med scriptsprog var, at udbyderen kunne lave code review, da kildeteksten var tilgængelig.

Jeg tilslutter mig Mortens kommentar om, at blot fordi der sidder klaphatte og ikke kan kode, så er det ikke en sikkerhedsrisiko i sproget.

Det var faktisk også det jeg mente.
Det er ikke PHP i sig selv, jeg mener udgør en risiko, det er udbredelsen kombineret med klaphatteprogrammering.

Jeg vil tro, at man til enhver tid kan sige at det mest udbredte 'sprog' vil udgøre den største risiko, på samme måde som Windows er det foretrukne target på PC'ere.

Mine betragtninger er baseret på et lille hobbyprojekt, hvor jeg sidste år, sammen med en anden, lavede nogle detaljerede logninger på en side.

Både GET og indhold af forsøg på POST.
Gennem et par måneder lavede jeg backtrace på både GET samt indhold i POST's.

På GET siden kan man sige, at der egentlig kun var 2 slags angrebsforsøg.
1) SQL-injection mod MS SQLServer, men dem tror jeg alle har hørt om.
2) Forsøg på remote execution via en HTTP reference til koden fra en anden server.

Alle disse forsøg er PHP kode.

Indholdet i POST's (blog/commentspam) kunne man også inddele i 2 overordnede kategorier.
1) Super tilbud om viagra/penisforlængere,billige forsikringer etc.
2) Link til en anden inficeret server, der redirecter til malware, med lokkemaden: Se den og den nøgen, eller asiatisk porno.r

Alle disse link og phishing sites m.v. har været baseret på PHP, deraf min antagelse.

Det er ikke en verdensomspændende undersøgelse, men vi snakker flere måneder, og backtracing af mange tusinde links.

Jeg har arbejdet med sikre systemer siden ca. '82, men har altid kigget indad, dvs. hvordan sikrer jeg min server/applikation.

Men jeg fik den interesse at kigge udad, og forsøge at tage temperaturen på 'internettet'.

Det var af personlig nysgerrighed, og ikke med formål at lave store rapporter eller lign.

Det betyder at 'dokumentationen' kun ligger i mit hovede.

Jo bevares, jeg har en database med en hulens masse links, men den slags er 'highly volatile', så de dør i løbet af et par dage (dvs. når webmasteren opdager de hoster den slags).

Så de aktuelle indhold af links kan ikke efterspores.

Desuden skal man(jeg) efterespore manuelt, og det tager alt, alt for lang tid.

  • 0
  • 0
Jan Keller Catalan

Alle disse link og phishing sites m.v. har været baseret på PHP, deraf min antagelse.

Jeg forstår, hvad du mener, men synes stadig ikke, din udtalelse er fair.

Analogier er som regel "misbrugsvenlige", men jeg synes godt, man kan vende dine udtalelser til, at hvis de fleste indbrudstyve bruger stål-koben til at bryde ind i huse, så udgør stål en sikkerhedsrisiko og derfor bør man lade være med at bruge stål selv.

Det kan godt være, at PHP er det foretrukne værktøj for phishing-sites, men det betyder ikke, at det er en sikkerhedsrisiko.

Det kan godt være, at der er flere sikkerhedshuller i PHP-kode på nettet end i Java-kode - men det skyldes i stor grad også, at der er meget mere PHP-kode end Java-kode.

"den største sikkerhedsrisiko i dag er netop PHP." lyder på mig som en advarsel imod at bruge PHP kode på sin webserver - og jeg kunne ikke være mere uenig.

  • 0
  • 0
Anonym

lyder på mig som en advarsel imod at bruge PHP kode på sin webserver

Når du skriver det på den måde kan jeg godt se det kan misforstås.

Det var bestemt ikke ment som en advarsel mod PHP.

Jeg ved ikke hvordan man så skal formulere det.
I bund og grund er det jo 'webmasteren' der er 'sikkerhedsrisikoen', uanset sprog/værktøj.

Din analogi har jeg tænkt lidt over.
Jeg tror jeg vil vende den til:
at hvis de fleste indbrudstyve bruger koben til at bryde ind i huse, så udgør koben en sikkerhedsrisiko, og man bør derfor sikre sine døre/vinduer ekstra godt mod koben.

  • 0
  • 0
Jan Keller Catalan

hvis de fleste indbrudstyve bruger koben til at bryde ind i huse, så udgør koben en sikkerhedsrisiko, og man bør derfor sikre sine døre/vinduer ekstra godt mod koben.

Man bør sikre sig, at man ikke selv har et koben liggende i et åbent udehus (~= man skal sikre sin webserver imod at have sikkerhedshuller i sin PHP-installation - især, hvis man ikke bruger PHP på sin server, men den alligevel er sat op til at kunne fortolke PHP)

men hvordan beskytter man sig imod hvad et malicious site bruger? Dér tabte du mig igen.

  • 0
  • 0
Anonym

men hvordan beskytter man sig imod hvad et malicious site bruger?

Jeg er ikke sikker på jeg forstår spørgsmålet.

Min egen lille 'undersøgelse' men tilhørende empiriske data tyder på at remote execution af PHP er den foretrukne metode til at inficere webservere på forskellige niveauer.

Både phishing sites, script injection, DDoS attacks osv.

Jeg har ikke dokumentation, men undervejs faldt jeg, udover de 'sædvanlige probes', over bla. et helt 'kontrolpanel', med indbyggede funktioner til stort set alle typer databaser, spam mail funktioner m.m.

Endvidere faldt jeg over en server hvor der lå et helt SDK til namogofer'en, både installation og removal, diverse javascript, samt ca. 400 directories med diverse 'malware'.
(Man havde glemt at slå directory listing fra:)

Webserverne i selv er(var) ikke berørt, men da de danner grundlaget for alle disse angreb via links i Mails, Facebook, script injection på troværdige sider m.m., vil jeg henføre dem under 'sikkerhedsrisiko'.

Ud fra denne betragtning vil jeg mene, at hvis samtlige PHP sites, globalt, sikrede sig mod remote execution, så vil man ad den vej indirekte have sikret sig.

Selvfølgelig er der inficering/injection via andre metoder, men det ville være en god start.

Man kan måske ændre analogien til:
Hvis alle indbrudstyve bruger remote execution, udgør det en sikkerhedsrisiko, og man bør derfor sikre sig ekstra godt mod dette.

  • 0
  • 0
Jesper Lund Stocholm

Jan,

Analogier er som regel "misbrugsvenlige", men jeg synes godt, man kan vende dine udtalelser til, at hvis de fleste indbrudstyve bruger stål-koben til at bryde ind i huse, så udgør stål en sikkerhedsrisiko og derfor bør man lade være med at bruge stål selv.

Det kan godt være, at PHP er det foretrukne værktøj for phishing-sites, men det betyder ikke, at det er en sikkerhedsrisiko.

Hmmm ...

"Analogier er som regel "misbrugsvenlige", men jeg synes godt, man kan vende dine udtalelser til, at hvis de fleste hackere bruger kode rettet imod Windows/IS til at hacke, så udgør Windows en sikkerhedsrisiko og derfor bør man lade være med at bruge Windows selv.

Det kan godt være, at Windows-kode er det foretrukne værktøj for hackere, men det betyder ikke, at windows er en sikkerhedsrisiko."

Hvis du bruger et værktøj, der har stor opmærksomhed i hackerverden, så udsætter du dig selv for en øget risiko for problemer i forhold til, hvis du brugte et mindre "kendt værktøj". Det er sådan uafhængigt af, om dit værktøj er IE, Windows, PHP eller PHP-baserede CMS-systemer.

Om værktøjet i sig selv så er skrevet godt eller skidt, eller om fx Windows i sig selv er sikkert eller usikkert, kan naturligvis lægge til- eller trække fra i regnskabet, men det er klart, at hvis du bruger et værktøj, som mange hackere har opmærksomhed på, så øger du din risiko for problemer.

  • 0
  • 0
Anonym

Med din udtalelse

Hvis du bruger et værktøj, der har stor opmærksomhed i hackerverden

kan vi så ikke afslutte denne diskussion.

Jeg bruger [b]ikke[/b] værktøjer, der har bevågenhed i hackerverdenen, og jeg bruger heller ikke værktøjer der er sårbare.

Jeg prøver at gøre opmærksom på nogle ting - take it or leave it.

(IDFC)

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize