C, PHP, VB, .NET

Вече разгледахме статии, в които описахме проблемите за вмъкване на нежелан SQL код и XSS атаки. Те всъщност са част от една по-широка общност, която можем да наречем общо „вмъкване на нежелан код“. SQL injection целеше да повреди базата данни, а XSS атаките целяха да подведат потребител на системата. Логично остава още едно звено за атака – файловата система на сървъра. Знаете, че скриптовете, писани на езици като PHP, ASP, JSP, и др, се компилират и изпълняват на сървъра. Това дали означава, че тяхния сорс код е предпазен от модифициране?

Нека разгледаме няколко примера: Прочети още…

.

На няколко пъти споменахме, че Environment Variables не трябва да бъдат използвани като достоверен източник на информация. Време е да добавим още нещо – използването им може да доведе и до пробиви в сигурността. Една статия от seancoates.com заслужава значително внимание.

Трябва да отбележим, че описаното в статията е изключително честа практика при програмирането на PHP, а именно – когато правите заявка от един скрипт към самия него, то програмистите използват за улеснение $_SERVER[‘PHP_SELF’]. Тази environment променлива записва текущия локален път към скрипта. Следните форми могат да бъдат видяни в изключително много PHP приложения: Прочети още…

.

„Forced Browsing“ или още „Forceful Browsing“ е атака, която цели достъпване на ресурси, които би трябвало да бъдат защитени. Почти винаги причина за такава атака е лош дизайн на правата на достъп за приложението. Принципът за защита е само един – ако например искаме да автентикираме един потребител и да проверим дали е администратор или не, то ние НЕ трябва да разчитаме на информация подадена от него. Винаги извършвайте проверките на страната на сървъра. Следното видео демонстрира с пример ефекта от лошо управление на правата на достъп: Прочети още…

.

Cross Site Request Forgery (XSRF) е уязвимост, с която караме човек да извърши действие в даден сайт без той да желае да извърши това действие. В браузърите действа т.нар. „same origin policy“, който гарантира, че в рамките на една сесия на браузъра скрипт от един домейн не може да прочете информация от друг домейн, но то не спира изпращането на информация (GET и POST заявки) от един домейн на друг. Именно това се използва като основа за XSRF атаката. Например XSRF може да се използва в комбинация с XSS, за да бъде накаран потребител с по-високи права да изпълни действие, което не е трябвало да бъде изпълнено, да бъде откраднато сесийно cookie, т.н. Прочети още…

.

Cross Site Scripting (XSS) е атака, която използва уязвимост на приложението и „вмъква“ нежелан код, който се изпълнява в браузъра на крайния потребител. Най-общо казано атаката цели да намери място в програмата, в което се отпечатва стойността на дадена променлива и не се проверява коректно нейното съдържание. Обикновено в съдържанието на променливата се записва HTML, XHTML, JavaScript, ActiveX, VBScript, Flash, и др видове изпълним код, но най-разпространения вариант е Javascript. Възможностите за цел на атаката може да са много – придобиване на достъп до защитена зона на сайта (чрез постигане на session hijacking), подвеждане на потребителя да въведе информация към трети източник (physhing), инсталиране на нежелани програми на компютъра на потребителя (virus, worm, trojan, …), и др. Според изследване на Symantec около 80% от проблемите в сигурността на уеб-базираните приложения са свързани именно с XSS уязвимости. Също така се прави статистическо предположение, че поне 70% от динамичните уеб-сайтове в световната мрежа притежават такава уязвимост. Обикновено крайния потребител не може да намери визуален белег, по който да разкрие атаката. Прочети още…

.

Досега силно препоръчвахме употребата на SSL, но не дадохме конкретна информация как точно ще бъде защитена нашата комуникация с него. SSL e съкращение на „Secure Socket Layer“ и се използва изключително широко при криптиране на мрежови трафик. Най-често се използва при world wide web за криптиране на HTTP, но вече много често може да бъде видян и при други протоколи, като FTP, SMTP, NNTP, POP3, IMAP и т.н. Прочети още…

.

Това е както един от трудните за реализиране проблеми, така и един от най-трудните за предотвратяване. Има няколко основни правила, които трябва да имаме предвид:

1. Не вярвайте на готовите библиотеки. Ето ви един непълен списък на вградени функции от С, които са доказано уязвими:
strcpy(), strcat(), printf(), sprintf(), vsprintf(), gets(), scanf(), fscanf(), sscanf(), vscanf(), vsscanf(), vfscanf(), realpath(), getopt(), getpass(), streadd(), strecpy(), strtrns() и др.
Ето ви и един eлементарен пример:

	char buf[10];
	gets(buf);

Въведете повече от 10 символа и ще видите неприятен резултат. Прочети още…

.

Дотук разгледахме най-често срещаният проблем, позволяващ вмъкване на нежелан SQL код – лошо филтриране на входните данни. Отбелязахме, че е по-добре да даваме множество от позволени стойности на входните данни, а не просто да забраняваме непозволените символи. За да обясним защо ще демонстрираме чрез пример, в който няма да използваме кавички при изпълнение на заявката. Нека например изпращаме следната заявка:

	$sql = "SELECT * FROM stats WHERE id=$id"

В случая полето с име „id“ е от тип int и поради тази причина не е нужно ограждането на стойността в кавички. Ако подадем например числото „5“ ще се генерира следната заявка към базата от данни: Прочети още…

.

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

.

Прочети още…

.