Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   API приложений и сред (http://www.flasher.ru/forum/forumdisplay.php?f=61)
-   -   Защита! Инъекции! auth_key! Как защитить проект? (http://www.flasher.ru/forum/showthread.php?t=175458)

Azo 17.02.2012 10:53

Защита! Инъекции! 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...?

Psycho Tiger 17.02.2012 12:13

Цитата:

он пока для меня самый действенный и 100% защищающий (если не учитывать возможность декомпиляции приложения)
А для меня это самый смешной алгоритм, потому что я могу декомпилировать приложение.
Цитата:

Но может например поднять свой рейтинг в приложении, увидев один раз какой auth_key и viewer_id отправляется
Значит, не стоит хранить их на БД вконтакте.

Genzo 17.02.2012 12:31

1 - защита от SQL-инъекций - должна быть всегда
2 - самый нормальный способ "псевдо-авторизации", а не способ защиты приложения, просто без этого действия не отловить уникальность пользователя.
3 - слишком заморочено и не защищено на 100%.

не нужно изобретать велосипед, используйте 1,2 и будет вам счастье.

Azo 18.02.2012 02:38

Да но что такое псевдо авторизация и как ее делать?

incoob 13.03.2012 19:54

Цитата:

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


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

Посмотрите на функцию mysql_real_escape_string. Вроде обычно ее используют для предотвращения инъекций.

Андрей911 19.03.2012 16:00

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

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

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

Если в num передается 100% число, а пришло не число, то значит запрос левый и правильнее
PHP код:

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


Azo 21.03.2012 19:19

в том то и дело что за 1 секунду можно успеть 100 запросов. это не выход!

Андрей911 21.03.2012 20:43

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

udaaff 21.03.2012 21:03

Если не учитывать возможность декомпиляции приложения, то достаточно передавать в запросе хэш(данные + секретный ключ), а на сервере вычислять этот же хэш и сверять с полученным. Или зачем столько телодвижений по третьему пункту?
Многое от приложения зависит.

Андрей911 22.03.2012 09:11

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


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

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