Forbedre sikkerheden i vores applikationer med PHP

PHP fremkom som et alsidigt sprog, der giver os mulighed for at manipulere de data, der indtastes via en formular HTMLSelvfølgelig er der inden for dens forfatning flere værktøjer og muligheder end bare dette.
Alsidigheden og brugervenligheden gør det til et af de mest udbredte sprog i hele verden til webprojekter, der spænder fra enkle kontaktformularer til at være grundlaget for store applikationer i starten som f.eks. Facebook.
Problemet med alsidighed og brugervenlighed er, at udvikleren ikke er tvunget til at skrive sikker kode, men med meget usikre funktioner vil koden køre perfekt, og det er her problemerne kommer.
Webapplikationssikkerhed er noget, du ikke har fra starten PHPDette gør det dog ikke til et usikkert sprog, da sikkerhed svarer til et sæt teknikker og arbejdsstile, som en programmør skal kende for at anvende dem på deres scripts.
RammerDet er rigtigt, at med udseendet af rammer Mange sikkerhedsfunktioner er inkluderet som standard, men ikke alle udviklere brugte a ramme i ældre applikationer, og det er muligt, at for nogle funktioner bruges a ramme være et overskud.
Nøglerne til at opnå sikkerhed i vores applikationer med PHP De er: Kontroller og finjuster de data, som brugeren indtaster formularen, verificer anmodningernes oprindelse HTTP som vores ansøgning modtager, og endelig undgå direkte udførelse af instruktioner gennem formularer.
Der er en regel i programmering, og den er universel, det vil sige, at den ikke kun gælder for PHPDet er, at alle de data, der ikke genereres af applikationen, potentielt er ondsindede, betyder det, at hvis det ikke er noget, der er et resultat, som vi har programmeret, kan vi ikke stole på.
Dette princip gælder for formværdier, filer, Databaser, så et første skridt til at forbedre vores sikkerhed er at filtrere data, hvis vi skal interagere med disse elementer.
Vi vil liste nogle af de bedste fremgangsmåder, som vi kan anvende, når vi filtrerer de data, der er indtastet i vores formular:
Brug lister over tilladte værdierMed denne praksis ved vi, at hvis de data, der kommer gennem formularen, ikke passerer vores liste over tilladte og sikre værdier, bør de ikke gå til behandling, på dette tidspunkt skal der sendes en besked til brugeren for at rette deres data.
Ret aldrig ugyldige dataDet lyder måske fristende at lave et meget intelligent system, der korrigerer data med uoverensstemmelser, men i det lange løb kan dette give os problemer og sårbarheder, derfor bør vi ikke behandle det, hvis vi opdager noget uregelmæssigt.
Brug navngivningskonventionMed denne praksis kan vi skelne de sikre data og værdier fra de data og værdier, der er indtastet af brugeren, med dette vil vi i programmeringen forstærke brugen af ​​førstnævnte til behandling.
Der er to typer filtrering at vi kan gøre, den første er af værdier, som vi kender og den anden af ​​værdier, som vi ikke kender.
Det først Det er meget let at gøre, vi skal kun udføre rutiner med lister over kendte elementer og sammenligne med det, men dette er besværligt og svært at udføre i større applikationer. Det anden Det indebærer oprettelse af rutiner, der evaluerer værdiens struktur, og hvis den svarer til den, vi anser for sikker, lader vi den gå til behandling, ellers kaster vi en fejl, da den er af dynamisk karakter, er dette det anbefalede format.
Lad os se nedenfor en eksempelkode på den første type filtrering:
I den følgende kode vil vi se, hvordan vi opretter en formular, der har et element Vælg For at brugeren kan vælge en farve, da brugeren ikke behøver at skrive dataene for at indtaste direkte, kan vi falde i fejlen med ikke at validere oplysningerne, men det betyder kun, at vi har et sikkerhedsgab siden med en formular, der gælder de samme navne kan vi modtage potentielt farlige oplysninger.
Det er derfor, når værdien af ​​formularen er sendt igennem STOLPE, evaluerer vores script de mulige værdier, og hvis det er en af ​​de forventede, videregiver vi det til vores vifte af sikre værdier, som vi ser nedenfor.

Med dette har vi løst problemet på en enkel måde, men hvis listen i stedet for at have tre farver havde haft hundrede, ville historien om enkelhed have været en anden.
I det følgende eksempel vil vi dynamisk validere et felt, der er indtastet af brugeren på en passende måde, til dette skal vi bruge regulære udtryk og på denne måde undgå indtastning af tegn, der sætter vores behandling i fare, også evaluere postens størrelse og dermed undgå en flyde over eller overbelastning af vores datatype i behandlingen af ​​programmet. Lad os se koden på billedet:

FORSTØRRE

Her er nøglen til at opnå validering at vide korrekt, hvad vi vil behandle, for eksempel i tilfælde af et brugernavn, hvad vi normalt beder om er alfanumeriske tegn og bindestreger, det er derfor i almindelig sætning Vi validerer dette, vi har også brug for, at det er større end 0 tegn og maksimalt 32, hvis det, der indtastes af brugeren, opfylder alt dette, passerer det valideringen, det bedste af alt er, at dette virker med en værdi som f.eks. hundrede, da det er totalt dynamisk.
En anden trussel, som vi skal beskytte os mod, er udførelsen af ​​scripts fra andre websteder, takket være AJAX Vi kan sende formularer fra klienten til en rute, herunder anmodningstype og de værdier, vi ønsker.
Blødt punktDenne form for svaghed gør det meget let for nogen at inspicere vores formular og kontrollere vores felter, hvor ved at eje disse navne og metoden HTTP Prøv at sende usikre værdier, for at undgå dette skal vi anvende teknikker, der giver os mulighed for at validere, hvor anmodningen kommer fra, og hvis det er sikkert at tillade dens udførelse, ellers undgå at fortsætte stien inden for vores program.
For at undgå dette problem, et system af tokens Y sessioner, så når formularen indsendes, vurderer vi, om sessionen er den samme som den, der er etableret på en sikker måde, og dermed kan den ondsindede bruger ikke fortsætte.
Et hovedmål for en angriber er at kunne indsætte sin kode i vores miljø, til dette bruger de kodeindsprøjtninger SQL, dette angreb er kendt som SQL -indsprøjtning, hvor vi med usikrede formularer og forkert behandling kan modtage instruktioner SQL direkte uden grænser. For eksempel hvis vores evaluering SQL er følgende i vores script PHP:

Vi kan bruge enhver bruger af systemet som et brugernavn og til adgangskode vi bruger to scripts “--” med dette kan vi passere sikkerhed uden problemer, da to scripts er en kommentar SQL og derfor vil adgangskoden ikke blive evalueret.
Den korrekte måde at vurdere en SQL der stammer fra brugeren, fjerner de særlige og farlige tegn, kun evaluerer sikre udtryk. Lad os se et eksempel nedenfor på, hvordan du undgår den tidligere sag:
Det første vi skal gøre er a sanering af data, det vil sige forhindre det i at komme rent fra formen til vores SQL; Den anden ting er, at vi skal evaluere, er at hvis de to værdier svarer til at give adgang, men sidstnævnte svarer til hver enkelt logik, lad os se på billedet, hvordan vi opnår målet:

FORSTØRRE

Her er det, vi har gjort, at bruge værktøjet udarbejdede udsagn hvad boghandlen tillader os BOB til forbindelse til Database, med dette opnår vi, at det indtastede aldrig tages i en anden kontekst, der ikke er data, ser vi også, at i stedet for at bruge metoden STOLPE Vi har brugt vores sikre array, det betyder, at vores data allerede er verificeret, så risikoen er lavere.
Med dette har vi afsluttet denne vejledning, da vi ser de handlinger, vi kan tage for at gøre vores applikation mere sikker, er enkle, de kræver ikke en menneskelig indsats, men de hjælper os med at undgå de mest almindelige angreb og måske de hyppigste. . er givet. Der er en dårlig opfattelse vedr PHP af dem, der siger, at det er et usikkert sprog, men virkeligheden er, at usikkerhed produceres af programmereren, da sproget kun har værktøjer, som vi kan bruge til at forbedre og forhindre angreb på vores applikationer gennem data, der er indtastet af brugeren.