Delo - Danes sem malo čež dvanajsto uro opazil, da je bila spletna stran časnika Delo nedosegljiva. Sicer se je čez nekaj minut vrnila, je pa zato, po besedah urednikov zaradi tehničnih težav, bil nedosegljiv del strani, na katerem so objavljeni blogi uporabnikov. Po krajšem poizvedovanju sem ugotovil, da je šlo za več kot le tehnične težave.
Nekdo si je privoščil Delo in kratkomalo sesul sistem, na katerem so postavljeni blogi njihovih uporabnikov. Kot je razbrati iz tega zapisa, so se težave začele že nekaj dni prej, ko je ZliOsebek™ najprej izkoristil pomanjkljivosti sistema za umetno ocenjevanje lastnih (umetniško seveda ne posebej izvirnih) žnevniških zapisov, kasneje pa je ugotovil, da je možno s podobnimi prijemi tudi brisati poljubne zapise drugih avtorjev. Dobro, lahko bi govorili o zlobnih hekerjih, a je (pol)izdelek, imenovan Delo blog, že pred tem dogodkom doživljal mnoge kritike, ki pa jih, kot kaže, nihče na Delu ni jemal prav resno. Zato se se po mojem mnenju tudi ni čuditi pričakovanemu begu blogerjev k drugim brezplačnim ponudnikom, sploh ob trenutno dokaj neresnem odzivu, ki ga lahko vidite na spodnji sliki.
Nekako sem tole pri blog@delo pričakoval. Kar se tiče tega pubeca, je bilo uredništvo opozorjeno na njegovo početje že mnogo prej kot pa nekaj dni, kot je bilo to zapisano v tej novici. Zadeva se je vlekla... uf 2long...
Se strinjam, da se temu ni čuditi (begu)... a ne zaradi trenutnega odziva, ampak predhodnega ignorantskega obnašanja pri komunikaciji blogerjev in adminov... po mojem občutku je bil sistem kar prepuščen toku dogodkov...
So pac kekci. In namesto, da bi zdej oni ven spravli novico, kako so sami bili ignorantski do teh stvari, bomo poslusali spet kak oh in sploh hekrski napad se je zgodil. Zraven se morajo dopisati, da ocenjujejo skodo na 2 miljardi.
Zakaj negativen odnos? Kot je napisal xpozed - se je dogajalo že precej časa, varnost je na psu (kako lahko en uporabnik drugim briše vnose?), pa predvsem dokaj ignorantski in diletantski odnos odgovornih na Delu. Se zgodi...sam tole je pa rahlo neumno, se ti ne zdi?
Man is condemned to be free; because once thrown into the world,
he is responsible for everything he does.
[J.P.Sartre]
"Zraven se morajo dopisati, da ocenjujejo skodo na 2 miljardi."
Po zadnjih podatkih je škoda ocenjena na 2 milijardi slovenskih tolarjev
The main failure in computers is usually located between keyboard and chair.
You read what you believe and you believe what you read ...
Nisam čit'o, ali osudjujem (nisem bral, a obsojam).
Mislim, wau, wau, Delo uporablja php, ki je najbolj nezaščitena spletna tehnologija ever! Čisto drugače bi bilo, če bi uporabili kak Ruby on Rails ali Asp.Net 2.0, ki bistveno zmanjšajo takšne načine vdorov. Če mene vprašate, spletne strani narejene v php kr kličejo, da jih nekdo sheka. Zato sem jest osebno sklenil, da se ne bom več nikoli ubadal s php, ker se bo zmeraj nekdo našel, ki bo to "shekal".
in kakšno bi naj bilo pravilno opravičilo? mi namreč ni jasno.. a bi naj vsak bloger dobil zvišan ratio na njemu priljbenljenem torrent trackerju al kaj?
PARTyZAN: koliko so "shekali" php strani, koliko so "shekali" Ruby on Rails strani, koliko so "shekali" asp.net 2.0 strani !? Slednja dva se gibljeta med none in a few, medtem, ko je "shekanih" php strani že bilo preveč omenjenih. Že toliko je teh incidentov, da je bolje, da se php na sploh odsvetuje ozr. opozori razvijalce/vzdrževalce na številne nevarnosti, ki pretijo v samem php okolju.
Da ne boš misli, da pojma nimam, si preberi kakšno knjigo o PHP Security in boš videl, kako je ta php "švicarski sir" in na kakšne "finte" se da "vdirat" v spletno stran narejeno v php-ju. Mislim, da je vdiralec Dela prebral takšno knjigo in mu je bilo precej jasno, kako in kaj.
OK, vem da pretiravam, samo je res php izjemno nevaren, če nisi pozoren na vse možne finte vdora. Ozr. php po mojem mnenju preveč "ponuja" napadalcu. Asp.net 2.0 in RoR so po mojih izkušnjah po default bistveno bolj secure spletne aplikacije kot php aplikacije in ne govorim na pamet.
Eni tle se res mal preveč razburjate. Oz. dandanes vsakdo misli, da obvlada vse najboljše in da *njemu* se pa vdor ne more pripetiti. Pa kaj naj bi bilo narobe z Delovimi blogi? Meni se zdi reč čisto fina, sploh zato, da imamo Slovenci končno tudi slovenske blog hoste.
Ah, kakšni komentarji, da prime kakat. Komentarji da delov blog ni pravi blog. Ima to vezo z vdorom? Komentarji za PHP ni varen. Pa da je ASP.net varen. Ima to vezo z vdorom?
Ali ima vezo z vdorom da je nek kekec vdrl v sistem? Nobenih narekovajev ne rabimo, vdor je vdor.
Slabo so naredili programerji (kako hudiča lahko en user briše drugim poste? SQL inject? ne-preverjanje vhodnih parametrov v kaki delete funkciji?). Slabo se je pretestiralo. In če se je res vedelo da nekdo prčka po sistemu, se je slabo naredilo da se ni ukrepalo.
Če so pa vedeli za luknjo in je ne popravili, je pa lahko razlog ali nesposobnost programerjev (kar zelo težko verjamem da bi bilo pri nekomu ki dobi tak posel- tudi če nima pojma si bo opral ime in poiskal nekoga da bo to rešil zanj), bolj pa je pomojem tu resnica na tem (teoretiziram) da se je za bug vedelo, ampak ga programerji iz takega ali drugačnega razloga niso želeli popraviti. So se kregali? Hotli preveč? Ugibam.
To ali / da je php "nevaren" jezik pa je smešna trditev, sploh ob takem primeru. Dejstvo je, da je na LAMP velika večina OSS in popularnih aplikacij, dejstvo je da "lumpi" najdejo luknje in čeprav razvijalci popečajo, uporabniki ne upgrejdajo dovolj redno. Potem pa je luknja v softveru A (recimo phpbb) pa je nevem, 10k sajtov skrekanih, in je "kriv php".
V debato da je asp.net omejen na iis (swiss cheese) ne bom šel, je pa omenjeno na mnogo sajtih. Oracle naprimer pravi tole o ASP.NET vs PHP, pa mislim da omajo eksperte ki so prebrali več kot kako knjigo o exploitih kot nerdor:
ASP.NET officially requires that you use IIS. Unfortunately, IIS has a long history of vulnerabilities, which makes many administrators reluctant to deploy it to handle their web site. Whether these weaknesses are because of Microsoft's ineptness or because IIS is a real red flag to hackers is irrelevant: Those systems have a history of being hacked and compromised. PHP runs on Apache, too, which is fast and open source and has a good security track record. Also, as I mentioned, Apache runs on many platforms.
Vsak jezik je lahko nevaren. Aplikacije so danes prehitro in mnogokrat prepoceni razvite. Razvijal bi pa že vsak "računalničar"
PARTyZAN: koliko so "shekali" php strani, koliko so "shekali" Ruby on Rails strani, koliko so "shekali" asp.net 2.0 strani !? Slednja dva se gibljeta med none in a few, medtem, ko je "shekanih" php strani že bilo preveč omenjenih. Že toliko je teh incidentov, da je bolje, da se php na sploh odsvetuje ozr. opozori razvijalce/vzdrževalce na številne nevarnosti, ki pretijo v samem php okolju.
Razsvetli me. Nastej mi par teh "nevarnosti", ko jih je ze toliko. Spletna aplikacija je varna toliko, kot jo naredis varno sam.
Mimogrede: logicno, da je bilo vec "shekanih" strani, ki uporabljajo php, ce ga pa vecina spleta uporablja.
Phoebus, ne poznaš organizacije v velikih podjetjih. Menedžment odloča o tem, kaj se dela in kaj ne . Lahko, da majo nesposobne programerje, ampak oni so sposobni (in dolžni) take zamenjat. Stavim, da so jim dali NIČ časa za testiranje in odpravljanje napak, tudi po pojavitvi prvih manjših incidentov ...
Phoebus, skupaj z Oracle, govoris neumnosti o vanrosti IIS. Ne pozabit, smo leta 2006, in IIS 6.0 je med nami ze ~3 leta, v tem casu pa so nasli dve celi luknji (in jih tudi popatchali).
Matevzk: še kako dobro vem, kako je to v ne-it firmah, samo nisem nič o tem povedal :)
Na kratko- managerji NE vedo, ali so programerji dobri ali slabi. Nič ne vejo. Kupijo tam, kjer dobijo "največ". Tu pa lahko gledajo roke, ceno, ime, ipd.
Ker pa so si imena, cena in roki (dobri so zasedeni) nekako skregani, izberejo kar jim najbolj odgovarja.
Tako da kriviti management je smešno [dokler ne poči kje]. Kupiš avto ki ti je kul in si ga izbral pri trgovcu, ga voziš k njemu na servis. Se pelješ, vse zgleda lepo, začne ti ropotat auspuh, pa ti ni prioriteta zašvasat luknjo ker si brez denarja. Če ti bo kdo reku "ej, avspuh ti ropota" boš reku "ni mi prioriteta, bom že". In potem ti čez pol leta na skoraj novem, redno servisiranem avto odpade kolo.
A si kriv ti, ker si vozil k serviserju z dobro reklamo in cenami? Si kriv ti, ker nisi bil pripravljen zamenjat lonca na avspuhu? Ali so krivi mehankarji/proizvajalec ker so ti slabo pošeraufali avto?
Dejstvo je, da so krivi programerji.
AMPAK, poučna zgodba:
Pri punci v firmi so iskali nekoga ki bi jim naredil stran. Klasično povpraševanje- celostna podoba/struktura, seveda CMS, profi izgled, nekaj malega specifične funkcionalnosti.
Nič strašnega. Cene so bile vse tam-tam, +- 200 jurjou (pa prosim naj se ne oglašajo tisti ki to "naredijo za 100, tu pa se govori o +-200"; tisti ki je zares v tem poslu, ve kakšne so cene).
Izbrali so firmo, ki bi jim naredila v X (malo) dnevih od podpisa pogodbe in je imela dokaj lep /po izgledu/ portfolio. "Taveliki" so bili seveda predragi ali pa imeli predolge roke.
Zadeva se je podpisala, in uni "predstavnik" je vsake par dni "skočil" okoli z novo celostno strukturo, najprej nekajkrat kar s slikami, potem pa s statiko iz DW. Seveda so naročniki ponoreli, ker se je to skakanje vleklo že več kot mesec in zahtevali v roku tedna rezultat, sicer bodo padli penali.
In rezultat? Po enem tednu aplikacija, ki "se ne prikazuje čisto dobro v mozilli, dela pa v IE". CMS skropucalo da se ga bog usmili. Dodajanje določenih vsebin je dinamično na način, da se kliče izvajalca da doda.
Vsekakor je tu kriv naročnik da ni znorel, usekal penalov, ipd... samo stvar se je buckala levo in desno dokler ni bil izgled v vseh treh "uporabljanih" browserjih primeren in ni delalo kot si predstavlja naročnik, potem pa konec- o varnosti pa nihče nič. A bo potemkriv naročnik da ni pregledal kode?
In na tej točki je (bilo) delo. Zadeva je -po njihovem- ustrezala zahtevam. Managerji ne vedo nič o tem, kaj je v kodi!
MS: Ne bom rekel nič, ne vem kako je z IIS. Sem samo C/P iz oracle strani.
Seveda pa pogodbe naredijo stvar malo smešno. "Ne odgovarjamo za morebitno izgubo podatkov, ki bi lahko nastala ob uporabi našega programa" je tako zelo znana vrstica. Ampak če ima program tako očitno varnostno luknjo, je kriv programer!
Tako kot je proizvajalec avtomobila kriv, če se avtomobili samovžigajo. Čeprav "ne odgovarjajo za samovžige" Tako kot je proizvajalec računalnikov kriv, če stresa elektrika. Čeprav kje piše da ne odgovarjajo. Tako kot je proizvajalec igrač kriv, če igrača razpade prehitro. Čeprav piše da je igrača za "normalno" rabo. ....
Da bo moja trditev o krivdi programerja dobila še malo podlage.
MS, reciva da delaš nek program za neko firmo. Ta firma ga na veliko uporablja, ti pa si priden pa vsake tolko narediš update. Ali pa naj bo to CMS, nima veze. In potem narediš verzijo X, ki si jo spisal ves utrujen, rok te je basal, pa si rekel "bom dal vseeno že danes gor, sej dela, juhuhu".
Naslednji dan pa pizderija, izginila vsebina vseh spletnih mest / izignili vsi dolgo-vnašani podatki v SW. Pustiva backupe. ampak, boš rekel da ni krivda tvoja, programerska, da je v programu napaka? Seveda bi bila tvoja.
Kar vem tudi zase, ker tudi sam veliko programiram.
Ok, mogoce se lahko omejimo na zacetek: backup/restore. Ce tega ni, se nimamo kaj pogovarjat, ker je taka resitev krep. Baza mora bit bekupirana. Ce gre to za take malenkosti, se mora to izvajat dnevno. Tko da, ce ti naredijo pizdarijo, kot so jo v tem primeru, potegnes backup. Samo, to mora naredit tisti, ki je zadevo izdelal. Ce tega ni, je ze stvar v osnovi na slabi osnovi.
In zaradi slabo napisanega programa naj se pa kar dnevno dela backup baze? Še bolje, zakaj ne kar vsako uro, nikoli ne veš, kdaj bo heker udaril. Pa saj se tu ne gre za kakšne občutljive podatke, tako da je dnevno backupiranje prevelik overhead.
Sicer pa do take situacije, da se zaradi programske napake cela baza pobriše in je treba narediti restore, sploh NE BI SMELO priti, pika. SQL injection je ena izmed osnovnih potencialnih nevarnosti in nanjo opozarja vsak resen tutorial, to pa zato, ker so posledice lahko zelo hude. In kdor teh varnostnih osnov ne pozna, se naj ne gre programiranja. Isto velja za nedeljskega "informatika", ki je odgovoren za aplikacijo, a pri tem ignorira opozorila o potencialnih varnostnih luknjah. Restore baze je potem samo še gašenje požara in omiljanje posledic.
Tako kot je nekdo pred mano rekel: danes bi že kar vsak nekaj programiral za male pare, zato pa se takšne in podobne situacije vse prevečkrat pojavljajo.
Hja, če bi bil nesramen, bi rekel, da je to posledica novih razmer na DELU. Čeprav delno je to morda celo res. DELO se trenutno ukvarja samo s sabo in s politiko, namesto, da bi se ukvarjalo z zadevami, s katerimi naj bi se ukvarjali. To pa so bralci in publika.
Slovenskih blogov ne berem prav pogosto, zato me zanima, ali obstaja neka centralna "lokacija", kjer se najde večina slo blogov, tako kot recimo www.blog.hr pri naših sosedih? Na blog.si je kr neki, se mi zdi prav škoda domene.
Dodatek: glede na to, da je v Slo. več blog-hosting servisov, ali je kje kakšen seznam le-teh, ali pa vsaj statistika števila blogov na posameznem servisu?
Phoebus, očitno imava različno situacijo v mislih. Aja, Microsoft, midva tudi .
Vse je odvisno od organizacije v podjetju. Če je ta slaba, lahko programer naredi veliko traparij. In če programer lahko naredi veliko traparij, jih bo . Zame je torej kriv menedžment. Prav tako so oni krivi, če ne znajo ločiti med dobrim in slabim programerjem. Ljudi, ki jih imaš pod seboj, moraš poznati, vedeti moraš, kako dobro opravljajo svoje delo ... Seveda, če v primeru, ki ga je navedel Microsoft, programer reče "stvar sem stestiral in dobr dela", pa mu potem rečejo naj deploya in se izkaže, da je "luknjasta", je programer slabo (če sploh) stestiral in je on kriv.
Če pa programer reče "ej, premalo časa sem imel za tole reč, luknjasta je, lahko bi celo prišlo do vdorov" in vodstvo reče "zaenkrat bo dobr, nimamo resursov za to popravljat" -- in to je scenarij, ki se mi zdi najbolj verjeten za Delo -- je pa to management failure. Phoebus, ti si očitno imel v mislih študenta na počitniškem delu, ki "zna programirati" in je to stvar spacal skupaj, potem pa še če je kdo pomislil na to, da bi kaj popravili, ni hotel njegovega skrpucala nihče niti pogledati več. Tudi to je možno, ampak na (predhodnje manjše) incidente bi moralo reagirati vodstvo, programerji ne morejo kar sami nečesa začet delat ....
Cyb3r, torej so slo blogi raztreseni po raznoraznih domenah in naslovih. Predvidevam, da so na siblogs.com seznamu samo tisti, ki so se sami registrirali tam. Na siblogs jih je našteto 330 v slovenščini + 91 v drugih jezikih, na blog.hr je pa čez 100 tisoč blogov... Nekako se ne morem upreti vtisu, da bi lahko tudi v Slo. nastal "boom" blogov, če bi obstajal nek "glavni" blog hosting servis. Mogoče pa le manjka malo (dobro usmerjenega) oglaševanja.
Še komentar na pripombo od jeti51 glede dnevnih backupov: ne glede na to, kakšen je softver, moraš imeti REDNE backupe. In ja, dnevni sql dumpi so nekaj vsakdanjega v resnem delu.
Še bolje je imeti tracking sistem na sistemskem nivoju (kot ima npr. MS mail server), tako da ne moreš izgubiti NIČ. Še pesmica za sprostitev:
Yesterday, All those backups seemed a waste of pay. Now my source files have all gone away. Oh I believe in yesterday.
Suddenly, There's not half the files there used to be, And there's a milestone hanging over me. The system crashed so suddenly.
I pushed something wrong What it was I could not say. Now all my data's gone and I long for yesterday-ay-ay-ay.
Yesterday, The need for back-ups seemed so far away. I knew my data was all here to stay, Now I believe in yesterday.
ne glede na to, kakšen je softver, moraš imeti REDNE backupe. In ja, dnevni sql dumpi so nekaj vsakdanjega v resnem delu.
Obregnil sem se v to, da naš Microsoft za izhodišče postavlja pogoj, da se delajo dnevni backupi, jaz pa sem želel povedati, da je še bolj bistveno, da se najprej pokrpa sama aplikacija. Bolje brezhibna aplikacija, ki bo restore baze zelo redko potrebovala (npr. če pride do napake v hardwareu), kot pa luknjasta aplikacija, kjer je znova in znova treba delati restore - npr. enkrat dnevno ali več.
Mislim, da ni dvoma, katera možnost je boljša in kje se je treba (oz. bi bilo treba) najprej lotiti problema. Restore baze je, kot sem rekel, samo gašenje požara, medtem ko je dobro napisana aplikacija učinkovita preventiva pred požari. No, seveda so tudi redni backupi potrebni, a pri luknjasti aplikaciji ti bolj malo koristijo, saj ti lahko po vsakem restoru podatke v momentu spet pobrišejo in aplikacija lahko zelo hitro postane popolnoma neuporabna.
Ena bolj nezrelih izjav, kar jih slišiš. Krivit orodje za človeške napake? Kdor se spozna, mu je jasno, da so luknjaste APLIKACIJE, ne orodje. Kladivo je tud nevarno, če ga napačno apliciraš na problem oz. ga ne znaš uporabljat. Uhhh, otroci.
Pri softwareu je pa itak tako, da tisti, ki je najbolj razširjen, je najbolj napadan. Zato so Windowsi "nevaren" sistem. Gremo stavit, da če bi obrnili tržne deleže windowsev z linuxom, bi blo več exploitov znanih za linux, kot za windows?
In IE vs Firefox isto. Čim je Firefox pridobil na množici, so začeli leteti exploiti. Ne bom trdil, da je ENAKO luknjast, kot IE (ker menda ni), ampak point je, da je luknjavost softwarea (v smislu koliko lukenj ljudje poznajo) odvisna v največji meri od razširjenosti tega softwarea. Spet enako velja za phpBB.
Bistvena razlika je v tem, kako enostavno je naredit luknjo. PHP je glede tega blazno tragicno orodje. Skoraj vsak, ki dela s PHPjem, naredi kaksno luknjo.
Obstajajo bistveno boljsa orodja, nekatera izdelana tudi s PHPjem, ampak PHP sam od sebe to ni.
IE vs Firefox niti priblizno ni isto. Vsak rad razlaga kako je luknjavost softvera odvisna od popularnosti oz. trznega deleza. Ni res. IE je _bistveno_ bolj luknjast kot Firefox, je pa res, da je za to kriva predvsem globoka sistemska integracija IE, ki mu daje se posebej velik head-start pri luknjavosti.
Bistvena razlika je v tem, kako enostavno je naredit luknjo. PHP je glede tega blazno tragicno orodje. Skoraj vsak, ki dela s PHPjem, naredi kaksno luknjo.
Torej vsak, ki to orodje nepravilno uporablja.
IE vs Firefox niti priblizno ni isto. Vsak rad razlaga kako je luknjavost softvera odvisna od popularnosti oz. trznega deleza. Ni res.
1) Nisem opazil, da vsak. 2) Luknjavost software NI odvisna od popularnosti. Luknjavost, ki jo trg pozna, pa je. To razliko sem jasno poudaril v prejšnjem sporočilu. Seveda ni odvisna IZKLJUČNO od tega, je pa velik faktor. Program, ki ga uporablja 90% vseh ljudi na svetu, bo pokazal svoje hibe zelo zelo hitro. Več ljudi, več naključno odkritih lukenj, več otrok, ki imajo preveč časa in šarijo po zadevah. Lahko rečeš, da to ni res?
IE je _bistveno_ bolj luknjast kot Firefox, je pa res, da je za to kriva predvsem globoka sistemska integracija IE, ki mu daje se posebej velik head-start pri luknjavosti.
Saj sem rekel, da je IE verjetno bolj luknjast. Da je to res, lahko sicer z dokajšnjo gotovostjo verjamemo vsi, vemo pa ne. Dejstvo, ki ga ne moreš zanikati, je, da je Firefoxu s priljubljenosto narastlo tudi število exploitov. Zdaj pa preprosta linerana matematika: večaj priljubljenost in razširjenost firefoxa, istočasno pa manjšaj iste parametre IE-ju. Ko dobiš obratne deleže, boš imel tudi obrnjen tržni delež exploitov. Še vedno bo sicer IE relativno bolj luknjast, ampak število njegovih znanih exploitov bo precej manjše od Firefoxovih.
Ja, lahko. Ce bi bilo to res, potem bi imel google iskalnik najvec lukenj, ker ga uporablja ogromno ljudi in bi se torej moralo odkrit luknje. Wrong.
Tudi apache streznik, ki je izredno popularen, nima prav veliko lukenj. Tudi IIS6, ki je precej popularen, jih ima razmeroma malo. Seveda ima "user base" vpliv na to koliko napak se najde, nikakor pa to ne vpliva na kvaliteto in varnost softvera.
fatg> Obstaja zelo velika možnost, da dlje kot ti.
Potem ves, da je bil PHP dolgo casa zelo naklonjen nevarnemu programiranju in se je tako programiranje dolgo casa celo spodbujalo v dokumentaciji.
fatg> Torej vsak, ki to orodje nepravilno uporablja.
Ce 90% programerjev orodje uporablja nepravilno, je ocitno nekaj narobe z orodjem. Obstajajo orodja, ki jih pravilno uporablja 100% programerjev.
Ja ampak ce tako gledas potem programiranje spletnih aplikacij v PHPju lahko primerjas z rezanjem hrenovk z motorko. Da se, a je nevarno, ker orodje ni ravno optimalno za izvedbo danega opravila.
Ja, lahko. Ce bi bilo to res, potem bi imel google iskalnik najvec lukenj, ker ga uporablja ogromno ljudi in bi se torej moralo odkrit luknje. Wrong.
Tudi apache streznik, ki je izredno popularen, nima prav veliko lukenj. Tudi IIS6, ki je precej popularen, jih ima razmeroma malo. Seveda ima "user base" vpliv na to koliko napak se najde, nikakor pa to ne vpliva na kvaliteto in varnost softvera.
Eno je nekaj, kar samo po sebi NI luknjasto, omogoča pa razvoj luknjastega softwarea (razvojna orodja), drugo pa je software, s katerim ti ne moreš "proizvajat" lukenj, lahko pa so sama po sebi luknjasta. Apache lahko skonfiguriraš tako, da imaš luknje, ne moreš pa z apachejem producirati lukenj.
GMail je imel par varnostnih lukenj, ki so omogočale neke ne preveč fine zadeve. Ampak v GMailu ti ne moreš razviti nečesa neodvisnega, kar bi ljudje uporabljali na svojih računalnikih. Razlika je velika.
Potem ves, da je bil PHP dolgo casa zelo naklonjen nevarnemu programiranju in se je tako programiranje dolgo casa celo spodbujalo v dokumentaciji.
To je res, čeprav se ne bi strinjal z izrazom "naklonjen nevarnemu programiraju". So pa z odkritji lukenj sproti odpravljali napake. To, da razvijalci še vedno uporabljajo prijeme, ki so pred 3 leti bili v dokumentaciji, pa jih sedaj ni (ali pa celo so, z opozorilom kako tega NE smeš uporabljat), je problem razvijalca, ne PHPja.
Ce 90% programerjev orodje uporablja nepravilno, je ocitno nekaj narobe z orodjem. Obstajajo orodja, ki jih pravilno uporablja 100% programerjev.
Kakor obrneš. Dejstvo je, da ima očitno to orodje (v primerjavi s kakšnim drugim) neko miskomunikacijo z uporabniki. Vendar je ta debata bolj komplicirana, potegne namreč s sabo celo take argumente, kot so starost in izkušenost programerjev. PHP ima najmlajšo populacijo, kar posledično pomeni najmanj prebrane dokumentacije, izkušenj in vsega tega, kar močno vpliva na končne produkte. AMPAK. Vztrajam pri tem, da je to problem razvijalcev. Če vejo, da niso kompetentni v uporabi PHP-ja, naj ga ne uporabljajo. Saj so še druga orodja na svetu. Ni ti treba spravljati PHP-ja ob slab glas, ker obupno slabo sprogramiraš phpBB in PhpNuke, potem pa PHP seveda nosi slab prizvok.
No, to ni nujno, da je orodje zgreseno, lahko je pisano v mislih s popolno svobodo, ki marsikaj omogoca.
Deloma je tud to res. :) Orodje, ki zapira možnosti, ni dobro, pomembno je razmerje med odprtostjo in varnostjo. Razvojna orodja pa naj sploh ne bi zapirala možnosti. - Hočeš zbrisat pol diska? Lahko. - Boš spisal aplikacijo, ki to naredi? Če hočeš. - Je to dobro? Verjetno ne. - Boš to naredil? Ne. Razen mogoče po nesreči, ker ne znaš uporabljati orodja.
Ja ampak ce tako gledas potem programiranje spletnih aplikacij v PHPju lahko primerjas z rezanjem hrenovk z motorko. Da se, a je nevarno, ker orodje ni ravno optimalno za izvedbo danega opravila.
Dober argument. Prvo pravilo dobrega razvijalca je: uporabi orodje, primerno problemu. Ampak dober razvijalec bi tudi s slabim orodjem naredil spodobno zadevo. Slabi razvijalci so problem. Taki bi naredili varnostne luknje tudi v "varnem" razvojnem orodju, brez skrbi.
Ja, saj jaz uporabljam PHP. Pravzaprav ga poznam tako dobro, da tocno vem, zakaj ga sovrazim. Ker prepocasi pospravlja z lastno zgodovino. Recimo da je PHP 5 pomemben korak v pravo smer in da se reci pravilno odvijajo naprej, ampak sam jezik je danes ze mocno zastarel in neprakticen.
Python in Ruby sta bistveno blizje jeziku, ki ga zacetnik ne more zlahka zlorabiti in jeziku, ki ga izkusen programer lahko pripravi do tega, da pocne velicastne reci.
. Lahko, da majo nesposobne programerje, ampak oni so sposobni (in dolžni) take zamenjat. Stavim, da so jim dali NIČ časa za testiranje in odpravljanje napak, tudi po pojavitvi prvih manjših incidentov ... 
Pa saj se tu ne gre za kakšne občutljive podatke, tako da je dnevno backupiranje prevelik overhead.
