Verbeter de beveiliging van onze applicaties met PHP

PHP kwam naar voren als een veelzijdige taal waarmee we de gegevens die via een formulier zijn ingevoerd, kunnen manipuleren HTMLNatuurlijk zijn er binnen de grondwet meer tools en mogelijkheden dan alleen dit.
De veelzijdigheid en het gebruiksgemak maken het een van de meest gebruikte talen ter wereld voor webprojecten die variëren van eenvoudige contactformulieren tot de basis van grote applicaties in het begin zoals Facebook.
Het probleem met veelzijdigheid en gebruiksgemak is dat de ontwikkelaar niet gedwongen wordt om veilige code te schrijven, maar met zeer onveilige functies zal de code perfect werken, en dat is waar de problemen komen.
Beveiliging van webtoepassingen is iets dat u niet vanaf het begin hebt PHPDit maakt het echter geen onveilige taal, aangezien beveiliging overeenkomt met een reeks technieken en werkstijlen die een programmeur moet kennen om ze op zijn scripts toe te passen.
KadersHet is waar dat met het verschijnen van kaders Veel beveiligingsfuncties zijn standaard inbegrepen, maar niet elke ontwikkelaar gebruikte een kader in oudere toepassingen en het is mogelijk dat voor sommige functies a kader een overmaat zijn.
De sleutels om veiligheid in onze applicaties te bereiken met: PHP Dit zijn: controleer en verfijn de gegevens die de gebruiker op het formulier invoert, verifieer de oorsprong van de verzoeken HTTP die onze applicatie ontvangt, en vermijd ten slotte de directe uitvoering van instructies via formulieren.
Er is een regel in programmeren en deze is universeel, dat wil zeggen dat deze niet alleen van toepassing is op: PHPHet is dat alle gegevens die niet door de applicatie worden gegenereerd potentieel kwaadaardig zijn, dit betekent dat als het niet iets is dat een resultaat is dat we hebben geprogrammeerd, we niet kunnen vertrouwen.
Dit principe is van toepassing op formulierwaarden, bestanden, Databases, dus een eerste stap om onze beveiliging te verbeteren, is het filteren van gegevens als we met deze elementen moeten communiceren.
We gaan enkele van de best practices opsommen die we kunnen toepassen wanneer we de gegevens filteren die in ons formulier worden ingevoerd:
Lijsten met toegestane waarden gebruikenMet deze praktijk weten we dat als de gegevens die via het formulier binnenkomen niet door onze lijst met toegestane en veilige waarden gaan, deze niet moeten worden verwerkt, op dit punt moet een bericht naar de gebruiker worden gestuurd om hun gegevens te corrigeren.
Corrigeer nooit ongeldige gegevensHet klinkt misschien verleidelijk om een ​​zeer intelligent systeem te maken dat gegevens corrigeert met inconsistenties, maar op de lange termijn kan dit ons problemen en kwetsbaarheden opleveren, daarom moeten we het niet verwerken als we iets onregelmatigs detecteren.
Gebruik naamgevingsconventieMet deze praktijk kunnen we de veilige gegevens en waarden onderscheiden van die gegevens en waarden die door de gebruiker zijn ingevoerd, hiermee zullen we binnen de programmering het gebruik van de eerste voor verwerking versterken.
Er is twee soorten filtering dat we kunnen doen, de eerste is van waarden die we kennen en de tweede van waarden die we niet kennen.
De eerst Het is heel gemakkelijk om te doen, we hoeven alleen routines uit te voeren met lijsten met bekende elementen en deze te vergelijken, maar dit is omslachtig en moeilijk uit te voeren in grotere toepassingen. De tweede Het impliceert het creëren van routines die de structuur van de waarde evalueren en als deze overeenkomt met degene die we als veilig beschouwen, laten we deze naar verwerking gaan, anders gooien we een fout, omdat deze van dynamische aard is, is dit het aanbevolen formaat.
Laten we hieronder een voorbeeldcode van het eerste type filtering bekijken:
In de volgende code zullen we zien hoe we een formulier maken met een element selecteer Voor de gebruiker om een ​​kleur te selecteren, omdat de gebruiker de gegevens niet hoeft te schrijven om rechtstreeks in te voeren, kunnen we de fout begaan om de informatie niet te valideren, maar dit betekent alleen dat we een beveiligingslek hebben omdat met een formulier dat van toepassing is dezelfde namen kunnen we potentieel gevaarlijke informatie ontvangen.
Dat is de reden waarom zodra de waarde van het formulier is doorgestuurd NA, ons script evalueert de mogelijke waarden, en in het geval dat het een van de verwachte waarden is, geven we het door aan onze reeks veilige waarden, zoals we hieronder zien.

Hiermee hebben we het probleem op een eenvoudige manier opgelost, maar als de lijst in plaats van drie kleuren honderd had gehad, zou het verhaal van eenvoud anders zijn geweest.
In het volgende voorbeeld zullen we een veld dat door de gebruiker is ingevoerd op een geschikte manier dynamisch valideren, hiervoor moeten we gebruiken normale uitdrukkingen en vermijd op deze manier de invoer van tekens die onze verwerking in gevaar brengen, evalueer ook de grootte van de invoer en vermijd zo a overloop of overbelasting van ons gegevenstype bij de verwerking van het programma. Laten we de code in de afbeelding bekijken:

VERGROTEN

Hier is de sleutel tot validatie om correct te weten wat we willen verwerken, bijvoorbeeld in het geval van een gebruikersnaam, waar we normaal om vragen alfanumerieke tekens en koppeltekens, daarom in de gewone zin We valideren dit, we hebben ook nodig dat het groter is dan 0 tekens en maximaal 32, als wat door de gebruiker is ingevoerd aan dit alles voldoet, passeert het de validatie, het beste van alles is dat dit werkt met een waarde zoals honderd, omdat het volledig dynamisch is.
Een andere bedreiging waartegen we ons moeten beschermen, is het uitvoeren van scripts van andere sites, dankzij AJAX We kunnen formulieren van de klant naar een route sturen, inclusief het type verzoek en de waarden die we willen.
Zachte plekDit soort zwakte maakt het voor iemand heel gemakkelijk om ons formulier te inspecteren en onze velden te controleren, waar door deze namen en de methode te bezitten HTTP Probeer onveilige waarden te verzenden, om dit te voorkomen, moeten we technieken toepassen waarmee we kunnen valideren waar het verzoek vandaan komt en of het veilig is om de uitvoering ervan toe te staan, anders moet u het pad binnen ons programma niet voortzetten.
Om dit probleem te voorkomen, is een systeem van Munten Y sessies, zodat wanneer het formulier wordt ingediend, we evalueren of de sessie dezelfde is als de sessie die op een veilige manier tot stand is gebracht, en dat de kwaadwillende gebruiker dus niet verder kan.
Een belangrijk doel van een aanvaller is om zijn code in onze omgeving te kunnen invoegen, hiervoor gebruiken ze code-injecties SQL, deze aanval staat bekend als SQL injectie, waar we met onbeveiligde formulieren en onjuiste verwerking instructies kunnen ontvangen SQL direct zonder grenzen. Bijvoorbeeld als onze evaluatie SQL is het volgende in ons script PHP:

We kunnen elke gebruiker van het systeem gebruiken als gebruikersnaam en voor de wachtwoord we gebruiken twee scripts “--” hiermee kunnen we zonder problemen de beveiliging passeren, aangezien twee scripts een opmerking zijn SQL en daarom wordt het wachtwoord niet geëvalueerd.
De juiste manier om een SQL evalueren die afkomstig is van de gebruiker, verwijdert de speciale en gevaarlijke tekens en evalueert alleen veilige uitdrukkingen. Laten we hieronder een voorbeeld bekijken om het vorige geval te vermijden:
Het eerste wat we moeten doen is een gegevensopschoning, dat wil zeggen, voorkomen dat het puur van de vorm naar onze SQL; Het tweede dat we moeten evalueren, is dat als de twee waarden overeenkomen om toegang te geven, maar de laatste overeenkomt met de logica van elk, laten we in de afbeelding zien hoe we het doel bereiken:

VERGROTEN

Hier hebben we de tool gebruikt: voorbereide verklaringen wat de boekhandel ons toestaat BOB voor verbinding met Database, hiermee bereiken we dat wat wordt ingevoerd nooit in een andere context wordt genomen die geen data is, zien we ook dat in plaats van de methode te gebruiken NA We hebben onze beveiligde array gebruikt, dit betekent dat onze gegevens al zijn geverifieerd, dus het risico is lager.
Hiermee hebben we deze tutorial voltooid, omdat we zien dat de acties die we kunnen ondernemen om onze applicatie veiliger te maken eenvoudig zijn, ze vereisen geen menselijke inspanning, maar ze helpen ons om de meest voorkomende en misschien wel de meest voorkomende aanvallen te vermijden worden gegeven. Er is een slechte perceptie over PHP van degenen die zeggen dat het een onveilige taal is, maar de realiteit is dat onveiligheid wordt geproduceerd door de programmeur, aangezien de taal alleen tools heeft die we kunnen gebruiken om aanvallen op onze applicaties te verbeteren en te voorkomen door middel van gegevens die door de gebruiker zijn ingevoerd.