1

Икономически университет – Варна

Разработил : Добрин Благоев , фак № 9381 ,

51 група , специалност :”Информатика”

2

СЪДЪРЖАНИЕ:

1.Какво е ASP.NET? ________________________________________________________ 6

1.1Как работи ASP.NET сигуността? ____________________________________________ 7

2. Типове заплахи : ________________________________________________________ 7

2.1 Какво представляват SQL инжекциите? ______________________________________ 7

2.2 Използване на лесни за налучкване пароли или използване на една и съща парола за

login на различни места. ________________________________________________________ 9

2.2.1 Пароли: ________________________________________________________________ 9

2.2.2 слабите пароли : ________________________________________________________ 9

2.2.3 Празни пароли. _________________________________________________________ 9

2.2.4 Несигурно съхранение на пароли. _________________________________________ 10

2.2.5 Варианти за по-сигурно съхранение: ______________________________________ 10

2.3 Предпазване от XSS атаки и логване на атакуващия. __________________________ 10

2.3.1 Как работи XSS? _______________________________________________________ 10

2.3.2 Проверяване на кукитата ______________________________________________ 11

2.3.3 Как да се защитим от XSS: _____________________________________________ 14

2.4 Атаки "отказ на услуга" (Denial-of-Service - DoS атаки) _________________________ 14

2.5 Изчерпване на системните ресурси _________________________________________ 14

2.6 Предсказване на директории и URL адреси ____________________________________ 15

2.7 Атаки с променяне на целта ________________________________________________ 15

2.7.1 Атаки с променяне на директория _______________________________________ 15

2.7.2 Атаки с променяне на главна директория ________________________________ 15

2.8 Заплахи идващи от локалната мрежа и предпазване от тях ___________________ 16

2.9 Вмъкване (include) на файлове, които се подават като параметър през URL адрес 16

3.Авдентикация в ASP.NET : ______________________________________________ 16

3.1 Windows-Based автентикация: ______________________________________________ 17

3.1.1 Impersonation (въплъщаване) _____________________________________________ 17

3

3.1.2 Windows-Based – login: __________________________________________________ 17

3.2 NET Passport автентикация: ________________________________________________ 18

3.3 Forms-Based автентикация: ________________________________________________ 19

3.3.1 Страница за вход: ______________________________________________________ 20

3.3.2 Вградена автентикация - _______________________________________________ 20

Конфигуриране: ____________________________________________________________ 20

3.3.3 Вградена автентикация - login код: ______________________________________ 21

3.3.4 Ръчна автентикация - __________________________________________________ 21

Конфигуриране: ____________________________________________________________ 21

3.3.5 Ръчна автентикация - login код: _________________________________________ 21

4 Оторизация в ASP.NET: _________________________________________________ 22

4.2 NTFS/ACL – конфигуриране: ________________________________________________ 23

4.3 URL/директория – конфигуриране: __________________________________________ 23

4.4 WSAT (Web Site Administration Tool): _________________________________________ 23

5. Основни методи свързани със сигурността на уеб приложението .Ръчно и

автоматично(wizard) конфигуриране на приложението ,касаещо сигурността

му.(MSDN Съвети). _______________________________________________________ 24

5.1 Основни стъпки за адекватната защитa на Forms-Based автентикацията : ____ 24

5.1.1 Използвайте “membership” доставчиците , вместо обичайната авдентикация. 24

5.1.2 Използвайте на SSL за защита на пълномощията и "бисквитките" за

авдентификация. ___________________________________________________________ 25

5.1.3 Ако не можете да използвате SSL, помислете за намаляване на времетраенето

на сесията. ________________________________________________________________ 26

5.1.4 Проверка на потребителска информация за вход. _________________________ 27

5.1.5 Да не се съхраняват паролите директно в базите данни на потребителя . ____ 27

5.1.6 Криптиране на пароли за потребителска оторизация,хеширане: ____________ 27

FN_MD5 ___________________________________________________________________ 28

5.1.7 Прилагане на силни пароли. _____________________________________________ 29

5.1.8 Защита на достъпа до главния сървър за данните. _________________________ 30

4

5.1.9 Ограничаване на данните за авдентикация само по HTTPS връзките. ________ 30

5.1.10 Помислете за разделяне на сайта ,на зони с ограничен достъп и зони с

нормален достъп. ___________________________________________________________ 31

5.1.11 Използвайте уникални „бисквитки” и пътя до тях . ______________________ 31

5.2 Как да заключим ASP.NET приложение или Уеб услуга: ________________________ 31

5.2.1.Филтър на пакети: ____________________________________________________ 31

5.2.2 Защитни стени в приложния слой: ______________________________________ 32

5.2.3 NTFS Сигурност: ______________________________________________________ 32

5.2.4 Конфигуриране URLScan: _______________________________________________ 32

5.2.5 Конфигуриране на сигурността в SQL Server –а: ___________________________ 32

5.2.6 Сигурност при достъпа до данните: (как да се защитим ;насоки) ____________ 33

5.3 Вход /Потвърждаване на данните: __________________________________________ 33

5.3.1 Да не се разчита само на ASP.NET молбата за валидиране . ________________ 33

5.3.2 Проверка Вход за дължина, обхват, формат и вид . ________________________ 33

5.3.3 Проверка на данни от всички източници, като QueryString, бисквитки и HTML

контроли. _________________________________________________________________ 34

5.3.4 Не разчитайте на проверка от страна на клиента: _______________________ 34

5.3.5_Избягвайте име на файла осигурен от потребителя и въвеждане на пътя : _ 34

5.3.6 Имената на файловете ________________________________________________ 35

5.3.7_Пътеки на файловете: _________________________________________________ 35

5.3.8.Не връщайте обратно непроверен вход: __________________________________ 35

5.3.9Ако трябва да изпратите непроверени данни ,кодирайте изхода: ___________ 35

5.4 Други препоръки за сигурността : (автоматизирани настройки): _______________ 36

5.4.1 Избор на операционна система. __________________________________________ 36

5.4.2 Предназначение на сървъра. _____________________________________________ 36

5.4.3 Премахване на услуги: __________________________________________________ 36

5.4.4 Конфигуриране на сигурността: _________________________________________ 37

5.4.5 Примерите: ___________________________________________________________ 37

5

5.4.6 Validation (валидация, проверка): _________________________________________ 38

5.4.7 Забрана за автоматична валидация: _____________________________________ 38

5.4.8 Patching (кръпки, ъпдейти): _____________________________________________ 38

5.4.9 MBSA – сканиране: _____________________________________________________ 38

5.4.10 Logging: ______________________________________________________________ 40

6

1.Какво е ASP.NET?

ASP.NET представлява технология за разработка , на мощни web приложения базирани

на .NET платформата на Майкрософт, предлагайки някои съществени предимства в

сравнение с предишните модели за разработка на web приложения.

Характерни черти на ASP.NET :

Повишена производителност – създаваните с ASP.NET приложения представляват код,

който се изпълнява на уеб сървър. За разлика от предшестващите го технологии,

ASP.NET е в състояние да се възползва от предимствата на ранно свързване, just-in-time

компилирането, оптимизация на кеширане (на различни нива) и др. По този начин

получавате висока производителност преди да сте написали и ред програмен код.

Фиг.1: Представяне на логин формата и връзкара с MEMBERSHIP

доставчика.

7

1.1Как работи ASP.NET сигуността?

Концепцията за сигурност е залегнала в основата на ASP.NET. Уеб приложенията,

които изграждаме, по всяка вероятност ще се ползват от много на брой потребители и

сигурно ще са достъпни през Интернет. Това изисква от ASP.NET да предложи добре

развит механизъм за осигуряване на сигурност.

2. Типове заплахи :

- Като цяло трябва да споменем ,че уеб-приложенията са много по-уязвими

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

поражда , както от слабости на самото приложение,така и от слабости на самите

сървъри, СУБД, други приложения.

Нека и да споменем кои са възможните заплахи в .NET (ASP) приложенията:

- SQL инжекции.

- XSS атаки (крос сайт скриптинг)

- Затруднен достъп до услугитe .(denial of service- затруднено позване на

ресурсите и услугите на провайдера).

- Brute Force Attacks(събаряне на криптираните бази данни)

- Използване на лесни за налучкване пароли или използване на една и съща

парола за login на различни места.

- Прихванати пароли, посредством неоторизиран достъп до e-mail кутия, в която

се съдържат данни за достъп до акаунта/сървъра.

- Промяна на уеб-сайта, замяна на коректна с некоректна и заблуждаваща

информация.

- Вмъкване (include) на файлове, които се подават като параметър през URL адрес,

без да се прави коректна проверка дали файлът, който се вмъква, е от същото

приложение.

- Предсказване на директории и URL адреси

- Неавторизиран достъп до вътрешни мрежи.

- Изчерпване на системните ресурси

- Прихващане и манипулиране на входни „cookies”.

- Заразяване с вируси, троянски коне, инсталиране на код за DdoS атаки.

- Загуба на данни.

- прочитане/компрометиране на данни чрез packet sniffing.

- Компрометиране на сървъра чрез представяне като друго лице.

2.1 Какво представляват SQL инжекциите?

Има много начини една система да бъде пробита. Когато става дума за уеб базиран

софтуер, това най-често става със SQL инжекции. Това е най-разпространения начин за

атакуване на уеб сайт. В тази публикация накратко ще обясним какво точно

представляват SQL инжекциите и какви са вариантите те да бъдат затворени.

8

SQL инжекциите са уязвимости с начина на обработка на заявките към SQL сървъра.

Обикновенно бива подаван параметър, който освен информацията с ключа за конкретен

запис, съдържа и допълнителен код. По този начин хакерите могат да извличат

информация от Вашата база данни. Това могат да бъдат имейл адреси, които след това

се използват за спам цели, администраторски профили и друга конфиденциална

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

пароли. Те се пазят в базата с данни в криптиран вид. Лесно се разбиват (посредством

Bruteforce и MD5 Hash databases) лесните пароли. Обикновенно сложните не могат да

бъдат декриптирани. Всеки един програмен език е уязвим към SQL инжекции.

Обикновенно те се срещат при PHP, Perl, ASP.NET.

Решението е да се използват отделни функции, които проверяват параметрите, които се

подават при изпълняване на заявка. Под PHP може да се използва

mysql_real_escape_string() функцията. Друга нещо, което може да помогне е

използването на променливи, съдържащи строго определен вид данни. Например, само

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

филтриран преди подаването му в SQL заявката. Това ще обезпечи нейното

безпроблемно изпълнение и невъзможността да бъде пробита.

SQL инжекциите, като стар, но все още доста често срещан начин за атакуване на уеб

сайтове, не трябва да бъдат подценявани. Огромно количество сайтове (дори

правителствени) са уязвими към този вид атаки. Пример на c# , който е податлив на sql

инжекция:

strAuthor = Request.QueryString("authorname")

strConnectString = "Provider=SQLOLEDB; Data Source=sqlmac;Initial Catalog=test;

Integrated Security=SSPI;"

Set objConn = Server.CreateObject("ADODB.CONNECTION")

Set objCommand = Server.CreateObject("ADODB.COMMAND")

' Connect to SQL Server

objConn.Open(strConnectString)

' Execute the command

strCmd = "select title, description from books where author_name = '" & strAuthor &

"'"

Set objCommand.ActiveConnection = objConn

objCommand.CommandText = strCmd

objCommand.CommandType = adCmdText

Set objRS = objCommand.Execute()

' Process the resultset

' Close the objects

Ако обърнете внимание на кода, името на автора се чете от GET параметър (чрез

Request.QueryString) и след това се използва пряко в изграждането на изявление SQL

(sqlCmd), без да се проверява. Ако името на автора е някои валиден низ като Майкъл

след заявката връща книга с автор Майкъл. Но какво става, ако крайния потребител

въведе името на автора като: Michael'; drop table books; ?? В този случай последната

команда SQL става: select title, description from books where

author_name='Michael';drop table books . Това не само избира книги с автор Майкъл,

но и смъква таблица с име " книги”. Проблемът тук е, че разработчикът просто приема,

9

че на входа ще бъде низ без единични кавички, но никога не е валидирал Входният низ

за това. Всъщност този код не работи и ако името на автора е нещо като О'Нийл.

Най-добрият начин за решаване на този проблем , е използването на параметризирани

заявки. В предишния пример, се предполага, че максималната дължина на името на

автора на базата данни е 50. Ще „закърпим” кода в по-долу показания вариант:

' Execute the command

strCmd = "select title, description from books where author_name = ?"

Set objCommand.ActiveConnection = objConn

objCommand.CommandText = strCmd

objCommand.CommandType = adCmdText

Set param1 = objCommand.CreateParameter ("author", adWChar, adParamInput, 50)

param1.value = strAuthor

objCommand.Parameters.Append param1

Set objRS = objCommand.Execute()

' Process the resultset

' Close the objects

2.2 Използване на лесни за налучкване пароли или използване на една и

съща парола за login на различни места.

2.2.1 Пароли:

Доста често лесните пароли са основната причина за това, акаунтите да бъдат

разбивани. Хакерите могат да използват специални речници или така наречените brute

force (брутална сила) атаки за успешното пробиване на вашата парола. Какво е най-

лесното и правилно решение? Да използвате по-силни пароли разбира се… Основно

място, на което трябва да акцентирате са вашите имейли, защото обикновенно след

това хакерите могат да получат достъп до почти всички ваши услуги.

Често пробиви в приложенията стават поради :

- често недоглеждана област на защитата.

- слаби пароли.

- липсващи пароли.

- пароли в текстови файлове или в други файлове, поставени на уеб сървъра.

2.2.2 слабите пароли :

- Имена на места.

- Дати (рождени, годишнини) .

- Думи от речника.

- Кратки (под 8 символа).

- Само букви или само числа.

2.2.3 Празни пароли.

10

- да не се прави защита като просто се поставят страници за достъп в

директория, която само определени потребители знаят или с имена, които

само те знаят.

- да се внимава с SQL Server и MSDE – в някои ранни версии по подразбиране

паролата на sa е празна.

2.2.4 Несигурно съхранение на пароли.

- основно пароли за достъп до БД и/или кои потребители/пароли имат право на

достъп.

- основен проблем е съхранението им в обикновени текстови файлове - ASP.NET,

Global.asax и др., които са в директориите на уеб-приложението.

2.2.5 Варианти за по-сигурно съхранение:

- при интранет (Windows) и връзка с SQL Server / MSDE може да се

използва "Trusted Connection".

- да се съхранят пароли в machine.config.

- да се използва метода HashPasswordForStoringInConfigFile,

но само за сравнение.

- криптиране чрез други методи.

2.3 Предпазване от XSS атаки и логване на атакуващия.

2.3.1 Как работи XSS?

Това е начин за инжектиране на код в генериран HTML. Става с помоща на

променливите предвани чрез метода GET или при нефилтрирано(непроверено) поле за

специални символи, използвани в HTML. Основно XSS се използва за крадене на сесия

или куки (coockie).

Атаките от типа крос-сайт скриптинг (XSS) са един от днешните основни

вектори на атака, експлоатиращи уязвими уеб сайтове и използващи браузъри, за

да крадат кукита или да започнат финансова транзакция. Пробойните тип ХSS са

широко разпространени и изискват от организацията да внедри изчерпателно

разработен жизнен цикъл на сигурността, който включва моделиране на

заплахите, сканиращи инструменти и усилена бдителност към сигурността, за да

постигне най-добрата възможна позиция за защита и превенция от XSS.

Крос-сайт скриптингът (XSS) позволява на нападателите да изпращат злонамерен код

към друг потрбител, като се възползват от пробойна или слабост в интернет сървър.

Нападателите се възползват от XSS средства, за да инжектират злонамерен код в линк,

11

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

вграденото програмиране се включва и се изпълнява на компютъра на потребителя,

което предоставя на хакера достъп, за да открадне чувствителна информация.

Нападателите използват XSS, за да се възползват от уязвимостите на машината на

жертвата и от зловредния код в трафика вмсто да атакуват самата система. Много Web

сървъри генерират своите страници динамично. Например една търсачка може да

извърши търсене в своята база данни и след това да генерира страница на базата на

резултатите. Всеки сървър, който създава Web страници, в които е включена

информация от динамично попълнени шаблони, трябва да извършва проверка за не

наличие на специални символи. Ако в създаваните страници бъде включена

информация, съдържаща специални символи, то клиентският браузър би я тълкувал

като HTML тагове или скрипт, а не като обикновен текст. Това би дало възможност на

атакуващия да изпълнява избрани от него програми върху машината на клиента и то от

името на сървърът.

Нападателите имат възможност да променят HTML кода, който контролира страницата,

като използват уеб форми, които връщат съобщение за грешка при въвеждане на данни

от потребителя. Хакерът може да вмъкне код в линка на спам съобщение или да

използва имейл измама с цел да подмами потребителя да смята, че източникът е

легитимен.Например нападател може да изпрати на жертвата имейл съобщение с URL,

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

URL в блог или сайт на социална мрежа като Facebook или Twitter. Когато потрбителят

щракне върху линка, зловредният сайт, както и скриптът, заработват в браузъра му.

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

свой ред позволява на скрипта на нападателя да получи достъп до функционалността на

сайта, за да открадне кукита или да извърши транзакции, представящи се за легитимен

потребител.

2.3.2 Проверяване на кукитата

"Бисквитките" (cookies) са малки файлове, които се съхраняват временно на вашия

твърд (hard) диск и позволяват на сървъра да разпознае компютъра ви следващия път,

когато посетите Интернет. Бисквитките" се използват за да се отбележи кои части от

страницата сте посетили или извършили лични настройки, така че при последващо

ваше посещение, тези страници могат да бъдат показвани "на готово".Кукитата

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

променяно от атакуващият. Поради тази причина приеманите кукита трябва да бъдат

внимателно преглеждани, като над тяхното съдържание биват прилагани методите за

кодиране и филтриране, описани по-горе. Ето един пример за манипулиране на

информацията, носена от куки.Изпращано от сървъра, кукито има следният вид:

<% Response.Write("<BODY BGCOLOR=\"" +

Request.Cookies("UserColor") + "\">");%>

След промяна извършена върху клиентската машина кукито придобива вида:

12

Cookie: %22+onload%3D%27window%2Elocation%3D

%22http%3A%2F%2Fwww%2Eevilsite%2Ecom%22%3B%27

което означава:<body BGCOLOR="" onload=

'window.location=http://www.evilsite.com;'">

водещо до пренасочване на потребителя.

Ето и два примера за инжектиране на скриптове в динамично създавани страници. При

първият предполагаме, че от потребителя се изисква да въведе във форма името си,

което по късно бива визуализирано. Злонамерен потребител би могъл да въведе:

<script language='javascript'>

alert ('gatcha!');

</script>

вместо името си. В този случай скриптът просто ще изпише предупреждение, но в

общия случай той може да бъде какъвто атакуващият избере.

Инжектирането на скрипт може да бъде направено и чрез HTML таг, например:

<a herf=" [event]='bad script here' ">

click me

</a>

Този тип атаки най-често бива прилаган срещу сайтове, в които въведената

информация се представя на всички потребители, например сайтове за онлайн

дискусии.

Атакуване на приложението :

За да може злонамерен потребител да проведе XSS атака срещу приложението ,

той първо трябва да се намери вектора, където по –долу представените

изисквания са верни:

- Приложението е с не валидизиран вход на данните :

- Приложението няма криптиран изход на данните:

13

Фиг.2: XSS вектора на атакуващия в ThankYou.aspx страницата.

Забележете ,че изходните данни в ThankYou.aspx страницата се оформят

изпозвайки невалидизиран вход данни на потребителя ,и използва този вход в

данните за отговор ,без предварително кодиране.Злонамерения потребител може

лесно да използва този XSS вектор ,като излъже потребителя ,който гледа

ThankYou.aspx страницата ,той през това време праща скрипт от този сорт:

<script>alert('Xss Vector!')</script> . параметъра за името .

Фиг.3 . Показваща XSS уязвимостта в ThankYou.aspx страницата.

14

2.3.3 Как да се защитим от XSS:

1. : Преглед ASP.NET кода, който генерира изходните данни

2. Определете дали изхода включва, невалидизирани входни параметри.

3. Определяне на контекста, в който непроверения вход се използва като изход

4. Криптираме изходните данни.

5. Изрично указване на символното множество, използвано при генерирането на

Web страници

6. Установяване на специалните символи

7. Филтриране на специалните символи от динамичните елементи : < > ( ) { } + ! @ $ % * ..

8. Проверяване на кукитата

2.4 Атаки "отказ на услуга" (Denial-of-Service - DoS атаки)

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

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

дни и може да се отразят на производителността на мрежата, на целостта на данните

или на системните операции. Те работят по един от следните начини:

Консумиране на капацитета на мрежовата връзка

Изчерпване на системните ресурси

2.5 Изчерпване на системните ресурси

Подобно на мрежата, всеки компютър има ограничено количество ресурси,

включително памет, дисково пространство и капацитет на процесора. При този тип

атака, даден ресурс (ресурси) бива изчерпан, което прави невъзможен достъпа на други

приложения до него. SYN наводняването е типичен пример за такава атака. Тя води до

заемане на всички мрежови ресурси на една система.

Всяка система, поддържаща TCP/IP връзки, има лимит на броя на едновременно

активните връзки. SYN наводняването използва тристъпковото ръкостискане при

установяването на TCP/IP връзка. Успехът на тази атака се дължи на инициирането на

наполовина създадени връзки на порта на сървърът-мишена. Това са такива връзки, при

които тристъпковото ръкостискане не е завършено. При атакуване се изпраща само

първият пакет от TCP/IP ръкостискането, при това с невалиден или подменен адрес на

изпращача. Сървърът отговаря със SYN пакет с потвърждение, но поради това, че то

бива изпращано на фалшивия адрес, третият пакет от ръкостискането, с

потвърждението, което сървърът очаква, никога не пристига. Тези връзки остават

активни до изтичане на времето за изчакване на създаване на връзка. По този начин се

запълва максималният брой отворени връзки и нови връзки не могат да бъдат

осъществени.

Примери за други DoS атаки са "Smurf" и "fraggle". Тези атаки се осъществяват чрез

изпращане на голям брой Internet Control Message Protocol ( ICMP) ехо (ping)

съобщения на IP broadcast ("до всички") адреса на предварително избрана ( желателно

голяма ) мрежа, служеша за посредник, като адресът на изпращача им е подменен с

адреса на жертвата. Всяка една от машините, намиращи се в мрежата, на чиито IP

15

broadcast адрес е изпратен пакетът, ще отговори на изпратеното съобщение. По този

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

"Fraggle" атаката е подобна на "smurf" атаката с тази разлика, че при нея се използват

User Datagram Protocol (UDP) ехо съобщения.

2.6 Предсказване на директории и URL адреси

Този вид атака най-често бива прилагана срещу сайтове, предлагащи снимки, файлове

или друга информация срещу заплащане. Макар и да изглежда тривиална, тази атака

често завършва с успех. Нейната цел е придобиване на достъп, без преминаване през

определените за това процедури, например пропускане на рекламни банери, спонсори,

автентификация на потребителя или доказване на необходимата за достъп възраст ( при

сайтове, предназначени само за възрастни ). Можем да разделим тези атаки условно на

четири вида:

2.7 Атаки с променяне на целта

При оригинален адрес, до който потребителят има легитимен достъп,

например:http://www.website.com/pictures/pic1/pics/picture01.jpg потребителят би могъл

да направи промяна в него, даваща му неоторизиран достъп до други файлове,

например:

http://www.website.com/pictures/pic1/pics/picture02.jpg ( 03, 04 и т.н. )

2.7.1 Атаки с променяне на директория

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

вместо файл. При оригинален адрес:

http://www.website.com/pictures/pic1/pics/picture01.jpg

потребителят би могъл да придобие достъп и до цялата директория, ако тя не e

защитена:http://www.website.com/pictures/pic1/pics/

2.7.2Атаки с променяне на главна директория

При тази атака бива променяно името на директория от пътя указан от URL адресът.

При оригинален адрес:

http://www.website.com/pictures/pic1/pics/picture01.jpg

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

на техните имена, което в някой случаи ( като този в примера ) е лесно:

http://www.website.com/pictures/pic1

http://www.website.com/pictures/pic2

http://www.website.com/pictures/pic3 и т.н.

16

2.8 Заплахи идващи от локалната мрежа и предпазване от тях

Сега ще разгледам една проста атака която е най-често срещаната заплаха, която

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

последици и изтичане на информация. Sniffing е атака при която злонамереното

лице подслушва и преглежда трафика в мрежата, като по този начин може да

прехване пароли, както и практически всяко едно съобщение, което се

разпространява из мрежата. Някои мрежови специалисти вярват, че ако се използва

комутатор, тази атака се предотвратява напълно. За жалост това не е така.

Съществува един метод, който се нарича ARP Poissoning. При него се заразяват

ARP таблиците на хостовете, като по този начин чуждия мрежов трафик се прекарва

през атакуващия компютър, позволявайки той да бъде подслушван и дори

променян. Атаката при която се променя преминаващия трафик се нарича man in the

middle(междинна атака) и позволява осъществяването на много други атаки.

2.9 Вмъкване (include) на файлове, които се подават като параметър

през URL адрес, без да се прави коректна проверка дали файлът,

който се вмъква, е от същото приложение. При тези случаи злонамерено лице може да вмъкне (include) произволен файл или

адрес, след което и да получи пълен достъп до акаунта.По принцип не е добра

практика, директно да се вмъкват (include) файлове, чието име се подава като

параметър в адреса. Едно от решенията е, вместо това да се създаде таблица, в която

с ID-та са описани файловете, които ще се вмъкват, като в адреса се подава ID-то на

файла, а вътрешно в скрипта е определено кой файл трябва да се включи.По този

начин няма как да се подаде друг файл, освен този, които е дефиниран.Ако по

някаква причина трябва да остане подаването на файл в URL адреса трябва да се

добави и проверка, дали файлът се намира в хостинг акаунта и да се вмъква само ако

е изпълнено това условие.

3.Авдентикация в ASP.NET :

Автентикацията е процесът на разпознаване на даден потребител. Потре-

бителят се представя като предоставя данни за себе си (напр. Потреби-

телско име и парола). Тези данни се проверяват за валидност. Ако са

валидни, потребителят се счита за автентикиран. В противен случай му се

отказва достъп до система или поискания ресурс. В ASP.NET има три

възможности за автентикация: windows, forms и passport автентикация.

Ще се спрем по-подробно на всяка от тях след малко.

Оторизацията е процес на свързване на потребител с дадени права. За

оторизиран се счита потребител, който има право да работи с поискания

ресурс или да извърши конкретната операция. Във веригата на сигурност-

та това е следващият процес след автентикацията – след като разберем

кой е потребителят, ние трябва да знаем какви са неговите права. В

ASP.NET за оторизация се използва моделът Role-Based Security, т.е. всеки

потребител може да е в една или повече роли. Процесът на оторизация

17

може да се извършва не само на ниво потребител, но и на ниво роля.

Видове автентикация:

- Windows-based - потребителите/паролите са същите като на съответния сървър.

- Forms-based - потребителите могат да са други, да са зададени в списък или да се

проверяват от файл/БД.

- Passport - с използване на централизирания Microsoft Passport Service.

3.1 Windows-Based автентикация:

Windows автентикацията е най-добре да използваме, ако разработваме

приложение, което ще се използва в рамките на една компания (в нейния

Интранет), където потребителите са част от потребителския домейн и са

фиксиран брой. Този вид автентикация е неприложим, ако приложението

ще се използва в Интернет. Съществъва в три вида:

- Basic - съвместим с почти всички браузъри, но имената/паролите се

предават в обикновен текст, добре е ако има SSL.

- Digest - съвместим с по-малко браузъри (HTTP 1.1), но изисква Windows Domain

Controller

- Integrated Windows (NTLM) - най-сигурен метод, но работи само с Internet

Explorer.

3.1.1 Impersonation (въплъщаване?)

- допълнителна възможност към Windows-based автентикацията.

- автентикацията към ASP.NET с име/парола води до идентифицирането с това

име/парола към всички Windows ресурси.

- най-често се използва за авторизация до файлове/директории и/или достъп до

СУБД (напр. SQL Server).

3.1.2 Windows-Based – login:

18

Фиг.4 Windows-Based – login:

Избор на методи за автентикация:

Фиг.5. Избор на методи за автентикация:

Windows-Based - Web.config:

<authentication mode="Windows" />

3.2 NET Passport автентикация:

Този метод се базира на услугата MS Passport, която Microsoft предлага на своите

клиенти. Тази услуга всъщност представлява голямо единно хранилище на информация

за регистрирали се потребители. Информацията за тях е достъпна през уеб услуги.

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

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

19

Излизането може да стане както от текущия сайт, така и от всички сайтове, в които е

влязъл потребителят. Предимствата на този подход са, че се предоставя единен

механизъм за работа с потребители (единна база от данни), както и че има високо ниво

на сигурност. Недостатъците са, че услугата не е безплатна, а и работата на

приложението става зависимо от трета страна (в случая Microsoft). Централизиран

Microsoft Authentication Service.

Трябва да се изтегли Passport SDK и да се плати лицензионна такса.

В Web.config:

<authentication mode="Windows" />

Със собствена redirect страница при липса на

автентикация:

<authentication mode="Passport">

<passport redirectUrl="<URL>">

</authentication>

3.3 Forms-Based автентикация:

Фиг.6 Forms автентикация – принцип на действие :

Това е може би най-често използваният метод за автентикация в ASP.NET. В него

самото приложение се грижи за автентикирането на потребителите.

Forms автентикация – принцип на действие :

При поискване на ресурс (страница), който е разрешен само за автентикирани

20

потребители, клиентският браузър се пренасочва към предварително указана страница,

на която ще се извърши автентикацията. При успешна автентикация към клиента се

изпраща бисквитка, която указва, че потребителят е вече автентикиран. При всяка

следваща заявка бисквитката се прихваща и използва от ASP.NET за разпознаване на

автентикираните потребители.

Forms автентикацията е най-масово използваният метод за автентикация, защото е

много удобен за реализиране на конкретна логика за управление на потребителите.

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

Интернет, където броят на потребителите е силно динамичен. Единственото неудобство

е, че разчита на бисквитки, но и затова е помислено, като има възможност за сесия без

бисквитки – cookieless session.

3.3.1 Страница за вход:

Фиг.7 Страница за вход:

3.3.2 Вградена автентикация -

Конфигуриране:

Web.config:

<authentication mode="Forms">

<forms name="formsauth" loginUrl="login.aspx"

protection="All" timeout="60">

<credentials>

<user name="username" password="password"/>

</credentials>

</forms>

</authentication>

<authorization>

21

<deny users="?" />

</authorization>

3.3.3 Вградена автентикация - login код:

В login.aspx.cs:

using System.Web.Security;

Прихващане на събитието на натискане на бутона;

Button_Click:

if(FormsAuthentication.Authenticate(TextBox1.Text,

TextBox2.Text))

FormsAuthentication.RedirectFromLoginPage(

TextBox1.Text, CheckBox1.Checked);

else

Label4.Text = "Incorrect username or password!";

3.3.4 Ръчна автентикация -

Конфигуриране:

Web.config:

<authentication mode="Forms">

<forms name="formsauth" loginUrl="login.aspx"

protection="All" timeout="60">

</forms>

</authentication>

<authorization>

<deny users="?" />

</authorization>

3.3.5 Ръчна автентикация - login код:

В login.aspx.cs:

using System.Web.Security;

Прихващане на събитието на натискане на бутона;

Button_Click:

if(TextBox1.Text==user && TextBox2.Text==pass)

FormsAuthentication.RedirectFromLoginPage(

TextBox1.Text, CheckBox1.Checked);

22

else

Label4.Text = "Incorrect username orpassword!";

4 Оторизация в ASP.NET:

Оторизацията е процес на свързване на потребител с дадени права. За

оторизиран се счита потребител, който има право да работи с поискания

ресурс или да извърши конкретната операция. Във веригата на сигурност-

та това е следващият процес след автентикацията – след като разберем

кой е потребителят, ние трябва да знаем какви са неговите права. В

ASP.NET за оторизация се използва моделът Role-Based Security, т.е. всеки

потребител може да е в една или повече роли. Процесът на оторизация

може да се извършва не само на ниво потребител, но и на ниво роля.

Нека да разгледаме как се извършва оторизацията чрез сигурност, базирана на

роли.Оторизацията може да се извършва на ръка ,може и чрез Web Site Administration

Tool.Това е Wizard направен за Улеснение на разработчика. На него ще се спрем

малко по надолу :

Пример за ръчно оторизиране е следня код на писан в Global.asax.cs файла:

protected void Application_AuthenticateRequest(Object sender,

EventArgs e)

{

if (HttpContext.Current.User != null)

{

if (HttpContext.Current.User.Identity.IsAuthenticated)

{

FormsIdentity identity =

HttpContext.Current.User.Identity as FormsIdentity;

if (identity != null)

{

if (identity.Name == "Stefan" )

{

HttpContext.Current.User = new GenericPrincipal(

identity, new string[]{ "Web Developer" } );

} }}}}

Методът Application_AuthenticateRequest се извиква, когато даден

потребител бъде автентикиран. Ето какво правим в този случай. Проверя-

ваме дали наистина е автентикиран и ако е така, проверяваме дали се

използва Forms автентикация. Ако такава е налична, може да използваме

свойството Name на обекта identity, което ни връща вече съхраненото

име за потребителя в бисквитката за автентикация. След това реализи-

23

раме логиката за задаване ролите на потребителя, който се е автентики-

рал. В случая на потребителя "Stefan" се задава роля "Web Developer",

което ще му позволи достъп до всички ресурси, които са разрешени както

за него, така и за неговата роля.

Още видове ръчно оторизиране са :

4.2 NTFS/ACL – конфигуриране:

Web.config:

<authentication mode="Windows" />

<identity impersonate="true" />

Задаване чрез Windows Explorer (или друга програма)

на правата за съответните директории и/или файлове.

- NTFS ACL - използва дадените права върху файловете и директориите от NTFS,

има смисъл при Windows-based автентикация.

- URL/директория – конфигуриране на специфични Web.config за различните

директории на приложението.

4.3 URL/директория – конфигуриране:

- групират се файловете вдиректории според това кой трябва да има достъп до тях

и/или се задава точен път в Web.config.

- създават се в директориите файлове Web.config с данни кой има право на достъп

до тях и кой – не.

4.4 WSAT (Web Site Administration Tool):

(За Framework 3.5 и нагоре): http://www.youtube.com/watch?v=8t1MoIsMUKE (урок)

WSAT e wizard за автоматизирана конфигурация ( и оторизация) на уеб приложението

ни (сайта):

Настройките за уеб сайт конфигурацията се съхраняват във в XML файл, т.нар:

web.config, който се намира в главната папка на уеб сайта. Web Site Administration Tool

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

Web.config файла.Ако първия път в които използвате

WSAT за администриране на вашия сайт ,ако не съществува Web.Config файла то Web

Site Administration Tool , го създава.WSAT също така създава и база данни във

24

App_Data папката с уеб сайта ,за да съхрани данните за услугите на приложението

,като „membership” или информация за ролите.Като цяло промените правени в WSAT

,веднага се отразяват .Нека разгледаме таба Security от WSAT :

Фиг.8: таба Security от WSAT:

ASP.NET използва този таб, за да раздели автоматично нивото на достъп на отделните

акаунти на потребителите , съответно на роли ,към които акаунтите на потребителите

принадлежат(оторизация). Intranet уеб сайтовете използват Windows авдентикация

,където потребителите се идентифицират по техните данни от входа на Windows logon-

а.

5. Основни методи свързани със сигурността на уеб приложението

.Ръчно и автоматично(wizard) конфигуриране на приложението

,касаещо сигурността му.(MSDN Съвети).

5.1 Основни стъпки за адекватната защитa на Forms-Based

автентикацията :

5.1.1 Използвайте “membership” доставчиците , вместо обичайната

авдентикация.

25

Основната функция на “membership” доставчиците е управлението на данните,

регистрираните на сайта потребители, както и за предоставяне на методи за създаване

на потребители, изтриване на потребители, проверка на потребителски имена и пароли,

промяна на паролите, и така нататък. В Microsoft. NET Framework System.Web.Security

пространство включва класа на име MembershipUser, който определя основните

атрибути на “membership” потребителя и който “membership” доставчиците използват

за да представят отделните потребители .Също така се включва абстрактен клас

наречен MembershipProvider ,който дефинира основните атрибути и методи на

„membership” доставчика .Кода на класа е представен във следния линк:

http://msdn.microsoft.com/en-us/library/aa478949.aspx

Фиг.9 “membership” доставчиците:

5.1.2 Използвайте на SSL за защита на пълномощията и

"бисквитките" за авдентификация.

SSL (Secure Sockets Layer):

- HTTP обменът е в некодиран вид и може да се прочете по пътя.

- Особен проблем са имена/пароли,номера на карти и др. Попълвани във форми.

- SSL може да преодолее тези проблеми.

- необходим е сертификат.

SSL сертификати.

- могат да се купят от специализирани организации (напр. VeriSign).

26

- могат да се издадат чрез Certificate Services, но ще дава предупреждение, че

може източникът да не е надежден.

Настройка на SSL:

Фиг.10 :Настойките на сайта с таба за SSL:

Фиг.11 : SSL сертификаитте:

5.1.3 Ако не можете да използвате SSL, помислете за намаляване на

времетраенето на сесията.

- ако не можем да използваме SSL ,то трябва да намалим живота на „бисквитката",за да

намалим по този начин времето , за което хакера може да използва заловената „

бисквитка „ ,за да предоставаи достъп до нашето приложение с подменената

идентичност. По подразбиране времето за удостоверяване на една бисквитка е 30

минути. Помислете за намаляване на това до 10 минути, както е показано тук.

27

<forms

timeout="00:10:00"

slidingExpiration="true"... />

Тук slidingExpiration="true"... осигурява това ,че крайния срок се рестартира след всяка

уеб заявка.

5.1.4 Проверка на потребителска информация за вход.

Проверете за вярност потребителските входни данни за тип дължина ,формат и обхват

.Използвайте регулярни изрази ,за да ограничите входните данни в сървъра.Ако не

използвате SqlMembershipProvider ,а трябва да разработите собствени заявки за достъп

до базата данни на потребителя,не използвайте потребителските детайли при входа ,за

да създадете динамично SQL statements ,защото това може да направи кода ви

податлив на SQL инжекции .Вместо това валидирайте входните данни и използвайте

параметрични stored процедури.

5.1.5 Да не се съхраняват паролите директно в базите данни на

потребителя .

Да не се съхраняват паролите на потребителите ,в прав текст или дори в криптиран

формат.

Вместо това ,съхранявайте паролите хеширани със „сол”(допълнителен низ ,криптиран

заедно с паролата) ,добър такъв алогритъм е SHA256,но преди това да разберем ,какво

представлява въпросното хеширане :

5.1.6 Криптиране на пароли за потребителска оторизация,хеширане:

Хеширането се използва, за да се съпостави на данни с произволна дължина, число

(хеш, хеш-стойност, хеш-код), което е тяхна уникална необратима репрезентация. Това

означава, че имайки хеш-стойността не можем да възстановим първоначалните данни и

хеширайки едни и същи данни всеки път ще получаваме един и същи хеш.

Фиг.12 : Процеса: Хеширане

1 Уникалността на хеш-стойността означава, че за различни данни ще получаваме

различни хеш стойности. Тази уникалност обаче не е абсолютна, тъй като в общия

случай входните данни имат по-голяма дължина от хеш стойността и следователно

поне два различни набора от входни данни ще имат един и същи хеш (според принципа

на Дирихле за чекмеджетата). Когато това се случи, казваме, че има колизия.

28

2 Някой от най-известните алгоритми за хеширане са MD5, SHA1, SHA256, SHA384 и

SHA512. При тях е доказано, че колизии съществуват, но е много трудно да се

постигнат на практика. Тези алгоритми се наричат криптографски силни хеширащи

алгоритми. Те имат свойството, че по дадена хеш стойност е изключително трудно да

се намерят данни, от които тя се получава.

Доста често разработчиците на софтуер си задават въпроса: „В какъв вид е най-добре

да бъде запазена една парола в базата с данни?“ Повечето програмисти се спират на

варианта с най-обикновенно MD5 криптиране, което между другото върши работа, но

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

качеството, това не е достатъчно. В много от случаите MD5 хешовете могат лесно да

бъдат разбити с помощтта на големи бази данни от MD5 хешове.Дължината е обаче 128

бита на MD5 хешовете .Съшествува като stored procedure във Microsoft SQL Server

2003 и имплементира оптимизиран MD5 хеш алгоритъм..Този сорс е компилиран и

тестван на Microsoft Visual C++ 6.0 and .NET 2003.

1.Екстрактваме DLLфайла: xp_md5.dll и го слагаме (примерно) в : C:\Program

Files\Microsoft SQL Server\MSSQL\Binn.Прекомпилирания DLL е в рилийз

директорията ,където е сорс кода на проекта.

2.Създаваме Extended Stored Procedure ,наречена:Xp_md5 в "master" база данните.

Right-click "Extended Stored Procedures" под базите данни в сървър мениджъра и

кликваме "New Extended Stored Procedure..." Въвеждаме xp_md5 в „име” ,а за пътя

въвеждаме пълния път до xp_md5.dll.( USE master;

EXEC sp_addextendedproc 'xp_md5', 'xp_md5.dll')

3.Създаваме функия(user-defined) във всяка база в която смятаме да използваме MD5

процедурата.Дясно копче:” "User Defined Functions" под съответната подходяща база

данни .и кликваме на nd click "New User Defined Function...". Вкарваме следния код :

CREATE FUNCTION [dbo].[fn_md5] (@data TEXT)

RETURNS CHAR(32) AS

BEGIN

DECLARE @hash CHAR(32)

EXEC master.dbo.xp_md5 @data, -1, @hash OUTPUT

RETURN @hash

END

4.(по избор) може да създадем други потребителско ориентирани функции за

извеждане на дължината на данните (за субстрингове , двоични или типове с фиксирана

дължина)

Използване :

FN_MD5

Потребителско ориентираните функции ,могат да бъдат използвани по следния начин:

//Проста SQL заявка:

// fn_md5() се опитва автоматично да сметне дължината на вкарания стринг:

SELECT dbo.fn_md5('Hello world!');

29

// fn_md5x() взема аргумент с избираема дължина за substrings, fixed-width types, etc.

,затова слагаме и дължината на стринга )

SELECT dbo.fn_md5x('Hello world!', 12);

ЕТО И ИЗХОДНИТЕ ДАННИ (криптирането на стринга” Hello World”).

86fb269d190d2c85f6e0468ceca42a20

Софтуерните продукти използват и по-сложни варианти за криптиране на паролите.

Разбира се, не трябва да се прекалява със сигурността, защото това би могло да окаже

влияние на цялостната съвместимост на продукта.

Добро решение на проблема е паролите да се пазят в базата с данни в криптиран вид,

заедно с добавена сол. Солта представлява определен набор от символи, които се

добавят към паролата, след което паролата бива криптирана заедно с тях. По този

начин възможността да бъде декриптирана паролата с използване на хакерски бази

данни се свежда до нулева. Единствения вариант за нейното разбиване е да бъде

направена BruteForce атака (брутална сила), когато всички възможни комбинации се

проверяват и се прави сравнение между паролата в базата и генерирания хеш. Но в този

случай хакерите трябва да знаят солта и хеша, също така паролата трябва да бъде

примитивна.

Да си представим в момента цялостна система за оторизиране на потребители, без

значение на какъв език за програмиране е писана тя (PHP, Python, Java). След

регистрация, към паролата на потребителя се добавя случаен набор от символи, които

се записват в отделно поле в таблицата. Паролата и солта се запазват заедно в

криптиран вид (MD5, SHA1 и т. н.) За да бъде проверено, дали въведената парола от

даден потребител съответства на тази, създадена при регистрацията, скрипта прави

следната проверка. Взима от полета на таблицата солта, добавя я към въведената

парола, криптира двете и сравнява двата хеша. Системата работи, и в същото време е

достатъчно сигурна.

5.1.7 Прилагане на силни пароли.

Уверете се ,че паролите са сложни достатъчно, за да попречат назлонамерените

потребители да се разпознаят паролите на другите потребители и да се предотвратят по

този начин „dictionary” атаките срещу потребителската база данни .По начало ASP.NET

membership провайдерите ,прилагат силни пароли .За пример Например,

SqlMembershipProvider и ActiveDirectoryMembership доставчиците гарантират, че

паролите са най-малко седем знака с най-малко на дължина един не буквен

знак.Пример за такава парола е примерно:P@SSW0RD , където имаме в низа 6 букви

,една цифра и един знак.Трябва да сме сигурни ,че конфигурацията на membership

провайдера налага пароли с най-малко тази защитеност. За да конфигурираме една

прецизна сложност на паролата ,наложена от провайдера,то трябва да настроим

следните атрибути:

30

passwordStrengthRegularExpression. По начало е "".

minRequiredPasswordLength. По начало е 7.

minRequiredNonalphanumericCharacters. По начало е 1.

5.1.8 Защита на достъпа до главния сървър за данните.

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

предоставя съответния.Ограничете достъпа до сървъра за другите.Уверете се че

стринга съдържащ информация за връзката с сървъра е криптиран .

Ограничаване на правата:

- да не се дава на никой потребител повече права,

отколкото реално са му нужни.

- да не се осъществява достъп от приложение до БД/СУБД с

администраторски потребител/права, а с потребител с ограничени права.

-Не задържайте „бисквитките” за авдентикация:

Този вид „бисквитки” се съхраняват в профила на потребителя и могат да бъдат

откраднати, ако някой хакер получава физически достъп до компютъра на потребителя.

За да се уверим ,че „бисквитката „ няма да се задържи , задаваме на

DisplayRememberMe свойството от Login контрола да бъде „false”.Ако не използвате

Login контроли,можете да създадете ,неустойчива(временна) бисквитка ,като се

извикат един от двата метода RedirectFromLoginPage или SetAuthCookie от класа :

FormsAuthentication :

public void Login_Click(object sender, EventArgs e)

{

// Is the user valid?

if (Membership.ValidateUser(userName.Text, password.Text))

{

// Parameter two set to false indicates non-persistent cookie

FormsAuthentication.RedirectFromLoginPage(username.Text, false);

}

else

{

Status.Text = "Invalid credentials. Please try again.";

}

}

5.1.9 Ограничаване на данните за авдентикация само по HTTPS

връзките.

31

Задайте свойствата за защита на „бисквитката” за удостоверяване,за да сте сигурни ,че

браузерите изпращат „бисквитките” за удостоверяване , само през криптираните

HTTPS връзки.С използването на SSL ,вие се предпазвате от от злонамерения

нападател да залови „бисквитката „за удостоверяване и да получи достъп до вашето

приложение.Задайте своиството на бисквитката ,чрез използването на :

requireSSL="true" във <forms> елемента както е показано по долу:

<forms loginUrl="Secure\Login.aspx"

requireSSL="true" ... />

5.1.10 Помислете за разделяне на сайта ,на зони с ограничен достъп и

зони с нормален достъп.

За да избегнете изпозването на SSL в целия ви сайт ,използвайте отделна папка в която

да защитавате страниците ,които изискват достъп с пароли и

авдентикация.Конфигурирайте тази папка в IIS да изисква SSL достъп .тези страници

които поддържат анонимен достъп , може безопасно да бъдат достъпни и през HTTP

връзки.

5.1.11 Използвайте уникални „бисквитки” и пътя до тях .

Използвайте уникални имена и стойности за пътя във <forms> елемента.Чрез

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

могат да се появят когато се хостват ,множество приложения на един и същи

сървър.Например ако не изпозваме уникални имена ,възможно е потребителя ,който се

е авдентицирал в едно приложение ,да направи заявка към друго приложение ,без да

бъде пренасочен от входната страница на приложението.

5.2 Как да заключим ASP.NET приложение или Уеб услуга:

5.2.1.Филтър на пакети:

ASP.NET не изисква специално внимание, когато конфигурирате мрежово оборудване

или програмите за защитна стена за порт – базираното филтриране на пакети

.Интернет Информационния Сървър (IIS),дефинира TCP портове ,които ASP.NET

използва за комуникация.По подразбиране ASP.NET използва TCP port 80 за

стандартно HTTP, и TCP port 443 за HTTP със SSL криптиране.

Редица портове остават незащитени (отворени) по подразбиране.

Те са добре известни на хакерите и могат да се атакуват.

32

5.2.2 Защитни стени в приложния слой:

Защитните стени в приложния слой ,като Microsoft Internet Security и Acceleration

Server,могат да анализират подробностите относно идващите Уеб заявки ,включвайки

HTTP командата ,която е издадена и файлът ,който се изисква.Взависимост от

приложението различни типове могат да бъдат избирани . ASP.NET клиента може

законно да изисква файлове ,които имат следните разширения ,взависимост от

функционалността на приложението :

* .ashx* .aspx * .asmx* .rem* .soap

Файловете ,които са включени в ASP.NET приложение могат да използват

следните разширения :

.ascx .asmx .axd .config .cs .csproj .dll .licx .pdb .rem .asax

.soap .vb .vbproj .vsdisco .webinfo .xsd .xsx .resources .resx

Но,защитната стена не бива да пропуска всичките тези разширения до крайните

потребители.Тя трябв да бъде конфигурирана да ограничава типовете от HTTP

Команди ,които могат да бъдат потвърдени в ASP.NET приложението.Конкретно

,трябва да се потвърждават само GET, HEAD, и POST командите,към крайните

потребители .Разработчиците трябва да получават достъп и до други HTTP команди.

5.2.3 NTFS Сигурност:

Можем ефективно да намалим риска от това лична информация да бъде изложена на

риск от атаки.За да направим това ,трябва да ограничим NTFS разрешенията за

файловете.По принцип ASP.NET приложенията работят в контекста на ASPNET

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

разрешения за ASPNET потребителския акаунт.

5.2.4 Конфигуриране URLScan:

URLScan е Microsoft ISAPI филтър ,който е проектиран да осигурява по – подробно

фотриране на входящите уеб заявки от IIS 5.0 сървърите. URLScan осигурява много

възможности за защитната стена на приложния слой и може да филтрира заявки

базирани на име на файла ,пътя и типа заявка.

5.2.5 Конфигуриране на сигурността в SQL Server –а:

Много ASP.NET приложения комуникират с Microsoft SQL Server базите данни.Общо

взето всички злонамерени атаки ,насочени към базите данни ,използват ASP.NET

приложението, като се възползватот от разрешенията ,които администратора на базите

данни ,предоставя на приложението.За да създадете най доброто ниво на защита против

такива атаки, конфигурурайте позволенията към базите данни ,за да ограничите

разрешенията ,които давате към ASP.NET.Разрешавайте само минималните права ,с

които прилжението се нуждае за функционира.Например ограничете ASP.NET да

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

приложението трябва да има достъп .Когато приложението не ъпдейтва директно

33

таблица,не разрешавайте на ASP.NET да представя актуализации.За повече сигурност

,конфигурирайте .подходящи разрешения за ASPNET акаунта на потребителя.

5.2.6 Сигурност при достъпа до данните: (как да се защитим ;насоки)

При изграждането на частта за достъп до данни на вашето приложение, имайте

предвид следните насоки:

- Шифроване на низа за връзката с базата данни .( connection string);

- Използвайте най-малко привилегировани акаунти за достъп до база данни.

- Използвайте Windows удостоверяване когато е възможно.

- Ако използвате Windows удостоверяване, използвайте надеждна услуга.

- Ако не може да използвате домеин акаунт ,използвайте mirrored акаунти.

- При използване на SQL удостоверяване, използвайте силни пароли.

- При използване на SQL идентификация, препоръчително е да правите защита през

мрежата.

- При използване на SQL идентификация, трябва да се правят защити и в

конфигурационните файлове .

- Валидирайте не проверени входни данни ,преминали чрез методите за достъп до

данните.

- Когато правите SQL заявки ,използвайте безопасни SQL параметри.

- Избягвайте динамични заявки които приемат входния поток данни.

5.3 Вход /Потвърждаване на данните:

5.3.1 Да не се разчита само на ASP.NET молбата за валидиране .

ASP.NET съдържа форма за проверка на входни данни ,която е включена по

подразбиране. validateRequest атрибута е сложен на true в конфигурационния файл

.трябва да се уверим ,че той е пуснат за всички страници ,освен за тези от които

приемаме набор от HTML елементи .Ако се налага да го махнем ,то трябва да

променим ValidateRequest атрибута на false .

5.3.2 Проверка Вход за дължина, обхват, формат и вид .

Не се доверявайте на входните данни. Хакер пренасящ опасни входни данни ,можа да

опита да направи SQL инжекция, крос-сайт скриптове, както и други атаки за

проникване в системата , които целят да използват уязвимостта в приложението.

Трябва да се направи проверка за постоянния поток от безвредни входни данни, като

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

приемат входни данни през сървърните контроли ,се използват ASP.NET контролите за

валидиране на входни стрингове ,като RegularExpressionValidator, RangeValidator, и

34

CustomValidator ,като пример.Ако не използваме сървърни контроли ,може да

използваме регулярни изрази или класа Regex ,може да проверяваме обхвата на

данните ,като ги преобразуваме в типове : integer или double и после да приложим

проверка за обхвата.

5.3.3 Проверка на данни от всички източници, като QueryString,

бисквитки и HTML контроли.

Повечето уеб приложения приемат информация от различни източници, включително

HTML контроли , сървърни контроли, низове с заявки , и бисквитки.Валидираите

входа от всички тези източници за да предотвратите атаки ,свързани с проникване от

хакери.Използвайте регулярни изрази ,за да си помогнете да удостоверите входните

данни.Следващия пример ,ще ни насочи ,как да изпозваме класа класа Regex:

using System.Text.RegularExpressions ;

// Instance method:

Regex reg = new Regex(@"^[a-zA-Z'.\s]{1,40}$");

Response.Write(reg.IsMatch(Request.QueryString["Name"]));

// Static method:

if (!Regex.IsMatch(Request.QueryString["Name"],@"^[a-zA-Z'.\s]{1,40}$"))

{

// Name does not match expression

}

Ако не можете да кеширате регулярения израз за честа употреба, трябва да използвате

по-статичния метод IsMatch.

5.3.4 Не разчитайте на проверка от страна на клиента:

Не разчитайте на проверка от страна на клиента, защото може лесно да бъде

заобиколено.Например, злонамерен потребител може да забрани от страна на клиента

скрипт проверките, като изключи JavaScript.Използвайте клиентската проверка ,в

добавка на проверката от страна на сървъра ,за да се намалят обиколките до сървъра и

да се подобри работата на потребителя.

5.3.5_Избягвайте име на файла осигурен от потребителя и въвеждане

на пътя :

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

потребителя или въвеждане на пътя до проекта. Ако не направите това ,резултата може

да доведе до достъп на хакерите към нашите произволни файлове и ресурси .Ако все

пак приложението трябва да приеме входни имена на файлове и път до файла или до

35

URL-то ,то трябва да се удостовери ,че пътя е в коректния формат и сочи към валидно

място с контектста на нашето приложение .

5.3.6 Имената на файловете

Уверете се ,че пътеката на файла се свързва само с файловете вътре във вашата

витруална директроия на приложението,ако това е възможно.Когато проверите имената

на файловете ,вземете пълното име на файла ,чрез използването на System.IO.Path:

GetFullPath метода.

5.3.7_Пътеки на файловете:

Ако използвате MapPath да монтирате виртуална путека към физическа пътека към

сървъра ,използвайте пренатоварения Request.MapPath метод да приеме двоични (1 или

0 ) параметри ,така ,че да можеш дапредотвратиш появата на cross-

application.Следващия код показва този похват:

try

{

string mappedPath = Request.MapPath( inputPath.Text,

Request.ApplicationPath, false);

}

catch (HttpException)

{

// Cross-application mapping attempted

}

Последните false параметри предотвратяват кръстосаните приложения.

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

да пътува извън йерархията на витруалната директория на приложението . Всеки опит

да се направи това води до генериране на изключение от тип HttpException

5.3.8.Не връщайте обратно непроверен вход:

Не връщайте входни данни обратно на потребителя без да си го потвърдил или

кодирал данните.Връщайки входните данни оратно към потребителя прави твоята

апликация ,податлива на злонамерени атаки ,като cross-site scripting.

5.3.9Ако трябва да изпратите непроверени данни ,кодирайте изхода:

36

Ако пишете изходни данни ,които вкючват ,потребителски входни данни или данни от

споделена база данни или локален файл,които не са проверени ,не седоверявайте а ги

кодирайте.Криптирането на данните , гарантира, че то се третира като буквален текст, а

не като скрипт. Можете да използвате метода HttpUtility.HtmlEncode. Също така, ако

пишете URL адреси, които могат да съдържат опасни знаци, тъй като са изградени от

входни данни или данни от обща база данни, използвайте HttpUtilty.UrlEncode да ги

направи безопасни.

Бележка : Уверете се ,че датата е криптирана ,преди тя да се върне на

клиента.

5.4 Други препоръки за сигурността : (автоматизирани настройки):

5.4.1 Избор на операционна система.

- да се прецени мощ/сигурност/цена - Windows XP Pro, Windows2000, Windows

2000 Server,Windows Server 2003.

- Да се използва NTFS.

5.4.2 Предназначение на сървъра.

- Какво ще прави сървърът - уеб-сървър, СУБД, поща, файлове и др.

- Повече функции = повече потенциални проблеми по сигурността.

- В зависимост от случая , да се направи подходящо разпределение между

няколко сървъра.

5.4.3 Премахване на услуги:

- Много услуги са инсталирани, но не се използват.

- Някои услуги се използват вътре в организацията, но не е блокиран

външния достъп.

- Да не се инсталират и/или да се премахнат неизползвани услуги

(напр. FTP, SMTP).

37

Фиг.13 : Премахване на някой услуги,които не ни вършат работа.

5.4.4 Конфигуриране на сигурността:

Фиг.14 : Конфигуриране на сигурността:

5.4.5 Примерите:

38

- редица примери (вкл. от самото Visual Studio .NET) не са

достатъчно обезопасени.

- да не се инсталират на компютъра, на който ще работи приложението.

5.4.6 Validation (валидация, проверка):

- да се проверява всеки вход от потребителя за коректност и наличие на евентуален

злонамерен код.

- по подразбиране ASP.NET проверява за HTML елементи и предизвиква изключение.

5.4.7 Забрана за автоматична валидация:

Не е препоръчително, но може да се наложи.За целия проект (Web.config):

<pages validateRequest="false"/>

За отделни страници:

<% @ Page ValidateRequest="false" %>

5.4.8 Patching (кръпки, ъпдейти):

- операционната система, уеб-сървърът, .NET framework, СУБД трябва да са

винаги актуализирани с последните ъпдейти.

- може да се използва Microsoft Baseline Security Analyzer (MBSA).

5.4.9 MBSA – сканиране:

39

Фиг.15 : MBSA – сканиране::

MBSA – резултати:

Фиг.16 : MBSA – резултати:

40

5.4.10 Logging:

Фиг.17 : Logging::