Подобрете сигурността на нашите приложения с PHP

PHP се появи като универсален език, който ни позволява да манипулираме данните, въведени чрез формуляр HTMLРазбира се в рамките на нейната конституция има повече инструменти и възможности от това.
Универсалността и лекотата на използване го правят един от най -широко използваните езици в световен мащаб за уеб проекти, които варират от прости форми за контакт до основата на големи приложения в началото, като например Facebook.
Проблемът с гъвкавостта и лекотата на използване е, че разработчикът не е принуден да пише защитен код, но с много несигурни функции кодът ще работи перфектно и оттам идват проблемите.
Защитата на уеб приложенията е нещо, което нямате от самото начало PHPТова обаче не го прави несигурен език, тъй като защитата съответства на набор от техники и стилове на работа, които програмистът трябва да знае, за да ги приложи към своите скриптове.
РамкиВярно е, че с появата на рамки Много функции за сигурност са включени по подразбиране, но не всеки разработчик използва a рамка в по -стари приложения и е възможно за някои функции да се използва a рамка бъде излишък.
Ключовете за постигане на сигурност в нашите приложения с PHP Те са: контролират и прецизират данните, които потребителят въвежда във формуляра, проверяват произхода на заявките HTTP което нашето приложение получава и накрая избягвайте директното изпълнение на инструкции чрез формуляри.
В програмирането има правило и то е универсално, тоест не се отнася само за PHPТова е, че всички данни, които не се генерират от приложението, са потенциално злонамерени, това означава, че ако не е нещо, което е резултат, който сме програмирали, не можем да се доверим.
Този принцип се прилага за стойностите на формите, файловете, Бази данни, така че първата стъпка за подобряване на сигурността ни е да филтрираме данните, ако трябва да взаимодействаме с тези елементи.
Ще изброим някои от най -добрите практики, които можем да приложим, когато филтрираме данните, въведени във формуляра ни:
Използвайте списъци с разрешени стойностиС тази практика знаем, че ако данните, които идват през формуляра, не преминават през нашия списък с разрешени и безопасни стойности, те не трябва да отиват за обработка, в този момент трябва да се изпрати съобщение до потребителя, за да коригира данните си.
Никога не коригирайте невалидни данниМоже да звучи изкушаващо да се направи много интелигентна система, която коригира данните с несъответствия, но в дългосрочен план това може да ни донесе проблеми и уязвимости, затова, ако открием нещо нередно, не трябва да го обработваме.
Използвайте конвенция за именуванеС тази практика можем да разграничим безопасните данни и стойности от тези данни и стойности, въведени от потребителя, с това ще засилим в рамките на програмирането използването на първия за обработка.
Има два типа филтриране което можем да направим, първото е от ценности, които познаваме, а второто от ценностите, които не познаваме.
The първо Това е много лесно да се направи, трябва само да изпълняваме рутинни процедури със списъци с известни елементи и да сравняваме с него, но това е тромаво и трудно за изпълнение в по -големи приложения. The второ Това предполага създаване на процедури, които оценяват структурата на стойността и ако тя съответства на тази, която считаме за безопасна, я оставяме на обработка, в противен случай изхвърляме грешка, тъй като е с динамичен характер, това е препоръчителният формат.
Нека видим по -долу примерен код на първия тип филтриране:
В следния код ще видим как създаваме формуляр, който има елемент изберете За да може потребителят да избере цвят, тъй като потребителят не трябва да пише данните, за да въведе директно, можем да изпаднем в грешката да не потвърдим информацията, но това означава само, че имаме пропуск в сигурността, тъй като с формуляр, който се прилага същите имена можем да получим потенциално опасна информация.
Ето защо, след като стойността на формуляра бъде изпратена POST, нашият скрипт оценява възможните стойности и в случай на някоя от очакваните ги предаваме на нашия масив от безопасни стойности, както виждаме по -долу.

С това ние решихме проблема по прост начин, но ако списъкът, вместо да има три цвята, имаше сто, историята на простотата щеше да бъде различна.
В следния пример ще проверим динамично поле, въведено от потребителя по подходящ начин, за това трябва да използваме регулярни изрази и по този начин да се избегне въвеждането на знаци, които излагат обработката ни на риск, също така да се оцени размерът на записа и по този начин да се избегне a препълване или претоварване на нашия тип данни при обработката на програмата. Нека видим кода на изображението:

Увеличете

Тук ключът за постигане на валидиране е да знаем правилно какво искаме да обработим, например в случай на потребителско име, това, което обикновено искаме, са буквено -цифрови знаци и тирета, затова в обикновена фраза Ние потвърждаваме това, ние също се нуждаем от повече от 0 знака и максимум 32, ако въведеното от потребителя отговаря на всичко това, то преминава валидирането, най -доброто от всичко е, че това работи със стойност като сто, тъй като е напълно динамичен.
Друга заплаха, срещу която трябва да се защитим, е изпълнението на скриптове от други сайтове, благодарение на AJAX Можем да изпращаме формуляри от клиента до маршрут, включително вида на заявката и стойностите, които искаме.
Меко мястоТози вид слабост прави много лесно някой да провери нашата форма и да провери нашите полета, където, като притежава тези имена и метода HTTP Опитайте се да изпратите несигурни стойности, за да избегнем това, трябва да приложим техники, които ни позволяват да потвърдим откъде идва заявката и ако е безопасно да разрешим нейното изпълнение, в противен случай избягвайте продължаването на пътя в нашата програма.
За да се избегне този проблем, система от жетони Y сесии, така че при подаване на формуляра да оценим дали сесията е същата като тази, установена по защитен начин, и по този начин злонамереният потребител не може да продължи.
Ключова цел на нападателя е да може да вмъкне кода си в нашата среда, за това те използват инжекции с код SQL, тази атака е известна като SQL инжектиране, където с необезпечени формуляри и неправилна обработка, може да получим инструкции SQL директно без ограничения. Например, ако нашата оценка SQL е следното в нашия скрипт PHP:

Можем да използваме всеки потребител на системата като потребителско име и за парола използваме два скрипта “--” с това можем да преминем сигурността без проблеми, тъй като два скрипта са коментар SQL и следователно паролата няма да бъде оценена.
Правилният начин да оцени SQL който произхожда от потребителя, премахва специалните и опасни знаци, като оценява само безопасни изрази. Нека видим пример по -долу как да избегнем предишния случай:
Първото нещо, което трябва да направим, е a дезинфекция на данни, тоест да му попречи да пристигне чист от формата до нашия SQL; Второто нещо, което трябва да оценим е, че ако двете стойности съответстват на даването на достъп, но последното съответства на логиката на всяка една, нека видим в изображението как постигаме целта:

Увеличете

Тук това, което направихме, е да използваме инструмента подготвени изявления какво ни позволява книжарницата ЗНП за връзка с База данни, с това постигаме, че въведеното никога не се приема в друг контекст, който не е данни, също виждаме, че вместо да използваме метода POST Използвали сме нашия защитен масив, това означава, че данните ни вече са проверени, така че рискът е по -малък.
С това завършихме този урок, тъй като виждаме, че действията, които можем да предприемем, за да направим нашето приложение по -сигурно, са прости, не изискват човешки усилия, но ни помагат да избегнем най -често срещаните атаки и може би най -честите … са дадени. Има лошо възприятие за PHP от тези, които казват, че това е несигурен език, но реалността е, че несигурността се произвежда от програмиста, тъй като езикът има само инструменти, които можем да използваме за подобряване и предотвратяване на атаки срещу нашите приложения чрез въведени от потребителя данни.