Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > API приложений и сред

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 17.02.2012, 10:53
Azo вне форума Посмотреть профиль Отправить личное сообщение для Azo Найти все сообщения от Azo
  № 1  
Ответить с цитированием
Azo
 
Аватар для Azo

Регистрация: Nov 2004
Адрес: Архангельская область
Сообщений: 492
Отправить сообщение для Azo с помощью ICQ Отправить сообщение для Azo с помощью AIM Отправить сообщение для Azo с помощью Yahoo
Cool Защита! Инъекции! auth_key! Как защитить проект?

Вот и научились создавать приложения. А защитить его не научились.
Перечислю несколько методов защиты и ниже напишу почему этого не достаточно.
Нужна помощь!

1
например получаем число переданное от прила на сервер в пхп
Не правильно - $num=$_POST["num"];
Правильно - $num=(int)$_POST["num"];


например получаем текст типа имени пользователя или другого размером до 10 символов
Не правильно - $name=$_POST["name"];
Правильно - $name=substr($_POST["name"],0,10);


// и тогда злоумышленники не смогут запихать в переменную целые строчки кода типа AND DELETE FROM table



2
передаем серверу значение viewer_id, auth_key
в скрипте должны присудствовать заранее переменные api_id, secret
И проверяем if ($auth_key=md5($viewer_id."_".$api_id."_".$secret)) то пропускаем , иначе блокируем запрос



3
Есть третий вариант защиты , он пока для меня самый действенный и 100% защищающий (если не учитывать возможность декомпиляции приложения)
Действенный то он и действенный но его считаю как "экспериментальны" так как требует лишней таблицы в mysql для хранения ключей

Я на сервере создал табличку с полями ид пользователья, время запроса, рандомное число
А в приложении создал класс который хеширует(свой алгоритм) секретное_слово+","+random()*1000000
И с каждым запросом отправляет на сервер...
Сервер дехеширует и делает split. То есть разделяет на 2 части получая : секретное слово и рандом.
Ид, Времья и рандом записывается в табличку
А теперь фокус:
Если секрет правильный то
И если в табличке не было такого рандома от такого этого user_id за последний ЧАС, то пропускаем.
Иначе: die("код не уникален");

Фишка 3го способа в том что для каждого пользователя и для каждого запроса к серверу от этого пользователя будут уникальные ключи и 2 раза по одному и тому же ключу не пропустим. В отличаи от auth_key, где пользователь изначально может узнать этот код в исходном коде страницы и от лица себя может делать сколько угодно запросов. Да, он не знает authkey других пользователей и поэтому не может повлеять на числа других.. Но может например поднять свой рейтинг в приложении, увидев один раз какой auth_key и viewer_id отправляется




Поэтому вопрос к тем кто уже одолел этот вопрс:
КАК ДОСТИЧЬ ТАКОГО УРОВНЯ ЗАЩИТЫ КАК В п.3 без всяких записей в базу и лишьших запросов mysql...?
__________________
-------------------------------
FLASH FLASH FLASH FLASH FLASH

Старый 17.02.2012, 12:13
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 2  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
он пока для меня самый действенный и 100% защищающий (если не учитывать возможность декомпиляции приложения)
А для меня это самый смешной алгоритм, потому что я могу декомпилировать приложение.
Цитата:
Но может например поднять свой рейтинг в приложении, увидев один раз какой auth_key и viewer_id отправляется
Значит, не стоит хранить их на БД вконтакте.

Старый 17.02.2012, 12:31
Genzo вне форума Посмотреть профиль Отправить личное сообщение для Genzo Посетить домашнюю страницу Genzo Найти все сообщения от Genzo
  № 3  
Ответить с цитированием
Genzo
 
Аватар для Genzo

блогер
Регистрация: Feb 2010
Адрес: MSK
Сообщений: 859
Записей в блоге: 3
Отправить сообщение для Genzo с помощью ICQ Отправить сообщение для Genzo с помощью Skype™
1 - защита от SQL-инъекций - должна быть всегда
2 - самый нормальный способ "псевдо-авторизации", а не способ защиты приложения, просто без этого действия не отловить уникальность пользователя.
3 - слишком заморочено и не защищено на 100%.

не нужно изобретать велосипед, используйте 1,2 и будет вам счастье.
__________________
Gamedev != Gaming (http://twitter.com/#!/GenzoDev). Don't forget to [+] if it works.

Старый 18.02.2012, 02:38
Azo вне форума Посмотреть профиль Отправить личное сообщение для Azo Найти все сообщения от Azo
  № 4  
Ответить с цитированием
Azo
 
Аватар для Azo

Регистрация: Nov 2004
Адрес: Архангельская область
Сообщений: 492
Отправить сообщение для Azo с помощью ICQ Отправить сообщение для Azo с помощью AIM Отправить сообщение для Azo с помощью Yahoo
Да но что такое псевдо авторизация и как ее делать?
__________________
-------------------------------
FLASH FLASH FLASH FLASH FLASH

Старый 13.03.2012, 19:54
incoob вне форума Посмотреть профиль Отправить личное сообщение для incoob Найти все сообщения от incoob
  № 5  
Ответить с цитированием
incoob

Регистрация: Mar 2008
Сообщений: 215
Цитата:
Сообщение от Azo Посмотреть сообщение
например получаем текст типа имени пользователя или другого размером до 10 символов
Не правильно - $name=$_POST["name"];
Правильно - $name=substr($_POST["name"],0,10);


// и тогда злоумышленники не смогут запихать в переменную целые строчки кода типа AND DELETE FROM table
Посмотрите на функцию mysql_real_escape_string. Вроде обычно ее используют для предотвращения инъекций.

Старый 19.03.2012, 16:00
Андрей911 вне форума Посмотреть профиль Отправить личное сообщение для Андрей911 Найти все сообщения от Андрей911
  № 6  
Ответить с цитированием
Андрей911
 
Аватар для Андрей911

Регистрация: Jun 2011
Сообщений: 127
Если Вы верите что флеш не декомпилируеют, то 3 вариант можно упростить и сделать вообще без таблицы.
Делайте хеш не со случайным числом, а с текущим серверным временем.
Передайте пользователю при старте приложения серверное время и там запустите таймер. При выполнении запроса передавайте и время когда он сделан. Время можно передавать открыто, так как алгоритм хеширования неизвестен. И если |Время на сервере - время на клиенте|> 3 сек, то запрос уже был.

Добавлено через 2 минуты
3 секунды - это на вскидку максимум сколько пройдет от момента отправки текущего времени сервером, до получения его клиентом

Добавлено через 14 часов 31 минуту
Кстати, на счет например получаем число переданное от прила на сервер в пхп
Не правильно - $num=$_POST["num"];
Правильно - $num=(int)$_POST["num"];

Если в num передается 100% число, а пришло не число, то значит запрос левый и правильнее
PHP код:
if(!is_numeric($_POST["num"])) die("Положительный ответ сервера. Типа молодец чувак у тебя получилось записать мне что-то в БД"); 


Последний раз редактировалось Андрей911; 20.03.2012 в 06:32.
Старый 21.03.2012, 19:19
Azo вне форума Посмотреть профиль Отправить личное сообщение для Azo Найти все сообщения от Azo
  № 7  
Ответить с цитированием
Azo
 
Аватар для Azo

Регистрация: Nov 2004
Адрес: Архангельская область
Сообщений: 492
Отправить сообщение для Azo с помощью ICQ Отправить сообщение для Azo с помощью AIM Отправить сообщение для Azo с помощью Yahoo
в том то и дело что за 1 секунду можно успеть 100 запросов. это не выход!
__________________
-------------------------------
FLASH FLASH FLASH FLASH FLASH

Старый 21.03.2012, 20:43
Андрей911 вне форума Посмотреть профиль Отправить личное сообщение для Андрей911 Найти все сообщения от Андрей911
  № 8  
Ответить с цитированием
Андрей911
 
Аватар для Андрей911

Регистрация: Jun 2011
Сообщений: 127
Ну тогда можно запоминать в таблице последнее значение времени запроса (в миллисекундах с 1970) и проверять, чтобы каждое следующее было строго больше предыдущего.
Получится по одной ячейке в БД на пользователя, а не на каждый запрос

Старый 21.03.2012, 21:03
udaaff вне форума Посмотреть профиль Отправить личное сообщение для udaaff Найти все сообщения от udaaff
  № 9  
Ответить с цитированием
udaaff
...

модератор форума
Регистрация: Sep 2006
Адрес: Minsk
Сообщений: 4,286
Если не учитывать возможность декомпиляции приложения, то достаточно передавать в запросе хэш(данные + секретный ключ), а на сервере вычислять этот же хэш и сверять с полученным. Или зачем столько телодвижений по третьему пункту?
Многое от приложения зависит.

Старый 22.03.2012, 09:11
Андрей911 вне форума Посмотреть профиль Отправить личное сообщение для Андрей911 Найти все сообщения от Андрей911
  № 10  
Ответить с цитированием
Андрей911
 
Аватар для Андрей911

Регистрация: Jun 2011
Сообщений: 127
если просто хэш(данные + секретный ключ), то можно перехватить запрос и отправить его еще 100 раз. А если там например покупка, то таким образом можно заплатить один раз, а купить 100.
Это конечно вопрос реализации и можно продумать приложения так чтобы повторный запрос не принес никакой выгоды пользователю. Ну а если выгода есть, то нужно как-то различать одинаковые запросы по времени, это менее затратно, чем хранить данные о каждом запросе и отправлять их со случайным числом.

Создать новую тему Ответ Часовой пояс GMT +4, время: 17:53.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 17:53.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.