|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Защита! Инъекции! 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 |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Цитата:
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
1 - защита от SQL-инъекций - должна быть всегда
2 - самый нормальный способ "псевдо-авторизации", а не способ защиты приложения, просто без этого действия не отловить уникальность пользователя. 3 - слишком заморочено и не защищено на 100%. не нужно изобретать велосипед, используйте 1,2 и будет вам счастье.
__________________
Gamedev != Gaming (http://twitter.com/#!/GenzoDev). Don't forget to [+] if it works. |
|
|||||
Да но что такое псевдо авторизация и как ее делать?
__________________
------------------------------- FLASH FLASH FLASH FLASH FLASH |
|
|||||
Регистрация: Mar 2008
Сообщений: 215
|
Цитата:
|
|
|||||
Регистрация: Jun 2011
Сообщений: 127
|
Если Вы верите что флеш не декомпилируеют, то 3 вариант можно упростить и сделать вообще без таблицы.
Делайте хеш не со случайным числом, а с текущим серверным временем. Передайте пользователю при старте приложения серверное время и там запустите таймер. При выполнении запроса передавайте и время когда он сделан. Время можно передавать открыто, так как алгоритм хеширования неизвестен. И если |Время на сервере - время на клиенте|> 3 сек, то запрос уже был. Добавлено через 2 минуты 3 секунды - это на вскидку максимум сколько пройдет от момента отправки текущего времени сервером, до получения его клиентом Добавлено через 14 часов 31 минуту Кстати, на счет например получаем число переданное от прила на сервер в пхп Не правильно - $num=$_POST["num"]; Правильно - $num=(int)$_POST["num"]; Если в num передается 100% число, а пришло не число, то значит запрос левый и правильнее Последний раз редактировалось Андрей911; 20.03.2012 в 06:32. |
|
|||||
в том то и дело что за 1 секунду можно успеть 100 запросов. это не выход!
__________________
------------------------------- FLASH FLASH FLASH FLASH FLASH |
|
|||||
Регистрация: Jun 2011
Сообщений: 127
|
Ну тогда можно запоминать в таблице последнее значение времени запроса (в миллисекундах с 1970) и проверять, чтобы каждое следующее было строго больше предыдущего.
Получится по одной ячейке в БД на пользователя, а не на каждый запрос |
|
|||||
...
модератор форума
Регистрация: Sep 2006
Адрес: Minsk
Сообщений: 4,286
|
Если не учитывать возможность декомпиляции приложения, то достаточно передавать в запросе хэш(данные + секретный ключ), а на сервере вычислять этот же хэш и сверять с полученным. Или зачем столько телодвижений по третьему пункту?
Многое от приложения зависит. |
|
|||||
Регистрация: Jun 2011
Сообщений: 127
|
если просто хэш(данные + секретный ключ), то можно перехватить запрос и отправить его еще 100 раз. А если там например покупка, то таким образом можно заплатить один раз, а купить 100.
Это конечно вопрос реализации и можно продумать приложения так чтобы повторный запрос не принес никакой выгоды пользователю. Ну а если выгода есть, то нужно как-то различать одинаковые запросы по времени, это менее затратно, чем хранить данные о каждом запросе и отправлять их со случайным числом. |
Часовой пояс GMT +4, время: 15:17. |
|
« Предыдущая тема | Следующая тема » |
|
|