Forbedre sikkerheten til applikasjonene våre med PHP

PHP fremsto som et allsidig språk som lar oss manipulere dataene som er lagt inn via et skjema HTMLSelvfølgelig er det innenfor dens grunnlov flere verktøy og evner enn bare dette.
Allsidigheten og brukervennligheten gjør det til et av de mest brukte språkene over hele verden for webprosjekter som spenner fra enkle kontaktskjemaer, til å være grunnlaget for store applikasjoner i begynnelsen som f.eks. Facebook.
Problemet med allsidighet og brukervennlighet er at utvikleren ikke er tvunget til å skrive sikker kode, men med svært usikre funksjoner vil koden fungere perfekt, og det er der problemene kommer.
Nettapplikasjonssikkerhet er noe du ikke har fra starten av PHPDette gjør det imidlertid ikke til et usikkert språk, siden sikkerhet tilsvarer et sett med teknikker og arbeidsstiler som en programmerer må kjenne for å bruke dem på skriptene sine.
RammerDet er sant at med utseendet på rammer Mange sikkerhetsfunksjoner er inkludert som standard, men ikke alle utviklere brukte a rammeverk i eldre applikasjoner, og det er mulig at for noen funksjoner bruker a rammeverk være et overskudd.
Nøklene for å oppnå sikkerhet i våre applikasjoner med PHP De er: kontroller og avgrens dataene som brukeren legger inn i skjemaet, bekreft opprinnelsen til forespørslene HTTP som vår søknad mottar, og til slutt unngå direkte utførelse av instruksjoner gjennom skjemaer.
Det er en regel i programmering og den er universell, det vil si at den ikke bare gjelder for PHPDet er at alle dataene som ikke genereres av programmet er potensielt ondsinnede, betyr dette at hvis det ikke er noe som er et resultat som vi har programmert, kan vi ikke stole på.
Dette prinsippet gjelder skjemaverdier, filer, Databaser, så et første skritt for å forbedre vår sikkerhet er å filtrere data hvis vi må samhandle med disse elementene.
Vi kommer til å liste noen av de beste fremgangsmåtene vi kan anvende når vi filtrerer dataene som er lagt inn i skjemaet vårt:
Bruk lister over tillatte verdierMed denne praksisen vet vi at hvis dataene som kommer gjennom skjemaet ikke passerer vår liste over tillatte og sikre verdier, bør de ikke gå til behandling, på dette tidspunktet må det sendes en melding til brukeren for å korrigere dataene sine.
Rett aldri ugyldige dataDet kan høres fristende ut å lage et veldig intelligent system som korrigerer data med inkonsekvenser, men på sikt kan dette gi oss problemer og sårbarheter, derfor bør vi ikke behandle det hvis vi oppdager noe uregelmessig.
Bruk navnekonvensjonMed denne praksisen kan vi skille de sikre dataene og verdiene fra de dataene og verdiene som er angitt av brukeren, med dette vil vi i programmeringen forsterke bruken av førstnevnte for behandling.
Det er to typer filtrering at vi kan gjøre, den første er av verdier som vi kjenner og den andre av verdier som vi ikke kjenner.
De først Det er veldig enkelt å gjøre, vi trenger bare å utføre rutiner med lister over kjente elementer og sammenligne med det, men dette er tungvint og vanskelig å utføre i større applikasjoner. De sekund Det innebærer å opprette rutiner som evaluerer strukturen av verdien, og hvis den tilsvarer den vi anser som trygg, lar vi den gå til behandling, ellers kaster vi en feil, da den er av dynamisk art, er dette det anbefalte formatet.
La oss se nedenfor en eksempelkode på den første filtreringstypen:
I den følgende koden vil vi se hvordan vi lager et skjema som har et element å velge For at brukeren skal velge en farge, ettersom brukeren ikke trenger å skrive dataene for å angi direkte, kan vi falle inn i feilen med å ikke validere informasjonen, men dette betyr bare at vi har et sikkerhetsgap siden med et skjema som gjelder de samme navnene kan vi motta potensielt farlig informasjon.
Det er derfor når verdien av skjemaet er sendt gjennom POST, evaluerer skriptet våre mulige verdier, og hvis det er noen av de forventede, sender vi det videre til vårt utvalg av sikre verdier som vi ser nedenfor.

Med dette har vi løst problemet på en enkel måte, men hvis listen i stedet for å ha tre farger hadde hatt hundre, hadde historien om enkelhet vært annerledes.
I det følgende eksemplet vil vi dynamisk validere et felt som er angitt av brukeren på en passende måte, for dette må vi bruke vanlig uttrykk og på denne måten unngå å skrive inn tegn som setter vår behandling i fare, også vurdere størrelsen på oppføringen og dermed unngå a flyte eller overbelastning av datatypen vår i behandlingen av programmet. La oss se koden i bildet:

FORSTØRRE

Her er nøkkelen for å oppnå validering å vite riktig hva vi vil behandle, for eksempel når det gjelder et brukernavn, det vi vanligvis ber om er alfanumeriske tegn og bindestreker, det er derfor i vanlig setning Vi validerer dette, vi trenger også at det skal være større enn 0 tegn og maksimalt 32, hvis det som er angitt av brukeren oppfyller alt dette, passerer det validering, det beste av alt er at dette fungerer med en verdi som f.eks. hundre, siden det er totalt dynamisk.
En annen trussel vi må beskytte oss mot er utførelsen av skript fra andre nettsteder, takket være AJAX Vi kan sende skjemaer fra klienten til en rute, inkludert forespørselstypen og verdiene vi ønsker.
Mykt punktDenne typen svakhet gjør det veldig enkelt for noen å inspisere skjemaet vårt og sjekke feltene våre, ved å eie disse navnene og metoden HTTP Prøv å sende usikre verdier, for å unngå dette må vi bruke teknikker som lar oss validere hvor forespørselen kommer fra, og hvis det er trygt å tillate utførelsen, ellers unngå å fortsette banen i programmet vårt.
For å unngå dette problemet, et system av tokens Y økter, slik at når skjemaet sendes inn, vurderer vi om økten er den samme som den som er etablert på en sikker måte, og dermed kan den ondsinnede brukeren ikke fortsette.
Et sentralt mål for en angriper er å kunne sette inn koden hans i miljøet vårt, for dette bruker de kodeinjeksjoner SQL, dette angrepet er kjent som SQL -injeksjon, hvor vi med usikrede skjemaer og feil behandling kan motta instruksjoner SQL direkte uten grenser. For eksempel hvis vår vurdering SQL er følgende i skriptet vårt PHP:

Vi kan bruke hvilken som helst bruker av systemet som brukernavn og for passord vi bruker to skript “--” med dette kan vi passere sikkerhet uten problemer, siden to skript er en kommentar SQL og derfor vil ikke passordet bli evaluert.
Den riktige måten å vurdere en SQL som stammer fra brukeren, fjerner de spesielle og farlige tegnene, bare evaluerer trygge uttrykk. La oss se et eksempel nedenfor på hvordan du kan unngå den forrige saken:
Det første vi må gjøre er a sanering av data, det vil si forhindre at den kommer ren fra formen til vår SQL; Den andre tingen er at vi må evaluere er at hvis de to verdiene tilsvarer å gi tilgang, men sistnevnte tilsvarer logikken til hver enkelt, la oss se på bildet hvordan vi oppnår målet:

FORSTØRRE

Her er det vi har gjort å bruke verktøyet utarbeidede uttalelser hva bokhandelen tillater oss BOB for tilkobling til Database, med dette oppnår vi at det som legges inn aldri blir tatt i en annen kontekst som ikke er data, ser vi også at i stedet for å bruke metoden POST Vi har brukt vår sikre matrise, dette betyr at dataene våre allerede er bekreftet, så risikoen er lavere.
Med dette har vi fullført denne opplæringen, ettersom vi ser at handlingene vi kan gjøre for å gjøre applikasjonen vår sikrere er enkle, krever de ikke en menneskelig innsats, men de hjelper oss med å unngå de vanligste angrepene og kanskje de hyppigste. . er gitt. Det er en dårlig oppfatning om PHP av dem som sier at det er et usikkert språk, men virkeligheten er at usikkerhet produseres av programmereren, siden språket bare har verktøy som vi kan bruke for å forbedre og forhindre angrep på applikasjonene våre gjennom data som er lagt inn av brukeren.