Разни въпроси към WEB-аджиите...

[persuader]

От: Разни въпроси към WEB-аджиите...

Прекалено голямо доверие имаш на microsoft :>

Валидирането винаги трябва да го интересува. Дори да не става въпрос за sql инжекция някой компроментиран потребител винаги може да инсертне в sql-a някакъв неприатен js който след това да обере паролите на който го интересува.

[pecix]

От: Разни въпроси към WEB-аджиите...

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

Във викито има много добри примери защо такъв вид параметри са сигурни, макар да липсва пример с .НЕТ (нещо подобно е, но според ме е доста по-изчистено):
http://en.wikipedia.org/wiki/Prepared_statement

Доп.: Примера от Java е това, за което говоря, но се ползва и при нормални заявки.

Доп. 2: Ползвам не само майкрософтски неща, зависи кой какво иска, така че имам някакъв поглед върху различните платформи. Но в темата става въпрос за .NET основно, за това споменавам по-специфични неща. А кое е по-добро и по-хубаво за дадено решение - зависи само и единствено от знанията и възможностите на програмиста

[Daniel]

Re: Разни въпроси към WEB-аджиите...

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

но масово хората ползват escape на стрингове в PHP

И не само ползват се и валидация на входните данни с проверка на съдържанието за определени символи.

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

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

[pecix]

От: Разни въпроси към WEB-аджиите...

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

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

[sparkybg]

От: Разни въпроси към WEB-аджиите...

В момента абсолютно всяко поле се тества за тип и валидност преди да иде в базата, и така и ще си остане. Даже понеже още отдавна ми писна от това на кой как му е настроен компютъра, приема числа и с точка, и със запетайка като разделител. Датите също се тестват и т.н. Това ми бяха едни от първите занимания още преди да пуснам продукта - наложих си начин на програмиране във всяка форма за въвеждане.

Тук смятам елементарната проверка да става на клиентската машина, а съществената в контролера на съответния View при post заявката. Дори и да вкарат скрипт някъде, аз не възнамерявам да оставям възможността скриптове да могат да четат и пишат в базата. Това ще става от контролерите. Паролите пък въобще не са в базата, тъй че точно тях да гепят със SQL няма как да се случи.

[Daniel]

Re: Разни въпроси към WEB-аджиите...

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

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

[sparkybg]

От: Re: Разни въпроси към WEB-аджиите...

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

Именно! JS върху клиентската машина проверява каквото може - тип на данните и прочие неща, а сървъра проверява каквото той си може - дали данните са "съвместими" със съдържанието на базата (например дали вече няма въведен такъв служител в базата данни на фирмата и т.н.), като не разчита много-много данните от проверката от JS да са коректни. JS проверката е само за да може при нормална работа да се избегнат ненужни заявки и трафик. Основното си е на сървъра.

[persuader]

От: Разни въпроси към WEB-аджиите...

Не става въпрос скриптова да четат и да пишат в базата ами някой да успее да инсертне в някое текстово поле javascript примерно описание на дейноста на фирмата - което след като бъде прегледано от друг потребител примерно администратор да направи поразия - примерно сменяне на парола email етц. Как и да е това е вече доста задълбаване в web сигурноста.

[pecix]

От: Разни въпроси към WEB-аджиите...

ASP.NET (т.е. уебската част от .нет фреймуърка) си има собствени контроли. То като си казал, че дадена контрола ще е статичен текст (ASP label или literal), той си остава просто текст, в който няма как да излезе линк или да се изпълни някакъв JS. Ще се види целия този скрипт на екрана, както и тук излиза в този форум:

...
<script type="text/javascript">
function myFunction()
{
alert("Hello! I am an alert box!");
}
</script>
...
<input type="button" onclick="myFunction()" value="Show alert box" />
...

Винаги можем да вмъкнем HTML код, вместо да ползваме разни готови неща, но тогава вината е изцяло на програмиста. Иначе валидация си има не само при SQL заявките, но и при генерирането на HTML, като така се избягват XSS атаките:
http://en.wikipedia.org/wiki/Cross-site_scripting

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

[sparkybg]

От: Разни въпроси към WEB-аджиите...

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

А, то тепърва ще ми дойдат на акъла и по-"дълбокомислени" въпроси. Всяко нещо с времето си. Сега гледам "nested master pages" например. Идеята е там да се съхранява session ID-то, и всеки контролер на View, който се показва в нестед мастър страницата да си го тегли автоматично от нея. После правя един абстрактен клас за контролер, който ползват всички View, който в конструктора си изтегля SessionID-то от нестед мастър страницата, където то е записано след логването. Ще видим какви ще ги измъдря...

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

[jumboframe]

От: Разни въпроси към WEB-аджиите...

Абе Вие друга работа нямате ли си ? Днес се пие бира от обяд!

[Tihomir(imageo)]

От: Разни въпроси към WEB-аджиите...

А, то тепърва ще ми дойдат на акъла и по-"дълбокомислени" въпроси. Всяко нещо с времето си. Сега гледам "nested master pages" например. Идеята е там да се съхранява session ID-то, и всеки контролер на View, който се показва в нестед мастър страницата да си го тегли автоматично от нея. После правя един абстрактен клас за контролер, който ползват всички View, който в конструктора си изтегля SessionID-то от нестед мастър страницата, където то е записано след логването. Ще видим какви ще ги измъдря...

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

Къде точно ще го записваш това SessionID, и за какво изобщо ти е необходимо ? Всичко необходимо го има ето тук: http://www.techrepublic.com/article/...x-file/5771721, и кода на VB.NET(понеже ми се струва, че на това пишеш , който слагаш в Global.asax.vb:

Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As EventArgs)
' Extract the forms authentication cookie
Dim cookieName As String
cookieName = FormsAuthentication.FormsCookieName
Dim authCookie As HttpCookie
authCookie = Context.Request.Cookies(cookieName)
If (authCookie Is Nothing) Then
' There is no authentication cookie.
Return
End If
Dim authTicket As FormsAuthenticationTicket
authTicket = Nothing
Try
authTicket = FormsAuthentication.Decrypt(authCookie.Value)
Catch ex As Exception
' Log exception details (omitted for simplicity)
Return
End Try

Dim roles(2) As String

'' Ето тук си логваш усера с кукито - намираш го, аутентикираш го, правиш му проверки, слагаш му роли и т.н.
roles(0) = "One"
roles(1) = "Two"
Dim id As FormsIdentity
' Тук може би ще ти трябва custom IIdentity обект, който да си поддържа логването и аутентикацията на усера
id = New FormsIdentity(authTicket)
Dim principal As GenericPrincipal
principal = New GenericPrincipal(id, roles)

' И накрая си го сетваш в Request.User
Context.User = principal
End Sub

Ако ти трябват някакви променливи по страниците - ползвай смело Context.Items - те са thread-safe, и може да си прехвърляш с тях данни controller->view.

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Абе Вие друга работа нямате ли си ? Днес се пие бира от обяд!

Аз в момента пия бира. Потно Krombacher-че.

И си се човъркам, въпреки това.

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Къде точно ще го записваш това SessionID, и за какво изобщо ти е необходимо ? Всичко необходимо го има ето тук: http://www.techrepublic.com/article/...x-file/5771721, и кода на VB.NET(понеже ми се струва, че на това пишеш , който слагаш в Global.asax.vb:



Ако ти трябват някакви променливи по страниците - ползвай смело Context.Items - те са thread-safe, и може да си прехвърляш с тях данни controller->view.

Под "сесия" разбирай "работна сесия", а не вградената сесия на браузера. Работната сесия съдържа в себе си текущия потребител, базата, в която работи, и правата му в тая конкретна база. Един и същи юзер може да е отворил няколко таба в които да работи в няколко различни бази с различни права във всяка. И по тоя повод контролера на страницата трябва да знае в коя работна сесия се работи към момента на заявката. Ориентирал съм се към скрити полета върху всеки view, които се "предават" от view нa view но мъдря някакъв по-автоматизиран подход. Понеже в post заявка, до колкото ми е известно , се връщат всички стойности на цялата страница, а не само тия на конкретния view, логичния подход би бил да сложа скрито поле в мастър страницата, което да съдържа ID на сесията, и контролерите да си го взимат от там. Сега мъдря механизъма, по който това да стане, и дали изобщо може да стане, понеже мастър страницата няма model, за да стане директно по стандартния начин за view.

Другия начин е ID-то да го има във всяко пренасочване и да се вижда в URL-то, но това не ми допада твърде. Освен това, ако на мастър страницата има контроли (менюта, бутони, табове и т.н.), при натискането им трябва да подават ID-то на контролера, към който е action-а, обаче бидейки в мастър страницата, която няма модел, няма как да се докопат до ID-то, поне по стандартен начин.

[Tihomir(imageo)]

От: Разни въпроси към WEB-аджиите...

Така както го обясняваш - май най-добре си е да е в URL-то sessionID-то. Така ще си настроиш Route-a на контролера да го подава като параметър, да си му чекваш правата още в началото(може и с custom attribute като в този пример), така чекваш permissions дали усера има права за подадения SessionID още преди да си влязъл в кода на view-то. От друга страна - ако е в URL текущата сесия/таб, то усерите могат да си го предават с copy-paste, вместо да си предават общия URL и да се инструктират - сега кликни тук и тук.... По-удобно е.

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

П.С. Всъщност не SessionID-то трябва да е в URL, ами TAB ID. SessionID явно е друго, дето не трябва да е горе. Него може да си го джуркаш през контролера, може и пак с атрибут да се чете и записва в ViewBag, и ще си го имаш винаги в master template-a..