Security веб проекта на .NET

[q_q4138]

Привет всем,

Делаю веб проект в VS, VB. По разным причинам сложно выносить connection strings в web.config, они остаются в code behind. Насколько я рискую в плане security? Мнения хакеров приветствуются .

[Gennadiy]

Привет всем,

Делаю веб проект в VS, VB. По разным причинам сложно выносить connection strings в web.config, они остаются в code behind. Насколько я рискую в плане security? Мнения хакеров приветствуются .

Абсолютно ничего не понятно. Connection string к чему? К базе данных?
Как ищется соответствие пользователя веба и базы данных? Какая модель web authontication используется? А какая web authorization?
В теории - внешние юзеры при правильной защите веб сервера добратся до code behind не могут. Ведь на клиент передается голый HTML (точнее HTTP headers тоже есть - вот тут могут быть дыры, но они с code behind не связаны обычно).

[Aden]

В общем случае, ConnectionString будет более "safe" как раз в "code behind", поскольку .vb файлы компилируются в DLL и не лежат в чистом виде на веб-сервере (непонятно только, Вы что, при каждом изменении парамeтров соединения с БД будете перекомпилировать проект?). А так, используйте CryptoAPI http://msdn.microsoft.com/library/defau ... portal.asp

[Bobo]

В общем случае, ConnectionString будет более "safe" как раз в "code behind"

В обшем случае нет никакой разницы.
Поскольку ни *.dll ни *.config веб сервер не отдаст.
Если же хакер получил доступ к файлам, минуя веб сервер, то тоже нет никакой разницы, т.к. в обшем случае dll декомпилируется.
Шифруйте TripleDESом, если боитесь.
Или используйте dotfuscator какой-нибудь

[Stick]

В общем случае, ConnectionString будет более "safe" как раз в "code behind"

В обшем случае нет никакой разницы.
Поскольку ни *.dll ни *.config веб сервер не отдаст.
Если же хакер получил доступ к файлам, минуя веб сервер, то тоже нет никакой разницы, т.к. в обшем случае dll декомпилируется.
Шифруйте TripleDESом, если боитесь.
Или используйте dotfuscator какой-нибудь

Dllку компилируйте с "сильным именем". Она будет надёжно заинкриптaна. Strong name compilation. И ни каких проблем.

[Bobo]

Dllку компилируйте с "сильным именем". Она будет надёжно заинкриптaна. Strong name compilation. И ни каких проблем.

Нет.
Или вы так шутите?

[q_q4138]

Спасибо.

[Stick]

Нет.
Или вы так шутите?

Нет.
Я не шучу. Это серьёзный раздел и я понимаю это. А strong name компиляция - обычное дело и очень эффективный метод предотвращения декомпиляции ваших исходников.

[Falcon]

Нет.
Или вы так шутите?

Нет.
Я не шучу. Это серьёзный раздел и я понимаю это. А strong name компиляция - обычное дело и очень эффективный метод предотвращения декомпиляции ваших исходников.

Вы натурально бредите. Strong name может дать только имитозащиту но не предотвратить декомпиляцию. За скромных $5 я вам декомпилирую любую strong name assembly.

[blanko27]

...За скромных $5 я вам декомпилирую любую strong name assembly.

Давайте, я вам декомпилирую за $4.95

[Stick]

Да, ладно вам. Присылайте мне свои дллки - раскрою за так, за бесплатно. Пришлось покапаться в гуголе и найти как это делается. Хакеру хакерово. Может кто знает как .NET assemblies теперь защищать?

[blanko27]

Примените какой-либо обфускатор. Я как-то, около месяця-двух назад, поднимал вопрос об выборе обфускатора, но никто ничего не порекомендовал.

[Stick]

Примените какой-либо обфускатор. Я как-то, около месяця-двух назад, поднимал вопрос об выборе обфускатора, но никто ничего не порекомендовал.

Спасибо Вам за подсказку! Очень благодарен!
После недолгого шАпанья решил выкупить себе вот такой обфускатор:
[url=http://www.9rays.net/cgi-bin/components.cgi?act=1&cid=86]Spices.Obfuscator.Net [Console Only] Spices.Obfuscator.Net Console 62.95$
[/url] Недорого и мне нужен только консольный вариант.

[IA72]

Примените какой-либо обфускатор. Я как-то, около месяця-двух назад, поднимал вопрос об выборе обфускатора, но никто ничего не порекомендовал.

Спасибо Вам за подсказку! Очень благодарен!
После недолгого шАпанья решил выкупить себе вот такой обфускатор:
[url=http://www.9rays.net/cgi-bin/components.cgi?act=1&cid=86]Spices.Obfuscator.Net [Console Only] Spices.Obfuscator.Net Console 62.95$
[/url] Недорого и мне нужен только консольный вариант.

Практически никакого проку от обфускаторов нет. Да и собственно - зачем вообще нужно прятать код - у вас особо секретные алгоритмы применяются? Тогда запатентуйте. А иначе в чем смысл? Да и баги внесенные могут появится, а морока с отложенным подписанием при наличие нескольких библиотек способна свести с ума при автоматизированной компиляции. Не надо это вам.

[blanko27]

... баги внесенные могут появится ... Не надо это вам.

Вот и я в сомнении, хотя не против был бы получить какую-нибудь инфу о хороших коммерческих обфускаторах. Для конторы хотелось бы что-нибудь приличное прикупить.

[Stick]

Практически никакого проку от обфускаторов нет. Да и собственно - зачем вообще нужно прятать код - у вас особо секретные алгоритмы применяются? Не надо это вам.

Мине нада. Секрет скажу: продаю я их, зти самые асэмбли. Сам делаю и сам продаю. Идут на расхват. Тока защитить бы их ищо не мешает.

[IA72]

Практически никакого проку от обфускаторов нет. Да и собственно - зачем вообще нужно прятать код - у вас особо секретные алгоритмы применяются? Не надо это вам.

Мине нада. Секрет скажу: продаю я их, зти самые асэмбли. Сам делаю и сам продаю. Идут на расхват. Тока защитить бы их ищо не мешает.

И каким образом обфускатор их защитит? Тем более что для библиотек это еще меньше имеет смысл, так как public & protected методы в этом случае просто нельзя переименовывать. А в переименовывании и создании фальшивых overload методов собственно главный смысл и есть. Шифрование строковых констант - не смешите мои тапочки. Не говоря уже о такой замечательной вещи, как сообщения об ошибках - вместо достаточно полезного стека вы получите бесполезный для исследования набор непонятно чего. Еще раз - это совершенно глупое занятие, если вдуматься. Ненужное и зачастую вредное. Как вы думаете, почему Microsoft свои библиотеки не шифрует? Ценность кода это не алгоритм вот этой конкретной процедуры, и не структура объектов, а продукт целиком. Исключения надо патентовать.

[blanko27]

И каким образом обфускатор их защитит?

От умного - не защитит. Только умные, как правило не воруют по мелочам. От дурака - да защитит. Поэтому, я думаю, что для обфускаторов тоже есть ниша. Вон РемоутСофт не мелочится, $1000 их обфускатор стОит.

[Stick]

И каким образом обфускатор их защитит? Тем более что для библиотек это еще меньше имеет смысл, так как public & protected методы в этом случае просто нельзя переименовывать. А в переименовывании и создании фальшивых overload методов собственно главный смысл и есть. Шифрование строковых констант - не смешите мои тапочки. Не говоря уже о такой замечательной вещи, как сообщения об ошибках - вместо достаточно полезного стека вы получите бесполезный для исследования набор непонятно чего. Еще раз - это совершенно глупое занятие, если вдуматься. Ненужное и зачастую вредное. Как вы думаете, почему Microsoft свои библиотеки не шифрует? Ценность кода это не алгоритм вот этой конкретной процедуры, и не структура объектов, а продукт целиком. Исключения надо патентовать.

Что даст патентование алгоритмов? Куча денег и времени это дело убъёт. У меня нет каких-то уникальных алгоритмов чтоб патентовать. Всё уже придумано.
Зачем public & protected методы переименовывать? Что внутри у них - это да, это можно попереименовывать. Зачем сообщения об ошибках конечному пользователю из сборки показывать? Или я чего-то не понимаю? Microsoft может себе позволить свои библиотеки не шифровать. Я нет.
Если говорить про продукт целиком, так у меня сборки привязываются к проекту разработчика хитрым алгоритмом. Если кто-то посторонний пытается прилипить сборку к своему проекту - у него не получается. Может этот алгоритм запатентовать? Только патентование "это совершенно глупое занятие", говоря Вашими словами.

[IA72]

Что даст патентование алгоритмов? Куча денег и времени это дело убъёт. У меня нет каких-то уникальных алгоритмов чтоб патентовать. Всё уже придумано.

Тогда вам нет необходимости запутывать код

Зачем public & protected методы переименовывать? Что внутри у них - это да, это можно попереименовывать.

А что у них внутри? Вы понимаете, как обфускаторы работают?
С _кодом_ они ничего, кроме вставления фальшивых goto ничего не делают -
все запутывание исключительно на переименовании методов, что бы сложнее было читать. При этом я лично сталкивался со случаем, когда после обфускации код переставал работать - причем причину из сообщения было узнать нельзя.

Зачем сообщения об ошибках конечному пользователю из сборки показывать? Или я чего-то не понимаю?

? А вам для исправления багов, которые у пользователя случились они тоже не нужны? Ну-ну.

Microsoft может себе позволить свои библиотеки не шифровать. Я нет.
Если говорить про продукт целиком, так у меня сборки привязываются к проекту разработчика хитрым алгоритмом. Если кто-то посторонний пытается прилипить сборку к своему проекту - у него не получается. Может этот алгоритм запатентовать?

Если он представляет собой какую-то ценность, почему бы и нет.
А если это использование StrongNameIdentityPermissionAttribute в купе с выдаваемой клиенту персональной proxy, подписанной вами же, или еще какой аналогичный "хитрый алгоритм" , то не стоит.

Только патентование "это совершенно глупое занятие", говоря Вашими словами.

Я про патентование такого не говорил - если вы так считаете, то это исключительно ваши проблемы.
Короче, я завязываю - убеждать вас вдохнуть и подумать а нужно ли это на самом деле и стоит ли тратить на это время, деньги и усилия я больше не буду - каждый Буратино сам себе враг - вперед, наступайте на грабли самостоятельно.

[blanko27]

... Я про патентование такого не говорил - если вы так считаете, то это исключительно ваши проблемы.

А вот патентование, кстати, это тоже интересная область. Где-то слышал, что это даже не очень дорого.

[Stick]

Мне особенно понравилось про Буратино. Забавно...

[Falcon]

Мне особенно понравилось про Буратино. Забавно...

Мда... человек вам дело говорит, а вы смеетесь. Все обфускаторы предназначены для некомпетентных параноиков, никакой защиты они дать не могут. Даже pain in the ass не причиняют, так, мелкие неудобства только. И будьте уверены что если уж кто-то затеял декомпилировать вашу ассембли то он просто плюнет слюной на такую "защиту"

[Strannik223]

А по-моему топик в сторону куда-то от оригинального вопроса ушел. Человек спрашивал куда connection string засунуть что бы его не хакнули

Ответ: в web.config ему самое место. Сервер этот файл не отдаст веб клиету, поэтому нечего себе голову морочить обфускаторами если в них нет нужды.