Каким образом лучше защитить файл, который используется в ajax подгрузке данных Файл выдаёт остаток скидки на определённый код [js] $.ajax({ type: 'post', url: 'ticket.php', dataType: 'html', data: 'ticket=' + ticket, success: function (data) { $('.answer').html(data); } });[/js] например имеем код ABCDE на нём скидка 200рубей. Хочу защитить чтоб не могли запустить сканер для извлечения данных. Думаю делать токен на каждый запрос, может есть что-то проще, ведь токены придётся писать в БД, сверять, потом как-то избаляться от них. да и наверно если сканер делать на саму страницу откуда запрос идёт, могут и токены генерирование поймать и использовать. Вообщем кто сталкивался, может есть другие решения? Спасибо!
boo Что за сканер? Токен легко принять и послать программно, сэмулировав подзапрос. Шифруй сам номер билета каким-то алгоритмом, чтобы не смогли угадать следующий. Например, чтобы получить номер ABCDEF нужно послать F09AB2AACF и т.п. Алгоритм симметричный, последовательный. Токен можно использовать как ключ. Тебе есть что прятать? Тогда стоит оно того.
сканер - имеллось ввиду куча POST запросов к ticket.php с целью выяснить какой код валиден и имеет скидку. Спасибо, навели на мысль о обратимом шифровании, как то не приходило в голову. прятать может и нечего, и даже не кто и пытаться не будет вытащить эти данные, но защита должна быть...
boo Суть задачи в том, чтобы данные были НЕПОСЛЕДОВАТЕЛЬНЫ. Это КРАЙНЕ важно! Если у тебя билеты (это легкий для понимания пример) Код (Text): 123 1234 12345 123456 1234567 То любой школьник в цикле отправит тебе кучу инкрементированных запросов. Соответственно номера 12345 и 12346 образуют арифметическую прогрессию. Так что восьмиклассники тебя задерут. Нужен НЕПОСЛЕДОВАТЕЛЬНЫЙ алгоритм, как пример - обратимый хеш. Из 12345 ты получишь что-то вроде a4d00f0a0eff, а из следующего 12346 - уже 1ef4a12 или тому подобное. Угадать алгоритм, поняв, какие данные под ним, уже становится для восьмиклассника непосильной задачей. Если сами цифры представляют собой такой же симметричный детерминант, то тут если никто не знает алгоритма, то ничего уже не сделает.
+ еще надо писать IP и ограничивать кол-во запросов в период времени (допустим 15 за 10 минут) и т.п.
Эмм... а что мешает сделать эти запросы не на прямую через ticket.php, а через саму форму с сайта (перед шифровкой) тогда шифрование вообще ни чего не даёт. Остаётся тогда то что посоветовал igordata. отправлять будет те же самые 12345, а потом из дива '.answer' получать ответ. (коды если что такого типа- XXXX-XXXX)
Я сейчас опишу небольшую историю, откуда я это знаю, в общем-то. Если кому интересно. Как уже почти все тут знают - я играю в театре. Вернее играл. И в один прекрасный момент случилось так, что нужно было сделать 60 уникальных билетов на одно представление. Тратить деньги на краску, ламинирование, голограммы для нашего бюджета - дело гиблое. Решил за это дело взяться я. Предложение вручную считать количество вошедших и количество билетов всего я отмел сразу: тот, кто подделал, попадет, а тот, кто честно купил - останется в стороне. Это никуда не годилось. Сам билет в два счета можно было распечатать на принтере, меня это не беспокоило. Беспокоили меня только циферки, которые располагались на билете по обеим сторонам и две линии с перерывами в разных местах. Нарисую для демонстрации: Само оформление было внутри черного прямоугольника (на схеме), две нижние полоски обозначали пол и некоторую другую информацию, по которой можно технично описать человека. По этим полоскам можно определить, принадлежит билет владельцу или кому-то другому (куплен для другого кем-то, например. Этой инфы недостаточно). Справа расположен номер серии (время и место продажи) и количество билетов в партии, а так же отношение этого билета к отношению всей партии и серии в целом. Слева! расположен ложный код, точнее он не ложный, а являлся обыкновенным хешем, который должен был получиться из всех данных, описанных выше. Поскольку проверялись именно те данные, то хеш получался сам собой, и если он не сходился - тогда можно было тратить время на проверку. Для меня это был опыт, как бы это смешно не звучало - в партии нашлось 5 подделок. Все принадлежали недоумной школоте, выкинули за уши из зала за 20 секунд после просмотра. По сути я делал ИМЕННО ТОГДА распознавание (OCR) и именно тогда работал с графикой на уровне математики. Оттуда все знания, собсвенно. На реализацию ушел месяц - оно того стоило! boo Ты не понял, что я тебе предложил, увы. Тебе нужно менять не только backend, но и frontend
что менять во фронт? HTML: <input type="text" name="ticket" id="ticket" /> <a id="check_ticket">OK</a> тут дело в другом, что можно с помощью curl генерировать запросы непосредственно с моего сайта(и выходит что защита только ограничение в кол-ве запросов). С билетами интересная история, только у тех людей не было возможности показать вам 10 000 билетов чтоб угадать какой верен. пс: длина кода билета увеличенная в раза 2-3 думаю так же решает проблему...
boo На фронтенде переделывай СТРУКТУРУ цифр на билете. Я тебе это в своём втором сообщении писал. Структура, по которой нельзя угадать последовательность. Знаешь, что такое факториал? Факториал - это страшная штука. Одной цифрой больше - и результат огромен. А логарифм? Так вот, по логарифму вычисляй сложность, по факториалу - вариации. Всё до жути элементарно, но если у тебя структура билета 12345-123-22-123, и эти цифры подобрать можно, то это фейл. Никакой мощный бекенд тебя не защитит
ясно, вообщем выходит пользователю лучше давать уже шифрованный скрытым ключом билет, а после смотреть что при расшифровке совпадали данные и их структура.
boo Ну вот скажи, пожалуйста, если ты пользователю дашь все пароли от банковского счета, а со стороны банка будешь мутить защиту? Принцип всё равно останется прежний, какой бы ни была защита: пользователь авторизируется. Ты даёшь сейчас ключик, которым можно открыть твой замок. Цель твоей системы - реализовать (хотя бы приближенно) черный ящик. Пользователь что-то даёт (и он знает что), в черном ящике происходят какие-то операции и твой бэкенд получает уже чистый ключ и открывает замок. Номер (209357032675293286) -> чёрный ящик -> ключ (12345) -> замок (если ключ == 12345, то ...)