Защита при създаване на Dot net приложения в интернет

Защита при създаване на dotNET приложения в Интернет

Реферат на тема : Защита при създаване на

dotNet приложения в Интернет

Разработил: Проверил:

Моника Тошкова Петрова Доц. Д-р Стефан Дражев

специалност „Информатика“ Ас. Радка Начева

5 курс, 61 група

фак. номер: 1182

Варна 2014


2/20

Моника Петрова ф.номер: 11824 спец.“Информатика“

Съдържание:

Какво е .NET приложение в Интернет? ____________________________ 3

Видове заплахи за ASP.NET приложенията _________________________ 4

Cross Site Scripting (XSS) _________________________________________ 4

SQL инжекции _________________________________________________ 5

DDoS атаки ____________________________________________________ 5

Сигурност в ASP.NET _____________________________________________ 6

Автентикация _________________________________________________ 6

Авторизация __________________________________________________ 7

Видове автентикация в ASP.NET __________________________________ 7

Windows автентикация ________________________________________ 7

Basic автентикация __________________________________________ 8

Digest автентикация _________________________________________ 8

Integrated Windows автентикация ______________________________ 8

Forms автентикация __________________________________________ 10

Автентикация и авторизация чрез Forms authentication и Role-based

security – пример ___________________________________________ 11

Passport автентикация _______________________________________ 15

Сигурност на ниво сървър (IIS Security) __________________________ 15

Разглеждане файловете на сървъра ____________________________ 16

Анонимен достъп __________________________________________ 17

Криптиране на връзката чрез SSL _____________________________ 18

Сигурност чрез сесии _________________________________________ 18


3/20


Какво е .NET приложение в Интернет?

Приложенията в Интернет или както са по-известни Уеб приложенията

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

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

достъп през мрежа като Интернет или интранет. Днес уеб технологиите

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

но и напълно функционални уеб приложения, с интерфейс,

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

класическите настолни приложения, но и в много отношения ги

надминават. Накратко можем да дефинираме термина уеб приложение по

следния начин: Уеб приложение е софтуер, който работи в браузъра.

Необходимо е да изясним какво означава .NET. Microsoft .NET

Framework е платформа, създадена от Microsoft, която предоставя

програмен модел, библиотека от класове (FCL, Framework Class Library) и

среда за изпълнение на написан специално за нея програмен код (CLR,

Common Language Runtime). Тя е ключов елемент от стратегията за

развитие на Microsoft, чиято цел е повечето нови приложения за Windows

да бъдат базирани на .NET Framework. Технологията за разработка на уеб

приложения базирани на .NET платформата на Microsoft се нарича

ASP.NET. Едно от предимствата на ASP.NET е повишената

производителност. Тя се постига защото създаваните с ASP.NET

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

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

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

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

програмен код.


4/20


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

но основния недостатък е нивото на защитеност на данните. Това се явява

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

действия от страна на някои потребители. Достигане на високо ниво на

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

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

следващите глави.

Видове заплахи за ASP.NET приложенията

Cross Site Scripting (XSS)

Това е атака, която използва уязвимост на приложението и „вмъква“

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

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

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

нейното съдържание. Основно XSS се използва за крадене на сесии или

куки (cookie). XSS атаките са най-общо три вида:

Директни: Атакуващият предоставя връзка или друг вид „маскиран“

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

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

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

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

добие достъп до неговата административна част. Директните атаки се

реализират най-често чрез изпращане на писма по електронната поща към

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

Статични: Атакуващият успява да вмъкне нежелания код в база

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


5/20


най-честите атаки при т.нар. социални мрежи – форуми, блогове,

дискусионни групи, и т.н.

DOM: Това са XSS атаки от т.нар. локално ниво. Обикновено се

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

предизвика директна XSS атака към жертвата.

SQL инжекции

SQL инжекциите са техника за атакуване на приложения,

използващи SQL бази данни, чрез вмъкване на злонамерени SQL команди

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

потребителя винаги трябва да бъдат валидирани от приложението преди да

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

DDoS атаки

Атаката с рапределен отказ от обслужване (DDOS) може да бъде

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

изключи корпоративните системи. Хакерите извършват DDoS атака, като

експлоатират пролуки и уязвимости в компютърната система (често уеб

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

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

идентифицират и комуникират с другите системи за по нататъшно

компрометиране. След като нарушителят е поел контрол над множество

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

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

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

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

от компрометираните системи, ще причини спиране на системата цел и

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


6/20


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

организацият време и пари.

Съществуват още множество начини за заплаха на уеб

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

на сигурността при изграждането да ASP.NET приложенията.

Сигурност в ASP.NET

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

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

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

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

на сигурност.

Сигурността в ASP.NET се основава на цялостната система за сигур-

ност в .NET и в частност на модела, базиран на роли (Role-Based Security).

ASP.NET предлага модели за автентикация (authentication) и авторизация

(authorization), които заедно с предоставените услуги от уеб сървъра (IIS)

изграждат цялостната инфраструктура за сигурността в ASP.NET.

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

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

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

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

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

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

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

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


7/20


Авторизация

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

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

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

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

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

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

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

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

Видове автентикация в ASP.NET

Както вече споменахме, в ASP.NET има три вида автентикация: windows,

forms и passport (всъщност са четири, но четвъртият е none – никаква).

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

недостатъци.

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

Windows автентикацията разчита на самата операционна система да пре-

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

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

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

трябва да въведе име и парола:

Така въведените данни се проверяват за

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

или на домейна, в който той се намира. Ако са

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


8/20


автентикиран.

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

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

следните: basic, digest и integrated.

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

Това е най-простият метод за автентикация и най-

непрепоръчителният, защото паролата се предава в чист вид в HTTP

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

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

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

Подобна е на basic автентикацията с едно единствено предимство –

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

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

достъпът до него трябва да е ограничен.

Integrated Windows автентикация

Това е най-сигурният метод за автентикация в Windows среда. При

него не се предава никаква конфиденциална информация (няма диалогов

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

текущо влезлия (logged) потребител в операционната система, от която

идва заявката. Естествено сигурността и удобството имат своята цена –

тази възможност се поддържа само от Internet Explorer (уеб сървъра и брау-

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

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

е проблем, ако има защитна стена (firewall) в мрежата.


9/20


След като разгледахме всяка една от възможностите за Windows автен-

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

За начало указваме да се използва Windows автентикация в конфигура-

ционния файл на приложението Web.config:

<authentication mode="Windows" />

След това отваряме конфигурационната конзола на IIS и с десен бутон

върху нашия проект избираме Properties. От появилия се прозорец

избираме етикета Directory Security и натискаме бутона Edit, който се

намира в първата секция: Anonymous access and authentication control

(вж. фигурата). След това имаме възможност да изберем необходимия ни

метод – в случая сме избрали Integrated Windows автентикацията.


10/20


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

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

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

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

ще се използва в Интернет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

потребителите е силно динамичен. Единственото неудобство е, че разчита

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

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


11/20


Автентикация и авторизация чрез Forms authentication и Role-based

security – пример

В следващия пример ще разгледаме как може да използваме Forms автен-

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

Forms автентикация във файла Web.config:

<authentication mode="Forms" > <forms loginUrl="Login.aspx" /> </authentication>

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

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

тикация, потребителят ще бъде пренасочен към Login.aspx, където ще

може да се автентикира. Другата настройка, която трябва да направим в

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

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

уеб форми под директорията Admin да изискват автентикирани потребите-

ли:

<configuration> <system.web> ... </system.web> <location path="Admin"> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </location> </configuration>

Същото може да се постигне, като поставим Web.config в директорията

Admin със следното съдържание:

<configuration> <system.web> <authorization>


12/20


<deny users="?" /> </authorization> </system.web> </configuration>

Нека се спрем малко по-подробно на секцията authorization и нейните

дъщерни елементи. Елементът deny отказва достъпа до този ресурс на

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

атрибутът users, а за роли – roles (ако разрешените са повече от една, те са

разделени със запетая). Аналогично има елемент allow, който разрешава

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

* (всички потребители) и ? (потребителите, които не са автентикирани).

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

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

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

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

поискания ресурс.

Сега ще разгледаме как ще изглежда нашата форма за влизане в системата.

Ето съществената част от Login.aspx файла:

<form id="LoginForm" method="post" runat="server"> <table border="0" cellSpacing="2" cellPadding="2"> <tr> <td>Username :</td> <td> <asp:TextBox id="TextBoxUsername" runat="server" /> </td> </tr> <tr> <td>Password :</td> <td> <asp:TextBox id="TextBoxPassword" runat="server" TextMode="Password" /> </td> </tr> <tr> <td colspan="2"> <asp:Button id="ButtonLogin" runat="server" Text="Login" />


13/20


</td> </tr> <tr> <td colspan="2"> <asp:Label id="LabelErrorMessage" runat="server" /> </td> </tr> </table> </form>

Ето и как ще изглежда формата в клиентския браузър:

Сега ще разгледаме кода, който извършва автентикацията. Методът, който

обработва събитието Click на бутона ButtonLogin, е в code-behind файла

на формата Login.aspx:

private void ButtonLogin_Click(object sender, EventArgs e) { if (TextBoxUsername.Text == TextBoxPassword.Text) { FormsAuthentication.RedirectFromLoginPage( TextBoxUsername.Text, false ); } else { LabelErrorMessage.Text = "Invalid login!"; } }

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

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

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

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

извикаме статичния метод RedirectFromLoginPage(…) на класа


14/20


FormsAuthentication. Той приема два параметъра: потребителското име,

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

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

се конфигурира в Web.config). Вторият параметър служи да се избегне

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

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

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

използваме друг статичен метода SetAuthCookie(…), който само изпраща

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

FormsAuthentication е HashPasswordForStoringInConfigFile(…). Той

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

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

След като проследихме как става автентикацията, нека да разгледаме как

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

код, който трябва да напишем за целта, е в 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 се извиква, когато даден

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

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


15/20


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

случая Microsoft).

Сигурност на ниво сървър (IIS Security)

Ще разгледаме какво ни предоставя IIS сървъра за осигуряване на

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

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

ресурси, които се намират на сървъра. Поисканият ресурс може да не

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


16/20


Разглеждане файловете на сървъра

Стандартно IIS разрешава достъпа само до определени ресурси (*.aspx,

*.html, *.jpg и др.), останалите файлове не се обслужват (напр. Web.config,

*.cs и др.).

Ако е необходимо отдалечено разглеждане на файловете на приложението,

може да го разрешим, като маркираме настройката Directory Browsing,

намираща се в менюто Properties, щраквайки с десен бутон върху уеб при-

ложението в потребителския интерфейс на IIS.

На фигурата по-долу е показан диалогът за настройка на "Directory

Browsing" опцията.


17/20


Анонимен достъп

Поискването на ресурс от файловата система на уеб сървъра трябва да се

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

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

идентифицира като анонимна (стига да не е направена чрез Internet

Explorer, чийто потребител е в мрежата на сървъра) и се асоциира със

служебния потребител IUSR_machinename, където machinename е името

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

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

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

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

Properties.


18/20


Този път трябва да изберем Directory Security и щракаме върху бутона

Edit, който се намира в първата секция: Anonymous access and

authentication control. Не трябва да се дават по-големи права от

необходимите за достъп на акаунта IUSR_machinename.

Криптиране на връзката чрез SSL

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

за целта се използва най-разпространеният стандарт Secure Sockets Layer

(SSL). Стандартно браузърът и сървърът комуникират като си пращат

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

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

комуникацията между тях. Дори и недоброжелател да прихване

предаваната информация, той няма да е в състояние да ги декриптира. За

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

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

органи за това (Certification Authorities). Стандартно SSL комуникацията

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

започва с https://.

Сигурност чрез сесии

Сигурността чрез сесии е един значително удобен за прилагане

метод. При него автентикацията на потребителя не става при всяко

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

метод (например Login()), отговарящ точно за това. Той проверява дали

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

ASP.NET сесията (HttpSessionState обекта) по някакъв начин, например

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

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


19/20


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

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

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

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

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

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

При автоматично управление на сесията е много по-трудно да се реализира

Challenge/Response схемата за автентикация, която защитава паролата на

клиента от "подслушване по пътя".

За заключение е необходимо да отбележим, че техниките за защита

на ASP.NET приложения в Интернет трябва да продължават да се развиват

и усървършенстват. Само по този начин ще успяват да устояват на атаките

от злонамерени лица.


20/20


Използвана литература :

1. Статия за уеб приложения - http://edge-soft.com

2. Как да защитим уеб приложенията - http://review.sagabg.net/kak-da-

zashitim-ueb-prilozheniyata-predotvratyavan.html

3. ASP.NET - http://en.wikipedia.org/wiki/ASP.NET

4. Уеб приложение - http://bg.wikipedia.org/wiki

5. „Програмиране за .net Framework” том 2 , Светлин Наков и колектив

-http://www.devbg.org/dotnetbook/Nakov-Programming-.NET-

Framework-Book-Volume-2-ver-1.03.html

М.Петрова

Защита при създаване на Dot net приложения в интернет

Internet

Transcript of Защита при създаване на Dot net приложения в интернет