Добро пожаловать! Это — архивная версия форумов на «Хакер.Ru». Она работает в режиме read-only.
 

Защита клиент-серверного приложения.

Пользователи, просматривающие топик: none

Зашли как: Guest
Все форумы >> [Защита] >> Защита клиент-серверного приложения.
Имя
Сообщение << Старые топики   Новые топики >>
Защита клиент-серверного приложения. - 2011-11-29 10:55:37.276666   
kb33

Сообщений: 46
Оценки: 0
Присоединился: 2007-04-03 10:06:11.443333
Описание задачи:

Глобальная цель: защитить программно интеллектуальную собственность: как код программы, так и нелегальное использование программы.

Программный комплекс представляет собой клиент-серверное приложение для решения логистической задачи (реализован сложный алгоритм). СУБД ms sql server 2008, клиент - .net-приложение на c#.
На сервере находится бд с данными учётных записей и с данными, необходимыми для работы алгоритма.
На клиенте происходят все вычисления (сделано это для того, чтобы не заморачиваться относительно балансировки нагрузки на сервер, т.к. вычислений очень много, а сервер, в идеале, с экономической точки зрения, один).
Для того, чтобы нельзя было получить доступ к коду реализованного сложного алгоритма, клиентское приложение обфусцировано.

Предполагается, что пользователь платит денюжку, взамен получает программу-клиента, логин/пароль. Введя логин/пароль, пользователь получает доступ к бд + недостающие параметры для работы алгоритма.

Вопрос: необходимо, чтобы логин/пароль + данные передавались по защищённому каналу. Была идея использовать ssl, но я так понимаю, тогда следует думать относительно сертификатов (установки удостоверяющего центра, установки и выдачи сертификатов). Не будет ли лучше использовать один самостоятельно реализованных криптоалгоритмов? Например, алгоритм рукопожатия (тогда встаёт вопрос об использовании длинной арифметики, но тут, вроде бы, в интернете и готовых модулей хватает.)

Подскажите, пожалуйста, слабые места в задумке, и помогите решить вопрос о защите канала передачи данных.
Заранее благодарю!
Post #: 1
RE: Защита клиент-серверного приложения. - 2011-11-30 12:33:32.943333   
Pupkin-Zade

Сообщений: 9398
Оценки: 1489
Присоединился: 2004-03-10 13:54:16
ИМХО да - лучше использовать самостоятельное шифрование.
Слабое место все же по моему одно - что клиент все-таки отреверсят, ведь тут вопрос весь в деньгах.
Post #: 2
RE: Защита клиент-серверного приложения. - 2011-12-01 13:19:00.086666   
kb33

Сообщений: 46
Оценки: 0
Присоединился: 2007-04-03 10:06:11.443333
Понятно, спасибо за ответ!

А если реализовать проверку подлинности и авторизацию с помощью классов, и передавать уже в открытом виде хеш-паролей с "солью"?
И если сервер подключен к интернету и передаёт результаты работы клиентов на веб-сайт, как можно защитить сервер от внешнего вторжения? Будет ли достаточно установить список доступа и запретить любой трафик на сервер?
Post #: 3
RE: Защита клиент-серверного приложения. - 2011-12-01 13:47:28.380000   
Pupkin-Zade

Сообщений: 9398
Оценки: 1489
Присоединился: 2004-03-10 13:54:16
Ничего не понял, честно говоря. Авторизацию клиента на сервере? И что это даст? ИМХО вы просто сделаете еще одно уязвимое звено, а уж передавать в открытом виде пароль - это чудная затея. Почему бы вам не создать VPN сеть если у вас все так ценно?
Post #: 4
RE: Защита клиент-серверного приложения. - 2011-12-01 14:04:03.936666   
kb33

Сообщений: 46
Оценки: 0
Присоединился: 2007-04-03 10:06:11.443333
В том смысле, что по открытому каналу, не шифрованному, передавать логин и хеш пароля с солью.
А схема сети такая, т.е. только сервер имеет доступ в интернет.

Post #: 5
RE: Защита клиент-серверного приложения. - 2011-12-01 17:49:13.853333   
rgo

Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
quote:

ORIGINAL: kb33
А если реализовать проверку подлинности и авторизацию с помощью классов, и передавать уже в открытом виде хеш-паролей с "солью"?

Стоп-стоп. Вот тут поподробнее пожалуйста. Куда передавать хеши паролей с солью? Зачем передавать?

Зачем нужны хеши? Они для того, чтобы не хранить на сервере паролей: если база хешей уйдёт, то пароли останутся неизвестными общественности. Надо будет ещё брутить эти самые пароли. Что, при соблюдении всеми сторонами элементарных правил безопасности, безнадёжная затея.

Если же сервер выполняет авторизацию принимая хеш, то смысл хешей просто пропадает. Ведь в такой ситуации если спёрли базу хешей, то можно войти по хешу.

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

Передавать хеши можно, разве что, если параноидальная система безопасности подразумевает разделение труда: считаются хеши на одной машине (своим каким-то хитрым никому неизвестным алгоритмом), а хранятся хеши на другой машине. Ну типа если одна из машин взломана, то всё равно организовать брутфорс невозможно: для брутфорса надо знать алгоритм и иметь базу хешей. Но в этом варианте стоит два сервера – один сервер рабочий, второй сервер авторизации. Между серверами супер-пупер защищённый канал, проверка сертификатов и прочая мутотень.

quote:

ORIGINAL: kb33
Вопрос: необходимо, чтобы логин/пароль + данные передавались по защищённому каналу. Была идея использовать ssl, но я так понимаю, тогда следует думать относительно сертификатов (установки удостоверяющего центра, установки и выдачи сертификатов).

Да зачем тебе центры авторизации и прочая мутотень? Просто создаётся серверный сертификат, и на каждого клиента создаётся клиентский соответствующий серверному. При этом, в процессе авторизации, клиент не проверяет сертификат сервера, соответственно центры проверки сертификатов не нужны. Всё. И заодно не надо никаких паролей, никаких хешей и прочей шняги.
SSL – это всё в одном флаконе: и зашифрованное соединение, и авторизация клиента, и авторизация сервера. Другое дело, что можно использовать возможности SSL не полностью и иметь, скажем, только зашифрованное соединение и никакой авторизации. Или зашифрованное соединение и авторизацию клиента. Или зашифрованное соединение и авторизацию сервера. Но центр проверки сертификатов нужен только в той ситуации, когда клиент связывается с сервером, сервер говорит: "я член-с-горы.рф, вот мой сертификат!", а клиент при этом сертификат этот в первый раз видит. Вот тогда клиенту надо связаться с центром выдачи сертификатов и задать вопрос: "действительно ли член-с-горы.рф имеет такой сертификат (см. в приложении)?", и тогда центр выдачи сертификатов смотрит, проверяет и отвечает на вопрос: "да этот сертификат был выдан члену-с-горы.рф". Но если клиента не колышет авторизованность сервера, или клиент и так знает какой должен быть сертификат у сервера, то нафиг эти центры выдачи сертификатов нужны?
Post #: 6
RE: Защита клиент-серверного приложения. - 2011-12-01 18:01:33.073333   
rgo

Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
И вообще. Если в криптографии не в зуб ногой, то надо либо идти и изучать хотя бы азы, либо брать готовые схемы, скажем SSL и действовать согласно их рекомендациям. Вплоть до того, что тупым копипастом из туториалов реализовывать. Всяко надёжнее, чем вручную выкаблучиваться.
Post #: 7
RE: Защита клиент-серверного приложения. - 2011-12-02 17:08:08.916666   
kb33

Сообщений: 46
Оценки: 0
Присоединился: 2007-04-03 10:06:11.443333
rgo, спасибо за подробный ответ, конечно, но я и пытаюсь освоить азы, в том числе, задавая глупые вопросы.
Post #: 8
RE: Защита клиент-серверного приложения. - 2011-12-03 00:58:06.713333   
rgo

Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
quote:

ORIGINAL: kb33
rgo, спасибо за подробный ответ, конечно, но я и пытаюсь освоить азы, в том числе, задавая глупые вопросы.

Начать рекомендую с какого-нибудь учебника по криптографии. В алгоритмы вникать не обязательно, но в то, что эти алгоритмы дают – стопроцентов стоит. Узнать, скажем, что такое симметричные алгоритмы, ассиметричные, с открытым ключом, с закрытым. Для чего подходят те или иные алгоритмы. Примеры того, как можно создать защищённый канал, и тд, и тп. Так, на "глупых вопросах", далеко не уедешь. Глупые вопросы могут помочь, когда азы уже известны. Не, вопросы-то задавай – нет проблем. Я это лишь к тому говорю, чтобы подсказать наиболее эффективный путь, как можно въехать в тему.
Криптография очень тонкая штука. Одна неточность в протоколе обмена, и весь труд насмарку, поскольку протокол оказывается уязвим. Регулярно попадаются весёлые истории о взломах криптографических систем, деланных пальцем и на коленке. Я поэтому и рекомендую просто пользоваться SSL. То есть пойти почитать туториалы, где обязательно будет расписано как SSL работает. И уже понимая что к чему скопипастить код из туториала в свой проект.

Тот же VPN, который советовал Pupkin, строит всю свою приватность на использовании SSL: поднимая VPN надо возиться со всеми этими сертификатами, рассылать их всем, кто хочет подключиться к VPN и тд., и тп. И можно было бы и создать VPN между клиентами и сервером, а имея защищённую локалку уже можно особо и не париться о том, что кто-то будет перехватывать трафик и тырить пароли. Но использование VPN – это лишний блок кода, это более сложная в администрировании программа. То есть тебе, как программисту работа будет проще, но тому кто твою программу будет устанавливать, вероятно придётся повозиться: а если у него уже каждый компьютер в двух разных VPN сетях состоит? Каково такому админу ещё и третий VPN интерфейс в систему внести, причём так, чтобы конфликтов никаких не возникало? Или VPN over VPN создать, а? Так вот, прямое использование SSL избавит от этих проблем.
Post #: 9
RE: Защита клиент-серверного приложения. - 2011-12-03 20:44:00.103333   
kb33

Сообщений: 46
Оценки: 0
Присоединился: 2007-04-03 10:06:11.443333
rgo, спасибо ещё раз за советы, возьму на вооружение, буду учиться.

Задам ещё только парочку глупых вопросов, а то я себе это немного пространно представляю, а время меня поджимает:

если у меня есть exe-программа, которая подключается через интернет к серверу баз данных, между клиентом и сервером можно установить ssl-канал с помощью привязки сертификатов к портам?
Ориентируюсь здесь на эту ссылку, правильно ли?
http://msdn.microsoft.com/ru-ru/library/ms733791.aspx

Можно ли сделать передачу пароля и логина по ssl-каналу на сервер бд, а авторизацию каким-то образом с помощью active directory?
Post #: 10
RE: Защита клиент-серверного приложения. - 2011-12-04 03:12:55.940000   
rgo

Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
quote:

ORIGINAL: kb33
Ориентируюсь здесь на эту ссылку, правильно ли?
http://msdn.microsoft.com/ru-ru/library/ms733791.aspx

Там что-то про http… Зачем тебе http? Нужен просто секурный сокет. SSL – это Secure Socket Layer, то есть грубо говоря, SSL вклинивается в стек TCP/IP, одевается сверху на TCP. И, скажем, весь https – это тот же http, только не на базе протокола tcp, а на базе ssl одетого на tcp.
Это я к тому, что http, как я понимаю, тебе не нужен совершенно. И функции тебе нужны другие. Я не знаю что там и как в win32api для этого есть. Но я знаю, что всё это есть в OpenSSL: там есть и все необходимые API для клиента/сервера. Там есть и утилитки для создания генерации ключей, создания сертификатов и прочая, и прочая.
Что именно и как надо делать – я не могу сказать, поскольку OpenSSL знаю лишь с точки зрения администратора: я никогда не писал программ использующих SSL. Я знаю как создать все нужные сертификаты для сервера и клиентов, и я могу тебе это рассказать. Но как программировать – я не знаю. Хочешь я тебе туториал найду по OpenSSL? Но, при этом, не надо забывать, что может тебе OpenSSL и не нужен, если ты найдёшь функции для работы именно с SSL в win32api: удобнее, конечно, обойтись без OpenSSL, если не стоит вопрос кроссплатформенности клиента или сервера.

Но если ты планируешь использовать SSL, то всенепременно надо начать со статьи в википедии: прочитай её целиком, и убедись что тебе понятны все слова, под которыми прячутся ссылки на другие статьи. Просто SSL ведь подразумевает разные методы авторизации, разные уровни авторизации. Использование центров авторизации, не использование этих центров. Там много опций. И чтобы при написании кода не тонуть в вопросах типа "а зачем этот аргумент с непонятным описанием" стоит начать именно с теоретической подготовки.

quote:

ORIGINAL: kb33
Можно ли сделать передачу пароля и логина по ssl-каналу на сервер бд, а авторизацию каким-то образом с помощью active directory?

Я с AD очень мало дел имел. Причём как программист не имел вообще, лишь как администратор я поднимал контроллер домена на линуксе, и впихивал в него winxp хосты. Делал я это один раз, делал с кучей проблем: вендохосты ну никак не хотели признавать мой контроллер… Короче я уже и не помню ничего оттуда. Так что в этом я вообще ничего не смогу подсказать. Могу лишь сказать, что по SSL каналу можно передать логин и пароль. А вот можно ли попросить контроллер домена проверить логин с паролем… Этого я уже не знаю. Да и, думаю, там какие-то другие пути должны быть: если хост уже зарегался на контроллере, то надо как-то общаться с контроллером и выяснять, что этот хост из себя представляет.
Хотя могу предложить грязный трюк. админы, которым придётся работать с твоей программой, наверное тебя убьют за это. Но и тем не менее схема вполне рабочая: создаётся шара, на ней папка на которую проставляются такие ограничения доступа, чтобы писать туда могли бы лишь те, кому можно подключаться к твоему серверу. Твой же клиент будет лезть в эту папку и создавать там файлик, передавая таким образом серверу информацию о себе. Если хост, на котором клиент работает не зареган как надо на контроллере, то клиенту создать файлик не удастся.
Post #: 11
RE: Защита клиент-серверного приложения. - 2011-12-05 17:10:40.693333   
kb33

Сообщений: 46
Оценки: 0
Присоединился: 2007-04-03 10:06:11.443333
Спасибо большое за ответы, они мне очень помогли!
quote:

ORIGINAL: rgo
Хочешь я тебе туториал найду по OpenSSL?

Буду очень благодарен!

Пока в итоге у меня получается вот такая схема:
Клиент по ssl передаёт логин/пароль серверу. В бд хранится хеш пароля и соль. Проводится проверка пароля. Если клиент прошёл аутентификацию, далее определяются его права, в зависимости от того к какой роли он принадлежит.
Теперь осталось мне с ssl разобраться.

quote:

ORIGINAL: rgo
Хотя могу предложить грязный трюк.

:)) запомню, спасибо!

quote:

ORIGINAL: rgo
Я знаю как создать все нужные сертификаты для сервера и клиентов, и я могу тебе это рассказать.

rgo, расскажи, пожалуйста, буду очень благодарен!
Post #: 12
RE: Защита клиент-серверного приложения. - 2012-01-08 23:18:11.006666   
Jo Faza

Сообщений: 17
Оценки: 0
Присоединился: 2011-12-07 22:35:25.830000
В .NET очень развита криптографическая подсистема так что использовать какие-либо сторонние библиотеки (типа OpenSSL) не имеет смысла. В 4й версии фреймворка уже реализована арифметика больших чисел, так что программирование криптографических алгоритмов превращается в удовольствие.

Можно самому запрограммировать алгоритм шифрования а затем встроить его в .NET и использовать стандартный для .net поточный подход к шифрованию (при помощи CryptoStream). Об этом можете прочитать в моей статье в январском (2012) номере журнала "Хакер".

В вашем случае организовать защищенный канал связи проще всего самостоятельно с применением средств .NET Framework. Основная задача при этом - распределение ключей, что проще всего сделать используя протоколы открытого распределения, при этом открытый ключ сервера можно встроить в клиентское приложение. Все это достаточно просто и не займет много времени.

Я могу рассказать поподробнее, напишите мне на емейл first@plaintext.su либо через форму обратной связи на сайте http://plaintext.su
Post #: 13
Страниц:  [1]
Все форумы >> [Защита] >> Защита клиент-серверного приложения.







Связаться:
Вопросы по сайту / xakep@glc.ru

Предупреждение: использование полученных знаний в противозаконных целях преследуется по закону.