Förbättra säkerheten för våra applikationer med PHP

PHP framkom som ett mångsidigt språk som gör att vi kan manipulera data som matas in via ett formulär HTMLNaturligtvis finns det inom dess konstitution fler verktyg och möjligheter än bara detta.
Mångsidigheten och användarvänligheten gör det till ett av de mest använda språken världen över för webbprojekt som sträcker sig från enkla kontaktformulär till att vara grunden för stora applikationer i början som t.ex. Facebook.
Problemet med mångsidighet och användarvänlighet är att utvecklaren inte tvingas skriva säker kod, men med mycket osäkra funktioner kommer koden att fungera perfekt, och det är där problemen kommer.
Webbapplikationssäkerhet är något som du inte har från början PHPDetta gör det dock inte till ett osäkert språk, eftersom säkerhet motsvarar en uppsättning tekniker och arbetsstilar som en programmerare måste känna för att kunna tillämpa dem på sina skript.
RamverkDet är sant att med utseendet på ramar Många säkerhetsfunktioner ingår som standard, men inte alla utvecklare använde a ramverk i äldre applikationer och det är möjligt att för vissa funktioner används a ramverk vara ett överskott.
Nycklarna för att uppnå säkerhet i våra applikationer med PHP De är: kontrollera och förfina data som användaren anger i formuläret, verifiera ursprunget till förfrågningarna HTTP som vår ansökan tar emot och slutligen undvika direkt körning av instruktioner genom formulär.
Det finns en regel i programmering och den är universell, det vill säga att den inte bara gäller för PHPDet är att all data som inte genereras av programmet är potentiellt skadlig, det betyder att om det inte är något som är ett resultat som vi har programmerat kan vi inte lita på.
Denna princip gäller formulärvärden, filer, Databaser, så ett första steg för att förbättra vår säkerhet är att filtrera data om vi måste interagera med dessa element.
Vi kommer att lista några av de bästa metoder som vi kan tillämpa när vi filtrerar data som matas in i vårt formulär:
Använd listor över tillåtna värdenMed denna praxis vet vi att om data som kommer via formuläret inte passerar igenom vår lista över tillåtna och säkra värden, bör den inte gå till bearbetning, vid denna tidpunkt måste ett meddelande skickas till användaren för att korrigera deras data.
Korrigera aldrig ogiltiga uppgif.webpterDet kan låta frestande att göra ett mycket intelligent system som korrigerar data med inkonsekvenser, men i det långa loppet kan detta ge oss problem och sårbarheter, det är därför om vi upptäcker något oregelbundet bör vi inte behandla det.
Använd namngivningskonventionMed denna praxis kan vi skilja säkra data och värden från de data och värden som användaren har angett, med detta kommer vi att förstärka användningen av den förstnämnda för bearbetning inom programmeringen.
Det finns två typer av filtrering som vi kan göra, det första är av värden som vi känner och det andra av värden som vi inte känner till.
De först Det är väldigt enkelt att göra, vi behöver bara utföra rutiner med listor över kända element och jämföra med det, men detta är krångligt och svårt att utföra i större applikationer. De andra Det innebär att skapa rutiner som utvärderar strukturen av värdet och om det motsvarar det vi anser vara säkert, låter vi det gå till bearbetning, annars kastar vi ett fel, eftersom det är av dynamisk karaktär är detta det rekommenderade formatet.
Låt oss se nedan en exempelkod för den första typen av filtrering:
I följande kod kommer vi att se hur vi skapar ett formulär som har ett element Välj För att användaren ska välja en färg, eftersom användaren inte behöver skriva data för att mata in direkt, kan vi hamna i felet att inte validera informationen, men det betyder bara att vi har ett säkerhetsgap eftersom med ett formulär som gäller samma namn kan vi få potentiellt farlig information.
Det är därför som värdet på formuläret skickas igenom POSTA, vårt manus utvärderar de möjliga värdena, och om det är någon av de förväntade överför vi det till vårt utbud av säkra värden som vi ser nedan.

Med detta har vi löst problemet på ett enkelt sätt, men om listan istället för att ha tre färger hade hundra hade historien om enkelhet varit annorlunda.
I följande exempel kommer vi dynamiskt att validera ett fält som användaren har angett på ett lämpligt sätt, för detta måste vi använda vanliga uttryck och på så sätt undvika inmatning av tecken som utsätter vår behandling för fara, utvärdera också postens storlek och undvik därmed a svämma över eller överbelastning av vår datatyp vid behandling av programmet. Låt oss se koden i bilden:

FÖRSTORA

Här är nyckeln för att uppnå validering att veta korrekt vad vi vill bearbeta, till exempel när det gäller ett användarnamn, det vi normalt begär är alfanumeriska tecken och bindestreck, det är därför i vanlig fras Vi validerar detta, vi behöver också att det ska vara större än 0 tecken och högst 32, om det som skrivs in av användaren uppfyller allt detta, passerar det valideringen, det bästa av allt är att detta fungerar med ett värde som t.ex. hundra, eftersom det är helt dynamiskt.
Ett annat hot som vi måste skydda oss mot är körningen av skript från andra webbplatser, tack vare AJAX Vi kan skicka formulär från klienten till en rutt, inklusive typen av förfrågan och de värden vi vill ha.
Öm punktDenna typ av svaghet gör det väldigt lätt för någon att inspektera vårt formulär och kontrollera våra fält, var genom att äga dessa namn och metoden HTTP Försök att skicka osäkra värden, för att undvika detta måste vi tillämpa tekniker som gör att vi kan validera varifrån begäran kommer och om det är säkert att tillåta dess genomförande, annars undvik att fortsätta vägen inom vårt program.
För att undvika detta problem, ett system av tokens Y sessioner, så att när formuläret skickas utvärderar vi om sessionen är densamma som den som etablerats på ett säkert sätt, och därmed kan den skadliga användaren inte fortsätta.
Ett huvudmål för en angripare är att kunna infoga sin kod i vår miljö, för detta använder de kodinjektioner SQL, denna attack är känd som SQL -injektion, där vi med osäkra formulär och felaktig behandling kan få instruktioner SQL direkt utan gränser. Till exempel om vår utvärdering SQL är följande i vårt manus PHP:

Vi kan använda alla användare av systemet som ett användarnamn och för Lösenord vi använder två skript “--” med detta kan vi passera säkerhet utan problem, eftersom två skript är en kommentar SQL och därför kommer lösenordet inte att utvärderas.
Rätt sätt att utvärdera en SQL som härstammar från användaren, tar bort special- och farliga tecken, bara utvärderar säkra uttryck. Låt oss se ett exempel nedan på hur du undviker föregående fall:
Det första vi måste göra är a sanering av data, det vill säga förhindra att det kommer rent från formen till vårt SQL; Den andra saken är att vi måste utvärdera är att om de två värdena motsvarar att ge åtkomst, men det senare motsvarar logiken för var och en, låt oss se i bilden hur vi uppnår målet:

FÖRSTORA

Här är vad vi har gjort är att använda verktyget förberedda uttalanden vad bokhandeln tillåter oss PDO för anslutning till Databas, med detta uppnår vi att det som matas in aldrig tas i ett annat sammanhang som inte är data, vi ser också att istället för att använda metoden POSTA Vi har använt vår säkra array, det betyder att vår data redan är verifierad, så risken är lägre.
Med detta har vi avslutat den här självstudien, eftersom vi ser de åtgärder som vi kan vidta för att göra vår applikation säkrare är enkla, de kräver ingen mänsklig ansträngning, men de hjälper oss att undvika de vanligaste attackerna och kanske de vanligaste. . ges. Det finns en dålig uppfattning om PHP av dem som säger att det är ett osäkert språk, men verkligheten är att otrygghet produceras av programmeraren, eftersom språket bara har verktyg som vi kan använda för att förbättra och förhindra attacker mot våra applikationer genom data som skrivs in av användaren.