¿Cómo restringir el acceso a un archivo PHP?

Me gustaría restringir el acceso a un archivo PHP en mi servidor. Este archivo PHP toma los datos de una solicitud HTTP GET y los agrega a un archivo. Sencillo. Pero no quiero que se ejecute este archivo PHP a menos que la solicitud HTTP se genere desde la aplicación de teléfono inteligente que he desarrollado.

No quiero autenticar a cada usuario individualmente. Quiero que mi aplicación, y solo mi aplicación, pueda enviar la solicitud al archivo PHP. No quiero que las personas escriban una solicitud similar (http://www.mydomain.com/check.php?string=blahblahblah) en un navegador y tengan el mismo impacto.

He pensado en comprobar HTTP_USER_AGENT o alguna otra variable, pero me temo que también podrían ser fáciles de engañar. Podría insertar una clave en mi aplicación que busco, pero esa clave también podría verse comprometida.

El siguiente paso sería hacer que el servidor me envíe un desafío al cual respondo apropiadamente. O incluso podría mirar dentro de PKI. Pero, ¿cuál es una manera relativamente fácil de hacer esto, dado que no estoy tratando de proteger nada de valor real, solo para evitar el vandalismo menor?

¿Estoy tratando de reinventar la rueda aquí? ¿Ya hay una manera fácil y comprobada de hacer esto?

FWIW, este es el método más seguro que puedo pensar sin afectar seriamente el rendimiento, esencialmente el modo REST (ish), ya que para boostlo requeriría múltiples solicitudes y la información de estado de conexión almacenada en el servidor:

  • La aplicación y el servidor tienen una cadena de sal idéntica codificada, única para cada versión sucesiva de la aplicación móvil. Esta cadena debe mantenerse privada.
  • Cuando un usuario instala la aplicación en su dispositivo, la aplicación contacta con su servidor y le informa la versión de la aplicación y el IMEI del dispositivo, que las API de la plataforma móvil con la que está trabajando deben permitirle recuperar.
  • El servidor genera una clave única para esa instancia de la aplicación que se envía de vuelta a la aplicación y se almacena en el dispositivo, y la almacena en la base de datos del servidor con el IMEI y la versión instalada.
  • Durante la operación diaria (es decir, al realizar la solicitud que se detalla en la pregunta), la aplicación sigue este procedimiento:
    • Recupere la siguiente información:
      1. Dispositivo IMEI
      2. Clave de la aplicación
      3. Version de aplicacion
      4. Cuerda de sal codificada
      5. Cadena generada aleatoriamente para sal adicional (derivada de la marca de tiempo actual con microsegundos siempre es buena para una cantidad razonable de entropía).
    • Concatenar todas estas piezas de información juntas, preferiblemente con un relleno rígido entre ellas y producir un hash de la cadena resultante.
    • Envíe al servidor los siguientes datos junto con los datos de la solicitud real (tal vez en las cookies para obtener un poco más de seguridad):
      1. Hash generado
      2. Clave de la aplicación
      3. Cadena generada aleatoriamente utilizada como sal adicional
  • El servidor ahora usa la clave de la aplicación para recuperar el IMEI del dispositivo y la versión de la aplicación de esa instancia de la base de datos, y usa esa información junto con la cadena de sal codificada para la ID de la versión y la cadena de sal adicional enviada por el dispositivo para construir el picadillo. Si el hash generado en el servidor coincide con el hash generado por el dispositivo móvil, la solicitud es buena, si no la rechaza.
  • Toda la comunicación en este proceso es a través de HTTPS.

Para poder romper este sistema y falsificar una solicitud, un atacante debería saber lo siguiente:

  1. Dispositivo IMEI
  2. Clave de la aplicación
  3. Version de aplicacion
  4. Sal codificada
  5. El mecanismo que usa para generar el hash (el formato preciso de la cadena de entrada y el algoritmo hash).

Obviamente, si está trabajando con el dispositivo móvil, 1 – 3 son fáciles de extraer, pero 4 y 5 no se pueden encontrar sin ingeniería inversa de la aplicación (que literalmente no se puede hacer nada para prevenir, para personas con el conocimiento y la paciencia para hazlo).

Un ataque de hombre en el medio sería básicamente imposible, incluso después de romper el SSL (que no es trivial, por decir lo menos) y la ingeniería inversa de la aplicación para obtener 4 y 5, 1-3 no se puede recuperar sin un ataque de fuerza bruta sobre el hash, que es lo suficientemente complejo como para tardar varios cientos de millones de años (ver esta página para ver cómo llegué a esa figura), especialmente si uno de los tres es de longitud variable, lo cual la cadena de la versión de la aplicación podría ser fácilmente.

Define una sal en tu aplicación y en tu archivo php, luego hash esa sal combinada con la hora actual. Es poco probable que alguna vez se engañe.

$hash = sha1(time() . 'bladieblasalt'); if($_GET['hash'] == sha1(time() . 'samehash')) { echo 'valid'; } 

En primer lugar, debería implementar ssl en su aplicación, de lo contrario, alguien con poco conocimiento podría simplemente tener allí un teléfono conectado allí wifi y husmear el tráfico entre la aplicación y su sitio con wireshark o cain y abel ect. y obtener la url y cualquier parámetro aprobado, sin necesidad de desmontar nada.

La aplicación se conecta a su sitio y los registros de usuario, ya sea que sea un invitado o un miembro, su servidor le asigna a la aplicación un ID de solicitud y esta clave / token se pasa junto con cada solicitud y se valida en una sesión en su servidor.

El token se vería así: UNIQUE_REQUEST_ID_ASSIGNED_BY_SERVER:APPsIP:APPsTIME Encripta esta cadena y $_GET['token'] como $_GET['token']

Luego en su servidor descifre la cadena y explode() la cadena en sus partes y verifique contra una base de datos o sesión que la solicitud ID, IP y el tiempo coincidan con ect, si todo está bien, haga cualquiera.

Al igual que un sistema de inicio de sesión seguro, asigne una sal única para cada usuario y almacénela junto con la id. De solicitud de los usuarios.

En resumidas cuentas, solo dificulta que un abusador abuse del sistema. El 99% de las personas ni siquiera piensa en tocar el violín y el otro 1% lo bloquea ips.

Si no quiere nada por usuario, sino solo por aplicación, tendrá que confiar en un secreto integrado en la aplicación. Cualquiera que desmonte la aplicación finalmente podrá encontrarlo, por lo que cierta ofuscación podría ayudar, pero no mantendrá a determinadas personas fuera de su página.

Dicho esto, no tiene mucho sentido usar cualquier clave pública de cifrado. Como la aplicación es lo que podrían interesar a los spoofers, ya tendrían acceso a la mitad más valiosa de un par de claves. Así que también podrías usar algún método usando un secreto compartido.

Lo que realmente desea verificar es la autenticidad de los datos transferidos. Así que simplemente tome el núcleo de esa información (es decir, todos los campos que realmente importan), concatenézcalos con el secreto compartido, elimine el resultado y transfiéralo como un resumen del mensaje. El servidor realiza el mismo cálculo y verifica que el resumen computado coincide con el transferido. Si lo hace, el remitente de ese mensaje debe haber conocido el secreto compartido.

Todavía hay alguna posibilidad de un ataque de repetición, es decir, que alguien grabe un mensaje válido y lo repita más adelante. Puede detectar duplicados exactos en el lado del servidor y evitar la reproducción retrasada al incluir una marca de tiempo en la parte firmada del mensaje. Si su servidor permite una gran diferencia entre las marcas de tiempo del cliente y del servidor, tendrá que mantener la información duplicada durante la misma cantidad de tiempo. Si solo acepta pequeñas diferencias, puede funcionar con un caché duplicado más pequeño, pero los usuarios con dispositivos mal configurados pueden sentirse molestos, ya que es más probable que el servidor rechace sus solicitudes por ser demasiado antiguas.

Una nota más: escribiste sobre una solicitud GET causaba una escritura en algún archivo. Siempre asociaría alguna operación de cambio de estado con una POST . Si la aplicación es suya, no importa mucho, pero se sabe que los navegadores retransmiten las solicitudes GET sin preguntar al usuario, lo que provoca solicitudes duplicadas para alguna acción.

No hay un método de garantía. Puede usar la autenticación de Oauth … Dependiendo de la plataforma que use y cómo despliegue la aplicación en el teléfono, ¿tal vez puede comstackr la clave en la aplicación? Cualquier cosa puede y siempre se resquebrajará, no hay 100% de seguridad … Pero no hay vergüenza en el bash. 🙂

Personalmente, lo que utilizo para mis aplicaciones móviles es la autenticación RESTful con el inicio de sesión / par regular la comunicación basada en token hasta que caduque. 🙂

Las solicitudes HTTP pueden crearse carácter por carácter de la forma que el remitente desee. La suplantación siempre será posible.

Simplemente agregue autorización (inicios de sesión, contraseñas, sesiones, etc. y / o “claves API”) a su aplicación PHP y luego permita que su aplicación de teléfono autorice primero antes de enviar las solicitudes necesarias. Es probable que no lo hayas considerado porque si tu script es simple puede agregar algo de desorden a él, pero de nuevo casi todos los sistemas web lo necesitan, y eventualmente lo enfrentarás.

Permita que la aplicación del teléfono inicie sesión en su aplicación PHP a través de HTTPS para excluir la intercepción.