Я хотел бы ограничить доступ к файлу PHP на моем сервере. Этот PHP-файл принимает данные из HTTP-запроса GET и добавляет его в файл. Просто. Но я не хочу, чтобы этот файл PHP выполнялся, если HTTP-запрос не создан из приложения смартфона, которое я разработал.
Я не хочу аутентифицировать каждого пользователя отдельно. Я хочу, чтобы мое приложение и только мое приложение могли отправлять запрос в файл PHP. Я не хочу, чтобы люди вводили аналогично сформированный запрос (http://www.mydomain.com/check.php?string=blahblahblah) в браузер и оказывали такое же влияние.
Я подумал о проверке HTTP_USER_AGENT или какой-либо другой переменной, но я боюсь, что их тоже легко подделать. Я мог бы вставить ключ в свое приложение, которое я ищу, но этот ключ также может быть скомпрометирован.
Следующим шагом было бы, чтобы сервер отправил мне вызов, на который я отвечаю соответствующим образом. Или я мог даже заглянуть в PKI. Но что относительно простой способ сделать это, учитывая, что я не пытаюсь защитить что-либо реальную ценность, просто чтобы предотвратить мелкий вандализм.
Я пытаюсь изобрести колесо здесь? Есть ли простой, проверенный способ сделать это?
FWIW, вот самый безопасный метод, о котором я могу думать, без серьезного влияния на производительность – по существу, путь RESTful (ish), поскольку для его дальнейшего увеличения потребуется несколько запросов и информация о состоянии соединения, хранящаяся на сервере:
Чтобы прорвать эту систему и успешно обмануть запрос, злоумышленнику нужно будет знать следующее:
Очевидно, что если вы работаете с мобильным устройством 1 – 3, его легко извлечь, но 4 и 5 не могут быть найдены без обратного проектирования приложения (которое буквально ничего не может сделать для предотвращения, для людей, обладающих знаниями и терпением сделай это).
Атака «человек в середине» в принципе невозможна – даже после пробития SSL (что, по меньшей мере, нетривиально) и обратного проектирования приложения, чтобы получить 4 и 5, 1-3 невозможно получить без нападение грубой силы на хэш, что является достаточно сложным, что для этого потребуется в среднем несколько сотен миллионов лет (см. эту страницу, чтобы увидеть, как я пришел к этой цифре), особенно если одна из трех имеет переменную длину, которая строка версии приложения может быть легко выполнена.
Определите соль как в вашем приложении, так и в файле php, затем добавьте хеш в сочетании с текущим временем. Это вряд ли когда-нибудь обманет.
$hash = sha1(time() . 'bladieblasalt'); if($_GET['hash'] == sha1(time() . 'samehash')) { echo 'valid'; } Во-первых, вам нужно будет внедрить ssl в ваше приложение, а кто-то с небольшим знанием может просто иметь там телефон, подключенный к Wi-Fi, и обнюхивать трафик между приложением и вашим сайтом с помощью wirehark или cain и abel ect. и получить URL-адрес и любые переданные параметры, не нужно разбирать что-либо.
Приложение подключается к вашему сайту и пользовательским журналам, независимо от того, является ли его гость или член вашим сервером, присваивает приложению идентификатор запроса, и этот ключ / токен передается вместе с каждым запросом и проверяется в сеансе на вашем сервере.
Токен будет выглядеть так: UNIQUE_REQUEST_ID_ASSIGNED_BY_SERVER:APPsIP:APPsTIME Шифровать эту строку и отправить ее как $_GET['token']
Затем на вашем сервере расшифруйте строку и explode() строку в ее части и проверите против базы данных или сеанса, что идентификатор запроса, ip и время соответствия ect, если все хорошо, что бы это ни было.
Подобно системе безопасного входа в систему, для каждого пользователя присваивается уникальная соль и хранятся вместе с идентификатором пользователя.
Суть заключается в том, чтобы заставить злоумышленника злоупотреблять системой. 99% людей даже не подумают, что они будут играть, а остальные 1% будут закрыты.
Если вы не хотите ничего для каждого пользователя, но только для каждого приложения, вам придется полагаться на секрет, встроенный в приложение. Любой, кто разбирает приложение, в конечном итоге сможет найти это, поэтому может возникнуть какая-то обфускация, но он не будет удерживать определенных людей от вашей страницы.
Тем не менее, нет смысла использовать криптографию с открытым ключом. Поскольку сторона приложения – это то, что могут интересовать спуферы, у них уже будет доступ к более ценной половине пары ключей. Таким образом, вы можете использовать некоторый подход, используя общий секрет.
То, что вы действительно хотите проверить, это аутентичность передаваемых данных. Поэтому просто возьмите ядро этих данных (т. Е. Все поля, которые действительно имеют значение), объедините их с общим секретом, хэш-результат и передайте его как дайджест сообщений. Сервер выполняет тот же расчет и проверяет, соответствует ли вычисленный дайджест переданному. Если это так, отправитель этого сообщения должен знать общий секрет.
Есть еще шанс для повторной атаки, т. Е. Кто-то записывает действительное сообщение и повторяет его позже. Вы можете обнаружить точные дубликаты на стороне сервера и предотвратить задержку воспроизведения, включив отметку времени в подписанной части сообщения. Если ваш сервер допускает огромную разницу между временными метками клиента и сервера, он должен будет хранить повторяющуюся информацию за тот же самый промежуток времени. Если он принимает только небольшие различия, он может работать с меньшим дубликатным кешем, но пользователи с неконфигурированными устройствами могут быть раздражены, так как сервер с большей вероятностью отклонит их запросы как слишком старые.
Еще одно замечание: вы писали о запросе GET вызывающем запись в некоторый файл. Я бы всегда ассоциировал некоторую операцию изменения состояния с POST . Если приложение является вашим собственным, это не имеет значения, но браузеры, как известно, повторно передают запросы GET не спрашивая пользователя, тем самым вызывая повторяющиеся запросы на некоторые действия.
Нет гарантийного метода. Вы можете использовать аутентификацию oauth … В зависимости от того, какую платформу вы используете и как развертывание приложения на телефоне, возможно, вы можете скомпилировать свой ключ в самом приложении? Все, что угодно и всегда может быть взломано, нет 100% безопасности … Но не стыдно в попытке. 🙂
Лично, что я использую для своих мобильных приложений, это проверка подлинности RESTful с обычной паролей входа / прохода на основе токена, до истечения срока ее действия. 🙂
HTTP-запросы могут быть созданы персонажем по символу любым способом, который хочет отправитель. Spoofing всегда будет возможно.
Просто добавьте авторизацию (логины, пароли, сеансы и т. Д. И / или «ключи API») в свое приложение PHP, а затем пусть ваше приложение телефона сначала авторизуется перед отправкой необходимых запросов. Вы, вероятно, не считали это, потому что, если ваш сценарий прост, что может добавить к нему какой-то беспорядок, но опять-таки почти каждая веб-система нуждается в этом, и вы тоже столкнетесь с этим.
Позвольте вам подключить приложение для входа в ваше приложение PHP через HTTPS, чтобы исключить перехват.