За твърде много компании не е чак след е настъпило нарушение на сигурността че най-добрите практики за уеб сигурност стават приоритет. През годините си на работа като професионалист по ИТ сигурност, виждах от време на време колко неясен може да бъде светът на проблемите със сигурността на уеб разработката за толкова много от моите колеги програмисти .

Ефективният подход към заплахите за уеб сигурност по дефиниция трябва да бъде проактивен и защитен. За тази цел тази публикация има за цел да предизвика инерция на мисленето, надявайки се да инжектира читателя със здравословна доза параноя.

По-конкретно, това ръководство се фокусира върху 10 общи и важни подводни камъка, които трябва да знаете, включително препоръки за това как те могат да бъдат смекчени. Фокусът е върху Топ 10 уеб уязвимости идентифицирани от Проект за отворена защита на уеб приложения (OWASP) , международна организация с нестопанска цел, чиято цел е да подобри сигурността на софтуера по целия свят.

Малко буква за киберсигурност преди да започнем - удостоверяване и упълномощаване

Когато разговарям с други програмисти и ИТ специалисти, често срещам объркване по отношение на разграничението между упълномощаване и удостоверяване. И разбира се, фактът съкращението авт често се използва и за двете помага за влошаване на това често срещано объркване. Това объркване е толкова често срещано, че може би този проблем трябва да бъде включен в тази публикация като „Обща нулева уязвимост на мрежата“.

Така че, преди да продължим, нека изясним разграничението между тези два термина:

• Удостоверяване: Проверка, че дадено лице е (или поне изглежда, че е) конкретен потребител, тъй като е предоставил правилно своите идентификационни данни за сигурност (парола, отговори на въпроси за сигурност, сканиране на пръстови отпечатъци и т.н.).
• Разрешение: Потвърждаване, че определен потребител има достъп до определен ресурс или му е дадено разрешение за извършване на определено действие.

Казано по друг начин, удостоверяване е да знаете кой е даден субект, докато упълномощаване е да знаем какво може даден обект. Имайки това предвид, нека да влезем в първите 10 проблема със сигурността в интернет.

Често срещана грешка в уеб сигурността # 1: Инжекционни недостатъци

Недостатъците на инжектирането са резултат от класически неуспех за филтриране на недоверен вход. Това може да се случи, когато предавате нефилтрирани данни на SQL сървъра (SQL инжекция), на браузъра (XSS - ще говорим за това по късно ), към LDAP сървъра (LDAP инжектиране) или някъде другаде. Проблемът тук е, че нападателят може да инжектира команди на тези обекти, което води до загуба на данни и отвличане на браузърите на клиентите.

Всичко, което вашето приложение получава от ненадеждни източници, трябва да бъде филтрирано, за предпочитане според бял списък. Почти никога не трябва да използвате черен списък, тъй като получаването на това право е много трудно и обикновено е лесно да се заобиколи. Антивирусните софтуерни продукти обикновено предоставят звездни примери за неуспешни черни списъци. Съвпадението на шаблона не работи.

Предотвратяване: Добрата новина е, че защитата срещу инжектиране е 'просто' въпрос на правилно филтриране на входа и мислене дали на даден вход може да се вярва. Но лошата новина е, че всичко входът трябва да бъде правилно филтриран, освен ако на него несъмнено може да се има доверие (но поговорката „никога не казвай никога“ тук идва на ум).

Например в система с 1000 входа успешното филтриране на 999 от тях не е достатъчно, тъй като това все още оставя едно поле, което може да служи като изцеление на Ахил, за да разруши вашата система. И може би си мислите, че поставянето на резултат от SQL заявка в друга заявка е добра идея, тъй като на базата данни се има доверие, но ако периметърът не е, входът идва индиректно от момчета с злоупотреба. Това се казва SQL инжекция от втори ред в случай, че се интересувате.

Тъй като филтрирането е доста трудно да се направи правилно (като крипто), това, което обикновено съветвам, е да разчитате на функциите за филтриране на вашата рамка: доказано е, че работят и са внимателно проучени. Ако не използвате рамки, наистина трябва да помислите добре дали не използването им наистина има смисъл в контекста на сигурността на вашия сървър. 99% от случаите не е така.

Често срещана грешка в уеб защитата # 2: Счупено удостоверяване

Това е колекция от множество проблеми, които могат да възникнат по време на нарушено удостоверяване, но не всички произтичат от една и съща основна причина.

Ако приемем, че някой все още иска да пусне собствения си код за удостоверяване през 2014 г. (какво мислите ??), съветвам го да не се използва. Изключително трудно е да се постигне право и има безброй възможни клопки, само да спомена няколко:

1. URL адресът може да съдържа идентификатора на сесията и да го изтече в заглавката на референта на някой друг.
2. Паролите може да не бъдат криптирани нито при съхранение, нито при транспортиране.
3. Идентификаторите на сесията могат да бъдат предвидими, като по този начин получаването на достъп е тривиално.
4. Фиксирането на сесията може да е възможно.
5. Възможно е отвличане на сесии, изчакванията не са приложени правилно или се използва HTTP (без SSL защита) и т.н ...

Предотвратяване: Най-ясният начин да се избегне тази уязвимост на уеб защитата е използването на рамка. Може да успеете да приложите това правилно, но първото е много по-лесно. В случай, че искате да пуснете свой собствен код, бъдете изключително параноични и се научете какви са клопките. Има доста.

Често срещана грешка в уеб защитата # 3: Скриптиране на различни сайтове (XSS)

Това е доста широко разпространен провал на хигиенизирането на входа (по същество специален случай на често срещана грешка # 1 ). Атакуващият дава JavaScript маркери на вашето приложение при въвеждане. Когато този вход се върне на потребителя несинизиран, браузърът на потребителя ще го изпълни. Това може да бъде толкова просто, колкото създаването на връзка и убеждаването на потребителя да щракне върху нея, или може да бъде нещо много по-зловещо. При зареждане на страницата скриптът се изпълнява и например може да се използва за публикуване на бисквитките ви към нападателя.

Предотвратяване: Има просто решение за уеб защита: не връщайте HTML маркери на клиента. Това има допълнителната полза от защитата срещу инжектиране на HTML, подобна атака, при която атакуващият инжектира обикновено HTML съдържание (като изображения или силни невидими флаш плейъри) - не с голямо въздействие, но със сигурност досадно („моля, спрете!“). Обикновено заобикалящото решение е просто преобразуване на всички HTML обекти , така че това се връща като