DotNet Security, Dobrin Blagoev
Upcoming SlideShare
Loading in...5
×
 

DotNet Security, Dobrin Blagoev

on

  • 2,276 views

Dot Net Security

Dot Net Security

Statistics

Views

Total Views
2,276
Views on SlideShare
2,273
Embed Views
3

Actions

Likes
0
Downloads
22
Comments
0

2 Embeds 3

https://www.coursesites.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DotNet Security, Dobrin Blagoev DotNet Security, Dobrin Blagoev Document Transcript

  • Икономически университет – Варна Разработил : Добрин Благоев , фак № 9381 , 51 група , специалност :”Информатика”1
  • СЪДЪРЖАНИЕ:1.Какво е ASP.NET? ________________________________________________________ 6 1.1Как работи ASP.NET сигуността? ____________________________________________ 72. Типове заплахи : ________________________________________________________ 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 адрес 163.Авдентикация в ASP.NET : ______________________________________________ 16 3.1 Windows-Based автентикация: ______________________________________________ 17 3.1.1 Impersonation (въплъщаване) _____________________________________________ 172
  • 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 код: _________________________________________ 214 Оторизация в ASP.NET: _________________________________________________ 22 4.2 NTFS/ACL – конфигуриране: ________________________________________________ 23 4.3 URL/директория – конфигуриране: __________________________________________ 23 4.4 WSAT (Web Site Administration Tool): _________________________________________ 235. Основни методи свързани със сигурността на уеб приложението .Ръчно иавтоматично(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 Защита на достъпа до главния сървър за данните. _________________________ 303
  • 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 Примерите: ___________________________________________________________ 374
  • 5.4.6 Validation (валидация, проверка): _________________________________________ 38 5.4.7 Забрана за автоматична валидация: _____________________________________ 38 5.4.8 Patching (кръпки, ъпдейти): _____________________________________________ 38 5.4.9 MBSA – сканиране: _____________________________________________________ 38 5.4.10 Logging: ______________________________________________________________ 405
  • 1.Какво е ASP.NET?ASP.NET представлява технология за разработка , на мощни web приложения базиранина .NET платформата на Майкрософт, предлагайки някои съществени предимства всравнение с предишните модели за разработка на web приложения.Характерни черти на ASP.NET :Повишена производителност – създаваните с ASP.NET приложения представляват код,който се изпълнява на уеб сървър. За разлика от предшестващите го технологии,ASP.NET е в състояние да се възползва от предимствата на ранно свързване, just-in-timeкомпилирането, оптимизация на кеширане (на различни нива) и др. По този начинполучавате висока производителност преди да сте написали и ред програмен код.Фиг.1: Представяне на логин формата и връзкара с MEMBERSHIPдоставчика.6
  • 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 инжекциите и какви са вариантите те да бъдат затворени.7
  • 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 ServerobjConn.Open(strConnectString) Execute the commandstrCmd = "select title, description from books where author_name = " & strAuthor &""Set objCommand.ActiveConnection = objConnobjCommand.CommandText = strCmdobjCommand.CommandType = adCmdTextSet objRS = objCommand.Execute() Process the resultset Close the objectsАко обърнете внимание на кода, името на автора се чете от GET параметър (чрезRequest.QueryString) и след това се използва пряко в изграждането на изявление SQL(sqlCmd), без да се проверява. Ако името на автора е някои валиден низ като Майкълслед заявката връща книга с автор Майкъл. Но какво става, ако крайния потребителвъведе името на автора като: Michael; drop table books; ?? В този случай последнатакоманда SQL става: select title, description from books whereauthor_name=Michael;drop table books . Това не само избира книги с автор Майкъл,но и смъква таблица с име " книги”. Проблемът тук е, че разработчикът просто приема,8
  • че на входа ще бъде низ без единични кавички, но никога не е валидирал Входният низза това. Всъщност този код не работи и ако името на автора е нещо като ОНийл.Най-добрият начин за решаване на този проблем , е използването на параметризиранизаявки. В предишния пример, се предполага, че максималната дължина на името наавтора на базата данни е 50. Ще „закърпим” кода в по-долу показания вариант: Execute the commandstrCmd = "select title, description from books where author_name = ?"Set objCommand.ActiveConnection = objConnobjCommand.CommandText = strCmdobjCommand.CommandType = adCmdTextSet param1 = objCommand.CreateParameter ("author", adWChar, adParamInput, 50)param1.value = strAuthorobjCommand.Parameters.Append param1Set objRS = objCommand.Execute() Process the resultset Close the objects2.2 Използване на лесни за налучкване пароли или използване на една исъща парола за login на различни места.2.2.1 Пароли:Доста често лесните пароли са основната причина за това, акаунтите да бъдатразбивани. Хакерите могат да използват специални речници или така наречените bruteforce (брутална сила) атаки за успешното пробиване на вашата парола. Какво е най-лесното и правилно решение? Да използвате по-силни пароли разбира се… Основномясто, на което трябва да акцентирате са вашите имейли, защото обикновенно следтова хакерите могат да получат достъп до почти всички ваши услуги.Често пробиви в приложенията стават поради : - често недоглеждана област на защитата. - слаби пароли. - липсващи пароли. - пароли в текстови файлове или в други файлове, поставени на уеб сървъра.2.2.2 слабите пароли :- Имена на места.- Дати (рождени, годишнини) .- Думи от речника.- Кратки (под 8 символа).- Само букви или само числа.2.2.3 Празни пароли.9
  • - да не се прави защита като просто се поставят страници за достъп в директория, която само определени потребители знаят или с имена, които само те знаят. - да се внимава с 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 средства, за да инжектират злонамерен код в линк,10
  • който изглежда, че заслужава доверие. Когато потребителят щракне върху линка,вграденото програмиране се включва и се изпълнява на компютъра на потребителя,което предоставя на хакера достъп, за да открадне чувствителна информация.Нападателите използват XSS, за да се възползват от уязвимостите на машината нажертвата и от зловредния код в трафика вмсто да атакуват самата система. Много Webсървъри генерират своите страници динамично. Например една търсачка може даизвърши търсене в своята база данни и след това да генерира страница на базата нарезултатите. Всеки сървър, който създава Web страници, в които е включенаинформация от динамично попълнени шаблони, трябва да извършва проверка за неналичие на специални символи. Ако в създаваните страници бъде включенаинформация, съдържаща специални символи, то клиентският браузър би я тълкувалкато HTML тагове или скрипт, а не като обикновен текст. Това би дало възможност наатакуващия да изпълнява избрани от него програми върху машината на клиента и то отимето на сървърът.Нападателите имат възможност да променят HTML кода, който контролира страницата,като използват уеб форми, които връщат съобщение за грешка при въвеждане на данниот потребителя. Хакерът може да вмъкне код в линка на спам съобщение или даизползва имейл измама с цел да подмами потребителя да смята, че източникът елегитимен.Например нападател може да изпрати на жертвата имейл съобщение с URL,което сочи към уеб сайт и го снабдява със скрипт за влизане, или публикува злонамеренURL в блог или сайт на социална мрежа като Facebook или Twitter. Когато потрбителятщракне върху линка, зловредният сайт, както и скриптът, заработват в браузъра му.Браузърът не знае, че скриптът е злонамерен и сляпо изпълнява програмата, която насвой ред позволява на скрипта на нападателя да получи достъп до функционалността насайта, за да открадне кукита или да извърши транзакции, представящи се за легитименпотребител.2.3.2 Проверяване на кукитата"Бисквитките" (cookies) са малки файлове, които се съхраняват временно на вашиятвърд (hard) диск и позволяват на сървъра да разпознае компютъра ви следващия път,когато посетите Интернет. Бисквитките" се използват за да се отбележи кои части отстраницата сте посетили или извършили лични настройки, така че при последващоваше посещение, тези страници могат да бъдат показвани "на готово".Кукитатапредставляват заплаха за сигурността, обаче когато тяхното съдържание може да бъдепроменяно от атакуващият. Поради тази причина приеманите кукита трябва да бъдатвнимателно преглеждани, като над тяхното съдържание биват прилагани методите закодиране и филтриране, описани по-горе. Ето един пример за манипулиране наинформацията, носена от куки.Изпращано от сървъра, кукито има следният вид: <% Response.Write("<BODY BGCOLOR="" + Request.Cookies("UserColor") + "">");%>След промяна извършена върху клиентската машина кукито придобива вида:11
  • 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 атака срещу приложението , той първо трябва да се намери вектора, където по –долу представените изисквания са верни: - Приложението е с не валидизиран вход на данните : - Приложението няма криптиран изход на данните:12
  • Фиг.2: XSS вектора на атакуващия в ThankYou.aspx страницата. Забележете ,че изходните данни в ThankYou.aspx страницата се оформят изпозвайки невалидизиран вход данни на потребителя ,и използва този вход в данните за отговор ,без предварително кодиране.Злонамерения потребител може лесно да използва този XSS вектор ,като излъже потребителя ,който гледа ThankYou.aspx страницата ,той през това време праща скрипт от този сорт: <script>alert(Xss Vector!)</script> . параметъра за името . Фиг.3 . Показваща XSS уязвимостта в ThankYou.aspx страницата.13
  • 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 ("до всички") адреса на предварително избрана ( желателноголяма ) мрежа, служеша за посредник, като адресът на изпращача им е подменен садреса на жертвата. Всяка една от машините, намиращи се в мрежата, на чиито IP14
  • 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 и т.н.15
  • 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, т.е. всеки потребител може да е в една или повече роли. Процесът на оторизация16
  • може да се извършва не само на ниво потребител, но и на ниво роля.Видове автентикация: - 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:17
  • Фиг.4 Windows-Based – login:Избор на методи за автентикация:Фиг.5. Избор на методи за автентикация:Windows-Based - Web.config:<authentication mode="Windows" />3.2 NET Passport автентикация:Този метод се базира на услугата MS Passport, която Microsoft предлага на своитеклиенти. Тази услуга всъщност представлява голямо единно хранилище на информацияза регистрирали се потребители. Информацията за тях е достъпна през уеб услуги.Идеята на тази услуга е, че потребителят влиза в системата само веднъж и след товаможе да влиза директно и в други сайтове, използващи същата автентикация.18
  • Излизането може да стане както от текущия сайт, така и от всички сайтове, в които евлязъл потребителят. Предимствата на този подход са, че се предоставя единенмеханизъм за работа с потребители (единна база от данни), както и че има високо нивона сигурност. Недостатъците са, че услугата не е безплатна, а и работата наприложението става зависимо от трета страна (в случая 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 автентикация – принцип на действие :При поискване на ресурс (страница), който е разрешен само за автентикирани19
  • потребители, клиентският браузър се пренасочва към предварително указана страница,на която ще се извърши автентикацията. При успешна автентикация към клиента сеизпраща бисквитка, която указва, че потребителят е вече автентикиран. При всякаследваща заявка бисквитката се прихваща и използва от 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>20
  • <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);elseLabel4.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);21
  • elseLabel4.Text = "Incorrect username orpassword!";4 Оторизация в ASP.NET:Оторизацията е процес на свързване на потребител с дадени права. Заоторизиран се счита потребител, който има право да работи с поисканияресурс или да извърши конкретната операция. Във веригата на сигурност-та това е следващият процес след автентикацията – след като разберемкой е потребителят, ние трябва да знаем какви са неговите права. ВASP.NET за оторизация се използва моделът Role-Based Security, т.е. всекипотребител може да е в една или повече роли. Процесът на оторизацияможе да се извършва не само на ниво потребител, но и на ниво роля.Нека да разгледаме как се извършва оторизацията чрез сигурност, базирана нароли.Оторизацията може да се извършва на ръка ,може и чрез Web Site AdministrationTool.Това е 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, което ни връща вече съхраненотоиме за потребителя в бисквитката за автентикация. След това реализи-22
  • раме логиката за задаване ролите на потребителя, който се е автентики-рал. В случая на потребителя "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 файла то WebSite Administration Tool , го създава.WSAT също така създава и база данни във23
  • 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” доставчиците , вместо обичайнатаавдентикация.24
  • Основната функция на “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).25
  • - могат да се издадат чрез Certificate Services, но ще дава предупреждение, че може източникът да не е надежден. Настройка на SSL:Фиг.10 :Настойките на сайта с таба за SSL:Фиг.11 : SSL сертификаитте: 5.1.3 Ако не можете да използвате SSL, помислете за намаляване навреметраенето на сесията.- ако не можем да използваме SSL ,то трябва да намалим живота на „бисквитката",за данамалим по този начин времето , за което хакера може да използва заловената „бисквитка „ ,за да предоставаи достъп до нашето приложение с подмененатаидентичност. По подразбиране времето за удостоверяване на една бисквитка е 30минути. Помислете за намаляване на това до 10 минути, както е показано тук.26
  • <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 Уникалността на хеш-стойността означава, че за различни данни ще получаваме различни хеш стойности. Тази уникалност обаче не е абсолютна, тъй като в общия случай входните данни имат по-голяма дължина от хеш стойността и следователно поне два различни набора от входни данни ще имат един и същи хеш (според принципа на Дирихле за чекмеджетата). Когато това се случи, казваме, че има колизия. 27
  • 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 FilesMicrosoft SQL ServerMSSQLBinn.Прекомпилирания 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!); 28
  • // 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.NETmembership провайдерите ,прилагат силни пароли .За пример Например,SqlMembershipProvider и ActiveDirectoryMembership доставчиците гарантират, чепаролите са най-малко седем знака с най-малко на дължина един не буквензнак.Пример за такава парола е примерно:P@SSW0RD , където имаме в низа 6 букви,една цифра и един знак.Трябва да сме сигурни ,че конфигурацията на membershipпровайдера налага пароли с най-малко тази защитеност. За да конфигурираме еднапрецизна сложност на паролата ,наложена от провайдера,то трябва да настроимследните атрибути:29
  •  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 връзките. 30
  • Задайте свойствата за защита на „бисквитката” за удостоверяване,за да сте сигурни ,чебраузерите изпращат „бисквитките” за удостоверяване , само през криптиранитеHTTPS връзки.С използването на SSL ,вие се предпазвате от от злонамерениянападател да залови „бисквитката „за удостоверяване и да получи достъп до вашетоприложение.Задайте своиството на бисквитката ,чрез използването на :requireSSL="true" във <forms> елемента както е показано по долу:<forms loginUrl="SecureLogin.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 криптиране.Редица портове остават незащитени (отворени) по подразбиране.Те са добре известни на хакерите и могат да се атакуват.31
  • 5.2.2 Защитни стени в приложния слой:Защитните стени в приложния слой ,като Microsoft Internet Security и AccelerationServer,могат да анализират подробностите относно идващите Уеб заявки ,включвайки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 дапрочита разрешенията само за тези изгледи ,таблици ,редове и колонки ,към коитоприложението трябва да има достъп .Когато приложението не ъпдейтва директно32
  • таблица,не разрешавайте на 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, и33
  • 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_Избягвайте име на файла осигурен от потребителя и въвеждане на пътя : Където е възможно ,избягвайте писането на код който приуема ,файл осигурен отпотребителя или въвеждане на пътя до проекта. Ако не направите това ,резултата можеда доведе до достъп на хакерите към нашите произволни файлове и ресурси .Ако всепак приложението трябва да приеме входни имена на файлове и път до файла или до34
  • 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 параметри предотвратяват кръстосаните приложения.Това означава ,че потребителя не може успешно да предостави път ,който съдържа „ ..”да пътува извън йерархията на витруалната директория на приложението . Всеки опитда се направи това води до генериране на изключение от тип HttpException5.3.8.Не връщайте обратно непроверен вход:Не връщайте входни данни обратно на потребителя без да си го потвърдил иликодирал данните.Връщайки входните данни оратно към потребителя прави твоятаапликация ,податлива на злонамерени атаки ,като cross-site scripting.5.3.9Ако трябва да изпратите непроверени данни ,кодирайте изхода:35
  • Ако пишете изходни данни ,които вкючват ,потребителски входни данни или данни отсподелена база данни или локален файл,които не са проверени ,не седоверявайте а гикодирайте.Криптирането на данните , гарантира, че то се третира като буквален текст, ане като скрипт. Можете да използвате метода 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).36
  • Фиг.13 : Премахване на някой услуги,които не ни вършат работа.5.4.4 Конфигуриране на сигурността:Фиг.14 : Конфигуриране на сигурността:5.4.5 Примерите:37
  • - редица примери (вкл. от самото 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 – сканиране: 38
  • Фиг.15 : MBSA – сканиране::MBSA – резултати:Фиг.16 : MBSA – резултати:39
  • 5.4.10 Logging:Фиг.17 : Logging::40