Beveiligings vraag

Wat wil je precies beveiligen? Het gaat hier om een link daar valt niet veel aan te beveiligen lijkt me?

Anders zul je je vraag iets duidelijker moeten formuleren

Ik ga mee wat diestro zegt, wat wil je precies beveiligen?

Hoeft niet beveiligd te worden..

Enige wat je moet beveiligen is je server side code, daar moet je dus volgende paramater: ?online= Netjes gaan escapen indien je a.h.v. deze paramater een database interactie doet.

Indien je standaard mysql gebruikt kan je de functie: mysql_real_escape_string($_GET['online']); gaan gebruiken.
Indien je mysqli of PDO gebruikt dan hoef je enkel deze parameter te binden in je querie (voorbeelden genoeg online)

Veel success!

Citaat van MiCa-

Hoeft niet beveiligd te worden..

Uhm, dat staat niet op voorhand vast. Indien de getoonde informatie na aanroep van die link niet voor iedereen is bedoeld zul je wel degelijk enige controles in moeten bouwen...

Citaat van MiCa-

Enige wat je moet beveiligen is je server side code, daar moet je dus volgende paramater: ?online= Netjes gaan escapen indien je a.h.v. deze paramater een database interactie doet.

Ook dit is niet helemaal volledig. Ten eerste zou je je input moeten filteren, als $_GET['online'] niet bestaat of niet het juiste formaat heeft hoe je de query niet eens uit te voeren.

Citaat van MiCa-

Indien je standaard mysql gebruikt kan je de functie:

Indien je nog standaard mysql gebruikt moet je als de sodem... wiedeweerga overstappen op MySQLi of PDO. Zeker als je bezig bent met het schrijven van nieuwe code. Dan code schrijven die via mysql_-functies interactie heeft met je database staat bijna gelijk aan tijdsverspilling omdat deze functies al ~10 uitgerangeerd zijn en binnenkort voorgoed verdwijnen (PHP7 heeft ze niet meer geloof ik).

Citaat van FangorN

Uhm, dat staat niet op voorhand vast. Indien de getoonde informatie na aanroep van die link niet voor iedereen is bedoeld zul je wel degelijk enige controles in moeten bouwen...

Ook dit is niet helemaal volledig. Ten eerste zou je je input moeten filteren, als $_GET['online'] niet bestaat of niet het juiste formaat heeft hoe je de query niet eens uit te voeren.

Indien je nog standaard mysql gebruikt moet je als de sodem... wiedeweerga overstappen op MySQLi of PDO. Zeker als je bezig bent met het schrijven van nieuwe code. Dan code schrijven die via mysql_-functies interactie heeft met je database staat bijna gelijk aan tijdsverspilling omdat deze functies al ~10 uitgerangeerd zijn en binnenkort voorgoed verdwijnen (PHP7 heeft ze niet meer geloof ik).

Mee eens hoor
Maar client side code tonen / verbergen a.h.v. een variabele noem ik niet persee beveiligen. Je kan als het ware ook zelf de URL invoeren zonder dat je hem kan zien op de website.. Dus het blijft zeer belangerijk om server-side deze toepassingen te gaan beveiligen.

Overigens zie ik nog heel veel projecten (waar ik help of verbeter) die de oude mysql fncties gebruiken, en ik denk niet dat al die projecten de enige zijn op het web..
Het is inderdaad ten zeerste aangeraden om over te schakelen naar mysqli of PDO, maar voor heel grote projecten kan dit zeer lastig worden. Deze blijven dan dus ook draaien op een PHP versie die mysql_ nog ondersteunt.

Maar zowizo vroeg of laat zal het moeten, en dan zullen de meeste telaat zijn zoals gewoonlijk..

Citaat van MiCa-

Mee eens hoor Maar client side code tonen / verbergen a.h.v. een variabele noem ik niet persee beveiligen. Je kan als het ware ook zelf de URL invoeren zonder dat je hem kan zien op de website.. Dus het blijft zeer belangerijk om server-side deze toepassingen te gaan beveiligen.

Overigens zie ik nog heel veel projecten (waar ik help of verbeter) die de oude mysql fncties gebruiken, en ik denk niet dat al die projecten de enige zijn op het web..
Het is inderdaad ten zeerste aangeraden om over te schakelen naar mysqli of PDO, maar voor heel grote projecten kan dit zeer lastig worden. Deze blijven dan dus ook draaien op een PHP versie die mysql_ nog ondersteunt.

Maar zowizo vroeg of laat zal het moeten, en dan zullen de meeste telaat zijn zoals gewoonlijk..

Wat eigenlijk echt een slecht argument is, want die programmeurs (en jij) van die projecten weten donders goed dat die functies deprecated zijn dus ook aan vervanging toe zijn en dat is absoluut niet moeilijk om te doen.

Zoals @FangorN zei:

De volgende functies zijn deprecated en verwijderd uit PHP7.

• ext/ereg (since PHP 5.3; use ext/pcre instead) REMOVED (PECL extension)
• ext/mysql (since PHP 5.5; use ext/mysqli or ext/pdo_mysql instead) REMOVED (PECL extension)

Citaat van Tredgy

Wat eigenlijk echt een slecht argument is, want die programmeurs (en jij) van die projecten weten donders goed dat die functies deprecated zijn dus ook aan vervanging toe zijn en dat is absoluut niet moeilijk om te doen.
Zoals @FangorN zei:

De volgende functies zijn deprecated en verwijderd uit PHP7.

• ext/ereg (since PHP 5.3; use ext/pcre instead) REMOVED (PECL extension)
• ext/mysql (since PHP 5.5; use ext/mysqli or ext/pdo_mysql instead) REMOVED (PECL extension)

Ik weet donders goed dat die functies niet deprecated zijn zolang wij zelf kiezen welke PHP versie we gebruiken
Ook zitten we met ons bedrijf met meer dan 300 websites van de 400 die nog oude mysql functies gebruiken.

Zou jij het zien zitten al die websites om te bouwen?
Wij dus ook niet

Het is al jaren bekend dus..

Jij dus ook niet zul je bedoelen. Als jij als bedrijf dat niet ziet zitten om die om te zetten dat doe jij als bedrijf toch iets fout. Zijn gewoon kosten die je door kan berekenen. Die functies zijn wel deprecated waarom zouden ze anders in PHP7 verwijderd worden.

Je kan hier nog wat kennis op spijkeren: Why not to use MySQL extension

Volgens mij heeft TS trouwens genoeg tips gehad om de kwestie op te lossen.

Als jij dat trouwens als bedrijf niet ziet zitten om dat te doen, mag je ze doorzetten naar mij dan verdien ik er zelf wel wat aan.

Citaat van MiCa-

Ik weet donders goed dat die functies niet deprecated zijn zolang wij zelf kiezen welke PHP versie we gebruiken

Maar met nieuwere versies komen er ook bug- en security fixes, verbeterde performance en andere/nieuwe functionaliteit. Daarnaast moet je ook de hard- en software (EDIT: van de webserver zelf) in beschouwing nemen waar soortgelijke overwegingen (met name ten aanzien van security) spelen. Als je zelf dedicated servers beheert dan heb je deze vrijheid, maar de vraag is of je je dat op langere tijd kunt veroorloven.

Citaat van MiCa-

Ook zitten we met ons bedrijf met meer dan 300 websites van de 400 die nog oude mysql functies gebruiken.

Citaat van MiCa-

Zou jij het zien zitten al die websites om te bouwen?
Wij dus ook niet

Dit (legacy) probleem (als je het zo kunt noemen) gaat niet vanzelf weg en wordt over tijd alleen maar "groter". De eerste stap om langzaam naar een oplossing toe te werken is allereerst ruimte creëren om dit onderwerp bespreekbaar te maken, binnen de organisatie maar ook daarbuiten. Vaak zijn klanten zich niet bewust (of willen niet begrijpen) dat software een beperkte houdbaarheidsdatum heeft. Je zult dus ook moeten werken aan het creëren van begrip bij klanten dat code onderhouden moet worden, dat hier tijd in gaat zitten en (dus) dat dit geld gaat kosten. Dit valt onder verwachtingsmanangement als je het mij vraagt.

Het klinkt niet alsof je hier actief mee bezig bent maar misschien is het verstandig om hier eens een balletje over op te gooien want when smelly substances hit a rotating object (oftewel, er komt een moment dat je niet meer over kan maar over moet en als je dan geen plan hebt) dan heb je ECHT een probleem.

En uit een eerdere post:

Citaat van MiCa-

Overigens zie ik nog heel veel projecten (waar ik help of verbeter) die de oude mysql fncties gebruiken, en ik denk niet dat al die projecten de enige zijn op het web..

Mja, maar dat is dus in zekere zin een ontwerpfout. Je hebt alle mysql_-functies waarschijnlijk hard in je code staan. Stel nu dat je hier een of meer wrapper classes voor had geschreven (of zelfs wrapper functies). Het omschakelen naar MySQLi was dan in zijn simpelste vorm een kwestie van het aanpassen van de implementatie van je wrapper classes geweest. Dan hoefde je in elk project -in het eenvoudigste geval- slechts enkele regels code te vervangen in plaats van een search-replace door je hele codebase te doen (met toevoegingen van een database-link-parameter).

Als je slim bent doe je dit nu voor oplossingen met MySQLi (of zelfs PDO) alsnog zodat je niet rechtstreeks (API-specifieke) database-functies aanroept. Een ezel stoot zich in het algemeen...

Tevens: deze thread is enigszins offtopic geraakt, moderators, doe jullie werk.

Heb het over websites die in ons bedrijf al meer dan 10 jaar bestaan en dat zijn er een hele boel.
Inderdaad zijn alle mysql functies aanwezig in alle scripts en dit zou mijn baas een zeer groot verlies oplevern..

Jullie moeten mij niet de les spellen i.v.m. PDO of MySQLI want ik ben de persoon die ervoor gezorgd heeft dat ons bedrijf vanaf 2013 PDO gaat gebruiken voor alle projecten sinds dien..

Zoals eerder vermeld hebben we nog steeds +300 websites die gebruik maken van mysql_, hier word ook beetje per beetje aan gewerkt!
Het is onmogelijk voor ons om al deze aanpasingen door te voeren in een zeer korte tijd, vandaar onze keuze om PHP5+ te gaan blijven gebruiken tot we kunnen overschakelen naar 7 maar dit is volgens ons pas mogelijk tegen 2020

M'n baas ziet zelf ook in dat dit niet allemaal in een korte tijd kan gebeuren aangezien we een flink verlies zouden maken.
Ik zeg niet dat we er geen aandacht aan besteden! Ik zeg enkel dat het een zeer grote stap is voor een groot bedrijf die niet zomaar even kan genomen worden, we moeten rekening houden met heel veel klanten en ons ook kunnen blijven focussen op openstaande projecten.

Citaat van MiCa-

Jullie moeten mij niet de les spellen i.v.m. PDO of MySQLI want ik ben de persoon die ervoor gezorgd heeft dat ons bedrijf vanaf 2013 PDO gaat gebruiken voor alle projecten sinds dien..

Gebruik je naast MySQL ook andere database typen dan (EDIT: en in hoeveel gevallen)?

Citaat van FangorN

Tevens: deze thread is enigszins offtopic geraakt, moderators, doe jullie werk.

Interessante discussies geven wij graag de ruimte. als de TS maar goed geholpen wordt, vinden we het niet erg dat jullie extra informatie toevoegen.

Citaat van MiCa-

Heb het over websites die in ons bedrijf al meer dan 10 jaar bestaan en dat zijn er een hele boel.
Inderdaad zijn alle mysql functies aanwezig in alle scripts en dit zou mijn baas een zeer groot verlies oplevern..

Jullie moeten mij niet de les spellen i.v.m. PDO of MySQLI want ik ben de persoon die ervoor gezorgd heeft dat ons bedrijf vanaf 2013 PDO gaat gebruiken voor alle projecten sinds dien..

Zoals eerder vermeld hebben we nog steeds +300 websites die gebruik maken van mysql_, hier word ook beetje per beetje aan gewerkt!
Het is onmogelijk voor ons om al deze aanpasingen door te voeren in een zeer korte tijd, vandaar onze keuze om PHP5+ te gaan blijven gebruiken tot we kunnen overschakelen naar 7 maar dit is volgens ons pas mogelijk tegen 2020

M'n baas ziet zelf ook in dat dit niet allemaal in een korte tijd kan gebeuren aangezien we een flink verlies zouden maken.
Ik zeg niet dat we er geen aandacht aan besteden! Ik zeg enkel dat het een zeer grote stap is voor een groot bedrijf die niet zomaar even kan genomen worden, we moeten rekening houden met heel veel klanten en ons ook kunnen blijven focussen op openstaande projecten.

Toon Meer

Allereerst de lezen je niet de les, het is meer dat ze je advies geven over wat je wel en niet moet gebruiken, en daarnaast ook proberen je mening over dit onderwerp te veranderen.

Er zijn al genoeg redenen hier boven genoemd waarom je niet MySQL moet gebruiken, maar MySQLi of PDO. Daarnaast je kan inderdaad op een verouderde versie van PHP blijven zitten draaien, maar hou daarbij wel in het achterhoofd dat lekken, fouten etc er pas in volgende versies er uit gehaald worden. Wat dus ook alweer een risico punt is voor je klanten. Het is niet alleen zo dat MySQL verouderd is, niet updaten betekent ook dat je PHP verouderd raakt, en grote kans dus op bovengenoemde punten. Ook om die reden raad ik aan snel over te stappen naar nieuwere versies en technieken.

Hoi iedereen,

Volgens mij vereist deze topic enige opheldering en betere uitleg.

Allereerst aan de TS:
Zover ik zie hoef je $list->id of $id niet te beveiligen. Ik gok dat het een ledensysteem betreft mbt criminals. ID's zijn daar gegenereerd door de mysql database en wordt uit de DB gehaald. Dit betekent dat de gebruiker de ID variabele (in beginsel) niet kan beïnvloeden. Oftewel, er is geen beveiliging nodig. Wil je het écht controleren, valideer dan of de variabele ook daadwerkelijk numeriek is.

Over de mysql/deprecated discussie:
Er zijn slechts enkele redenen waarom je niet naar de nieuwe versie zou willen gaan. Óf er is op het moment geen geld voor de onderhoud of een nieuwe versie is in ontwikkeling of gaat geheid komen. Of net zoals bij de banken, de data of het systeem is zo kritiek dat men onder geen omstandigheid een fout kan veroorloven om ook maar een minimale fout te maken. Anders dan dat kan ik geen reden verzinnen.

In principe is het verhaal 'het kost veel' onzin. Niet de aanschaf maar de onderhoud van (de wat grotere) systemen zijn het duurst. Hoe meer je uitstelt, hoe duurder het onderhoud wordt. Hoe meer je uitstelt, hoe slechter de performance wordt (over het algemeen) t.o.v. nieuwe versies. Hoe meer je uitstelt, hoe minder bugfixes/security fixes je geniet. Kortom, het is altijd verstandig om naar een (stabiele bewezen) versie over te stappen.

Coderen in een oude standaard is het met het oog op dat hierboven altijd een slecht idee. Mysql is al deprecated.

Sterker nog, ik ben zojuist overgestapt naar PHP 7.0. Deze kan ongeveer 2x zoveel requests aan / 2x zo snel t.ov. PHP 5.6. In deze versie is de 'oude' mysql functie geheel verwijderd en ben je verplicht mysqli of PDO te gebruiken.