Het probleem is niet dat deze variabelen bestaan, maar dat ze direct in een pagina gebruikt worden zonder eerst de gegevens te sanitizen.

Bijvoorbeeld: is een XSS-lek, maar is veilig.

Wellicht dat dit een beetje zal lijken te helpen, maar er is zoveel meer mis dat het uiteindelijk futiel zal blijken. PHP is redelijk onfixbaar, niet in de laatste plaats omdat de ontwikkelaars gewoon nauwlijks benul van taalontwerp hebben.

De taal wordt ook op grote schaal ingezet door "handige knutselaars" waardoor het vol zit met digitale equivalenten van, bijvoorbeeld, het niet problematisch vinden om een restje aardedraad als schakeldraad in te zetten omdat de schakeldraad op was. Daarnaast is het een broodwinner voor het type dat het moet hebben van "routineklussen, zoals programmeerwerk" die off-shore-baar geacht worden te zijn. Dat "meer dan 80%" van de websites PHP gebruiken zegt dan ook iets over het opleidingsniveau van de gemiddelde webklusser. In zekere zin een ode aan de notie dat het internet er is voor iedereen.

Maar dat wil niet zeggen dat het niet problematisch is. De echte oplossing is om over te stappen op andere talen, zoals python met een web framework naar keuze, of ruby on rails voor het hippere hipsterwerk. Maarja, dan moet je ineens structuur in je werk aanbrengen. PHP is nou juist zo populair omdat je gelijk kan beginnen en snel resultaat boekt. En het is ook echt handig --ondanks de vreselijke problemen met de taal, waar de meeste gebruikers overheenkijken omdat ze niet beter weten-- omdat het bijna overal te krijgen is en voor simpele dingen gewoon werkt. Een emailformuliertje aan een verder statische html website toevoegen is zo gedaan.

Dat het vervolgens niet schaalt en uiteindelijk tot een grote berg spaghetti met extragratis onverbeterbare beveiligingsproblemen verwordt, ondanks het onaflatende enthousiasme van de gebruikers, daar komen de meesten pas achter als het te duur wordt geacht te zijn om nog over te stappen. Zoals altijd, er is nooit tijd om het in één keer goed te doen, maar wel altijd tijd om het toch maar weer overnieuw te doen... met de verkeerde middelen.

Pro tip: Begin geen nieuwe projecten in PHP.

En dit is nou de reden waarom je mensen op een secure coding cursus moet sturen. Omdat je dan dit soort zaken weet. Nou nog een tooltje wat source analyseert en dit soort zaken eruit filtert... (https://www.owasp.org/index.php/Source_Code_Analysis_Tools )

My two cents....

Afschaffen die request parameters. Static HTML is good enough for everybody.

Serieus: zo lang je request variabelen mee kunt geven zullen er prutsers zijn die er een bende van maken. Dan helpt het niet als je 80% van de websites opeens onbruikbaar maakt.

Wat is het alternatief? Ik moet ergens in mijn app $_POST uitlezen toch? Hoe kom ik aan post data als het niet in $_POST zit?

@0101: het punt is dat jij dit snapt, maar 99% van de php-krabbelaars wereldwijd helaas niet...

Misschien moeten met eerst bewijzen dat ze veilig kunnen programmeren :)

Zie dit niet echt als een probleem voor PHP, deze dingen zijn er al jaren. En idd, ze kunnen een probleem worden, als je 1 op 1 de variable overneemt in je code zonder enige vorm van controle.

Lijkt me nog beter om de functie mysql_query() te verbieden.
Dat is pas echt een security nachtmerrie.
Alleen prepared statements ondersteunen en weg zijn alle SQL injectie problemen!

Tja, goed punt en je geeft redelijke goede alternatieven. Natuurlijk had je ook ASP.NET, Java en ColdFusion kunnen noemen. Of Perl. Of gewoon CGI/C++ voor het maken van websites.
Nu ben ik vast langer bezig met web design dan de meesten hier. Ik begon immers bijna 20 jaar geleden toen Internet nog met een 33k6 modem over de telefoonlijn ging en CompuServe een der weinen aanbieders waren. Ik heb veel technieken voorbij zien komen en heb het altijd wel leuk gevonden om mijn eigen webserver code te bouwen in C++ of Delphi/Pascal. Alleen, dat soort ontwikkelingen zijn traag en tegenwoordig spreekt men vooral over "Rapid" application Development, met de nadruk op snel ontwikkelen.
Web developers zijn beter af indien ze de tijd nemen voor het ontwerpen van websites. Weet waar je aan begint en weet welke risico's aan iedere techniek kleven. Weet ook hoe je die risico's kunt verkleinen of vermijden en wees niet te beroerd om desnoods meerdere technieken door elkaar te gebruiken om potentiele hackers wat meer last te geven. Leer eerst de basis voor je je specialiseert in een bepaalde taal. Want taal is niet belangrijk. De techniek wel.
En voor de klant telt ook de snelheid. Klanten willen hun site morgen al af hebben, niet volgende maand. Zorg dus voor een grote box gereedschap waar je van alles en nog wat uit kunt gebruiken waarvan je weet dat het veilig is en een snel resultaat zal opleveren.

[sarcasme] ASP.NET, Java en ColdFusion zijn echt veilig ja [/sarcasme] keep on dreaming

Het gaat niet om de taal, het gaat erom wat je er mee doet!

Als je vandaag de dag nog geen framework (Symfony2, ZendFramework2, Yii, Laravel) gebruikt voor een serieuze PHP website ben je inderdaad verkeerd bezig. Maar om dan te zeggen dat PHP inferieur is gaat helemaal nergens over.

PHP zal misschien minder ondersteunen dan C++ , Java of C# maar dat maakt het nog geen slechte taal.
PHP was ontwikkeld voor website ontwikkeling, en daar is het ook nog steeds prima voor geschikt.

Je zegt dat "in de laatste plaats omdat de ontwikkelaars gewoon nauwlijks benul van taalontwerp hebben."

Perl is te ver doorgeschoten in het gebruik van Regex, Ruby heeft de eigenaardigheid dat variabelen uit de context waarin de functie werd aangeroepen worden meegegeven aan de functie (open/closen principe?), C is gevoelig voor memory leaks en C++ word geliefd en gehaat. Dus wat is nu je punt? Geen taal is perfect. Uiteindelijk komt het allemaal op één ding neer: Getting s**** (stuff) done!

Zelf heb ik al meer dan 10 jaar ervaring met PHP, en heb ik verschillende projecten op mijn naam staan.
Ik heb serieus gekeken naar Python, maar ben uiteindelijk bij PHP gebleven omdat ik anders al het werk dat ik inmiddels opgebouwd kan weggooien, en dat is voor mij een te groot verlies.

Python bied zeker voordelen die ik (en andere) graag in PHP terug zouden zien.
Maar dan is het alleen om het werk makkelijker te maken, niet omdat ik niet in staat ben om dit op een andere manier op te lossen.

Wim geeft het inderdaad goed aan, de meeste websites vandaag de dag worden via het RAD principe gemaakt (een goed doordacht ontwerpen kan ik het niet echt noemen).

En daar zitten nadelen (veiligheid en en architecture) en voordelen (snelheid van bouwproces) aan.
Wat ook de reden is dat PHP veelal word geassocieerd met spaghetti code (PHP is een perfect taal voor RAD), wat in andere talen ook mogelijk is trouwens.
Maar waar veelal van begin af aan de nadruk word gelegd op gestructureerd werken, en je dus minder snel fouten maakt.

Daarom is het belangrijk dat we beginners vanaf begin af aan leren hoe het wel moet.
http://www.phptherightway.com/

En sommige doorgewinterde programmeurs is het al gelukt om geavanceerde OOP technieken (zoals CQRS, Domain Boundary) te gebruiken in PHP, misschien niet zoals je gewend bent met Java of C# maar ze werken wel degelijk.
http://whitewashing.de/2012/08/11/oop_business_applications__trying_to_escape_the_mess.html

Een beetje offtopic, van mij mogen ze heel MySQL verbieden (zoals het nu is).
Host restrictions via de zelfde database waar ook je beschermde gegevens instaan?!

Terug on topic.

Super-globals (niet SuperGlobals) zijn inderdaad een veiligheidsrisico, en dit is de reden waarom Symfony2 En ZendFramework deze informatie in een object opslaat bij het starten van de applicatie. Als de aanvaller iets wil doen kan dit alleen tijdens de applicatie runtime zelf, en omdat daar geen Super-globals worden gebruikt is het veel moeilijker om deze aan te passen via het overschrijven van variabelen.

Er is overigens wel een extensie voor PHP beschikbaar waarmee super-globals voor request informatie niet langer nodig zijn. http://nl1.php.net/http

Maar deze extensie is optioneel en bied geen bescherming tegen aanvallen op $_SERVER

De PHP developers zouden er dan ook goed aan doen super-globals te vervangen voor een Static Class waar deze informatie uit kan worden gelezen/geschreven. En super-globals deprecated te maken.

PHP is van ver gekomen, en de communitie erom heen word steeds volwassener.

Helaas is " htmlspecialchars($_GET['test'],ENT_QUOTES,'utf-8');" niet best practice. Je filtert nl. de input, echter je moet het zo strict mogelijk valideren.

Het gaat nl. niet alleen om security, maar ook om de betrouwbaarheid van je code. Je code moet met alle invoer, die je toelaat logisch zijn. Als je bijvoorbeeld een integer verwacht en je krijgt een string, dan kan je code onverwachte dingen gaan doen, waar een hacker misbruik van kan maken. Gebruik frameworks zoals bijvoorbeeld Zend, waar dit soort validators al voor je gemaakt zijn.

$validator = new Validator_Integer();
if($validator->isValid($_GET["id"]) === false){
throw new Exception("digit-not-valid");
}

$id = $_GET["id"];


@ Viognier: Mee eens, echter sommige talen nodigen wel meer uit tot slechte code. PHP is helaas zo'n taal. In php kan je echter wel veilig programmeren, je moet je er alleen wel in verdiepen.

Dit is een mooie gedachte, maar gaat helaas niet werken :)
Je kan simpelweg niet alles oplossen met preperated statements.

Probeer maar is de structuur van je database aan te passen via een preperated statement, grote kans dat je een foutmelding krijgt. En nee ook stored procedures kunnen lek zijn als de query handmatig moet samenstellen in de procedure.

Als je via één SQL injectie de gehele database kan slopen heb je een groter probleem dan het niet gebruiken van prepared statements.

Veel programmeurs die net uit de PHP-luiers komen denken dat ze alles al weten. Echt niet!
Eigenlijk zouden ze eerst alle ins en outs moeten leren, voordat hun "scripts" (van OOP is vaak nog geen sprake) op een productiemachine uitgevoerd mogen worden.
En anders is het vragen om problemen.

@Wim ten Brink 14:06
SQL-injection en dergelijke komt niet alleen bij PHP / MySQL voor!

In de tijd dat IE 6 net op de markt was, had ik een keer een tekst aan mijn useragent toegevoegd. Deze tekst bevatte een apostrof. Vervolgens bleken diverse websites niet goed te werken.
En ik weet zeker dat er weinig veranderd is sinds die tijd...

Dan krijg je gewoon weer van dit soort grappen:

$dbh->prepare("INSERT INTO table (x,y) VALUES ($_POST['x'], $_POST['y])");

(Of hoe precies die syntax ook moge zijn in PHP.) Er bestaat trouwens ook nog andere databases dan enkel Mysql

Ben je hier toevallig in de war tussen wat functies en closures zijn?

Kan korter :)
Ben je hier toevallig in de war tussen wat functies en closures zijn?[/quote]
Ik weet niet precies hoe closures in Ruby werken, ik kwam dit tegen in Gitlab.

Zelfs voor een closure zou het vreemd zijn omdat een closure normaal gesproken alleen weet van de context waarin hij is gefineerd en niet de context waarin hij word aangeroepen. Dat zou namelijk het closen/open principe breken.

Inclusief de ontwerpers. Zie url beneden.

Nee, want je bent een hoop gedonder kwijt. Zeker niet alles, want codekloppers die geen idee hebben wat ze zullen doen zullen domme dingen blijven doen, en er trots op zijn. Maar met PHP wordt dat versterkt door rariteiten in de taal zelf.

Nee. Frans, Engels, Italiaans, en Duits zijn niet algemeen beter dan elkaar, maar ze zijn wel beter voor bepaalde doeleinden. Niet voor niets dat Frans de taal der liefde wordt genoemd. Italiaans is wellicht nog het makkelijkst te leren van dit rijtje, Engels is een beetje een omhooggevallen boerentaaltje maar wordt wereldwijd gesproken, en Duits is nog altijd groot voor bijvoorbeeld filosoferen. Een taal heeft wel degelijk sterktes en zwakten.

Dat geldt nog veel sterker voor computertalen. Wil je snelheid in uitvoering of hele precieze controle, dan ga je dicht bij de machine zitten en gebruik je C, al kost het schrijven meer werk en meer oppassen met pointers en dergelijk. C++ is meer van hetzelfde maar dan met tooling voor grote projecten erbij. Java wordt veel gebruikt in grootbedrijven omdat je er minder hooggequalificeerde codekloppers voor nodig hebt dan voor C++. Maar het blijkt daar handiger grote stukken aan tekstmanipulatie met xslt en xpath en xquery te doen dan het in java zelf te doen. Dat zie je bij andere talen dan toch minder. C# is zeg maar redmondiaanse antwoord op java, met hun aloude vendor lock-in extragratis erbij. Ruby en Python zijn vergelijkbaar als algemene scripttalen, alleen de inslag is radicaal anders.

Al die verschillen maken wel degelijk uit, al moet je meer dan alleen PHP achter je kiezen hebben om dat te begrijpen.

Nee, het probleem met PHP is altijd weer dat het een omgeving is waar je je veilig waant (het is niet zoals C waar de geringste fout je programma opblaast) maar waar je ongemerkt allerlei onveilige dingen doet, in combinatie met een heel erg groot contingent gebruikers dat niet erg goed is in opmerken wat veilig is en wat niet. Ze weten gewoon niet beter.


Je zegt hier dat een je als je nou maar een grote berg "standaard" duck tape en sjortouw over een uiteenvallend gebouw uitstort dat je dan verkeerd bezig bent, maar een beter gebouw is natuurlijk onzin. Laat ik het daar niet mee eens zijn.

Als het fundament te zwak is en vol zit met scheuren, gaat geen enkele hoeveelheid verdere opbouw de fundamentele problemen oplossen. Dat is de situatie die we hier hebben. Je kan jezelf voorhouden dat pappen en nathouden je tijd wel zal duren, maar de enige echte oplossing is toch echt alles inclusief fundering afbreken en een nieuwe fundering leggen voor je opnieuw begint met opbouwen. Zuur, maar soms gewoon onoverkomelijk. Dat is waarom je Architecten nodig hebt die meer kunnen dan overal maar wat ideetjes vandaan jatten.

PHP heeft die zwaargewichten gewoon niet in huis. Nooit gehad. Degenen die iets meer konden zijn al lang geleden naar elders vertrokken, maar grote lichten zijn daar nooit in de buurt geweest. En het is de taal duidelijk aan te zien, voor iedereen die een klein beetje achtergrond in de materie heeft.

Het probleem is niet dat PHP "minder" ondersteunt. Ze hebben alles waar ze tegenaanliepen in de taal gegoten, zeg maar zoals Engels aan nieuwe woorden komt. Het probleem is dat het geen coherent geheel is, maar een zooitje van onbegrepen toevoegingen. En daar zitten dus regelmatig gaten en kieren in, en dus ook allerhande en vaak onoverkomelijke beveiligingsproblemen. Zeg maar een grote verzameling krotten in een sloppenwijk, dat niveau.

Laat ik het iemand anders wat langer zeggen:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Overigens maakt het verzinnen van een lange lijst klachten tegen andere talen jouw lievelingstaal niet ineens beter. Vooruitgang is als we uiteindelijk beter bruikbare talen overhouden. PHP is in die grote vertelling vooral bruikbaar als voorbeeld van hoe het niet moet.

Je presenteert jezelf als een stereotiepe PHP "programmeur" die het niet aandurft met echte talen te werken. Zeg maar een soort vbklopper die niets anders kan van de intarrwebs. Er is een goede markt voor je kunstjes, wel 80% van de verscripte websites kunnen je gebruiken volgens de redactie, maar qua beveiliging ben je nog steeds onderdeel van het probleem, niet van de oplossing.

Persoonlijk schrijf ik een paar meer talen en kies ik per project welke het beste past. Kritieken zoals jij schrijft over talen waar je kennelijk geen benul van hebt, zal je van mij niet horen.

"Nee, want je bent een hoop gedonder kwijt. Zeker niet alles, want codekloppers die geen idee hebben wat ze zullen doen zullen domme dingen blijven doen, en er trots op zijn. Maar met PHP wordt dat versterkt door rariteiten in de taal zelf."

Elke taal heeft zijn zwakheden. Python heb je minder van deze zwakheden dan Php. Toch moet elke programmeur in elke taal deze zwakheden kennen, voordat hij daarin serieus gaat programmeren.
BTW Javascript heeft wellicht nog meer rariteiten dan PHP en ook daar kan je er prima omheen programmeren. Zie https://www.youtube.com/watch?v=hQVTIJBZook

"Als het fundament te zwak is en vol zit met scheuren, gaat geen enkele hoeveelheid verdere opbouw de fundamentele problemen oplossen. Dat is de situatie die we hier hebben. Je kan jezelf voorhouden dat pappen en nathouden je tijd wel zal duren, maar de enige echte oplossing is toch echt alles inclusief fundering afbreken en een nieuwe fundering leggen voor je opnieuw begint met opbouwen. Zuur, maar soms gewoon onoverkomelijk. Dat is waarom je Architecten nodig hebt die meer kunnen dan overal maar wat ideetjes vandaan jatten."

Php bevat idd een hoop scheuren. Echter in php kan je prima om deze zwakheden heen programmeren. Een framework helpt daarbij maar is geen pas klare oplossing.

"PHP heeft die zwaargewichten gewoon niet in huis. Nooit gehad."
Zie bijvoorbeeld:matthew weier o'phinney - http://www.slideshare.net/weierophinney/architecting-your-models

"Het probleem is niet dat PHP "minder" ondersteunt. Ze hebben alles waar ze tegenaanliepen in de taal gegoten, zeg maar zoals Engels aan nieuwe woorden komt. Het probleem is dat het geen coherent geheel is, maar een zooitje van onbegrepen toevoegingen. En daar zitten dus regelmatig gaten en kieren in, en dus ook allerhande en vaak onoverkomelijke beveiligingsproblemen. Zeg maar een grote verzameling krotten in een sloppenwijk, dat niveau."

In php zitten naast de lelijke stukken, ook mooie. Om de hele taal te vergelijken met een sloppenwijk, gaat me wel erg ver.

"Je presenteert jezelf als een stereotiepe PHP "programmeur" die het niet aandurft met echte talen te werken."
Volgens mij is dat jouw interpretatie van wat hij heeft gezegd. Wellicht durft hij dat wel, maar is dat financieel niet handig. En is php dan geen echte taal?

"Persoonlijk schrijf ik een paar meer talen en kies ik per project welke het beste past."
Dat is een goede insteek.

Mijns inziens, heb je een te zwart beeld van php. De talen die je noemt hebben elk hun eigen problemen. Als een beginnend programmeur schrijft in Ruby of Python maakt hij wellicht minder security fouten dan in PHP. Echter volgens mij moet je ook bij Python en Ruby (zonder frameworks) je GET en POST parameters valideren. Daarnaast moet je in deze talen waarschijnlijk ook je output escapen, prepared statements toepassen, Session handling goed op orde zijn, je wachtwoorden hashen met salt etc etc. Basis kennis van de taal en van web beveiliging blijft noodzakelijk. Als je dit voor PHP beheerst kan je er prima webapplicaties mee bouwen, die goed kunnen schalen.

Een goed programmeur kent de zwakheden alsook de sterke punten in de talen die hij beheerst. Dat eerdere linkje maakt daar een mooi punt over, gelijk aan het begin. Vooral spijkers op laag water zoeken in andere talen is daaraan gerelateerd.

Het lost het fundamentele probleem niet op. Op andermans splinters vitten en van de eigen balk vinden dat er maar omheen gelopen moet worden is niet geloofwaardig.

Javascript is geen panacea (https://www.destroyallsoftware.com/talks/wat), maar door de niche die het inneemt een stuk lastiger te vervangen dan PHP. Iedereen zijn browser vervangen is namelijk meer werk, en voor de meeste mensen volstrekt onacceptabel, dan simpelweg het back-end van je eigen website vervangen, wat als jij je werk goed doet je gebruikers niet hoeven te merken.

Vindt jij dit serieus een tegenwerping op wat je aanhaalt? Wat daar te zien is, is verre van origineel, niet diepzinnig, en heeft helemaal niets met de structuur (als in, volstrekt gebrek daaraan) in de taal zelf te maken.

Ik vond het wel passen, zo om de sfeer vriendelijk te houden.

Lijkt me duidelijk wat ik daar van vind.

Ik denk dat ik voldoende materiaal aangedragen heb om mijn standpunt tegenover PHP uit te dragen en duidelijk te onderbouwen.

Je vergeet dat ruby en python algemene scripttalen zijn. Iets als ruby on rails is dat niet. PHP... is niet een algemene scripttaal.

Als PHP de enige taal is die je beheerst, dan niet. En als je meerdere serieuze talen beheerst dan weet je beter dan PHP voor meer dan een enkel snel formuliertje toe te passen.

Vandaar ook: Begin geen nieuwe projecten in PHP.

Ik vind dit een redelijk denigrerende reactie. Dus als je Joomla, Drupal of een ander CMS gebruikt, dan mankeert er iets aan je opleidingsniveau, aangezien dit meestal gebaseerd is op PHP i.c.m. MySQL. Ruby on Rails vind ik een slecht gekozen voorbeeld. Was het immers niet RoR wat Diginotar gebruikte? We kennen allemaal de geschiedenis. Kennelijk kun je ook met die tool flink onderuit gaan. Ik denk dat je toch moet spreken over het opleidingsniveau van de persoon die iets maakt met een tool als PHP.

Je conflateert hier dingen. Een CMS gebruik je om niet zelf code of zelfs maar HTML te hoeven kloppen: Je geeft je "content" in met een CMS-eigen markup en dan regelt dat CMS de rest wel. Een soort eenpersoonswiki maar dan met meer toeters en bellen. Verder bestaat er bij mijn weten geen regel die zegt dat alle CMSen in PHP geschreven moeten zijn.


Als je hier iets zinnigs over weet aan te dragen, moet je dat vooral doen. Vage "waar rook is, moet toch ook wel vuur te vinden zijn"-insinuaties hebben we niet zo vreselijk veel aan.


Ik denk dat ik hier vrij duidelijk geweest ben, maar kennelijk vond je het nodig je in vreemde bochten te wringen om je teentjes daaronder te schuiven. Laat ik het nog maar even samenvatten dan:

Er bestaan geen "100% veilige" ontwikkelomgevingen. En zelfs PHP is niet "100% onveilig". Maar PHP is wel zo'n ongeorganiseerd zooitje dat het ergens onderaan de ranglijst bungelt. En dat gecombineerd met vele PHP"programmeurs" die weinig benul van programmeren laat staan van veilig programmeren hebben, betekent dat er heel erg veel uiterst brakke code in omloop is. De oproep is dan ook om hier niet zelf nog verder aan bij te dragen.

Dat jij dan een hoop moeite doet om in "probleem herkennen" vooral denigratie te zien is dan niet echt een positieve bijdrage.