2011-03-21 13 views
7

Tengo un sitio que puede recibir solicitudes de varios sitios. Algo así como un cheque de actualización. Estos sitios enviarán información como nombres de usuario, contraseñas, versión de la aplicación, etc., luego mi sitio enviará una respuesta basada en esta información.PHP - Pasar datos de un sitio a otro sitio de forma segura

Básicamente se trata de una solicitud $_GET, algo así como:

http://www.mysite.com/?user=boo&password=foo&version=4

me preguntaba si no habría ningún problema de seguridad que hacen cosas como esta. ¿Podrían estos datos ser "interceptados" de alguna manera?

+0

es posible que tenga en cuenta el hash/salt. es decir, los clientes solicitan el uso de una contraseña hash que es hash de nuevo utilizando una sal que solo su servidor conoce. –

+0

Este es el tipo de pregunta que sería perfecto para http://area51.stackexchange.com/proposals/12123/webservice-apis – Cyclone

Respuesta

8

Bueno, recomiendo no enviando el nombre de usuario/contraseña a través de texto sin formato bajo ninguna circunstancia (incluso cuando se encuentre bajo SSL). En cambio, sugeriría usar una forma de autenticación Digest.

En su lugar, sugeriría generar un token de autenticación grande (una cadena aleatoria de gran tamaño, 128 caracteres). Luego, los usuarios instalarían este "token" en su aplicación.

Ahora, cuando la aplicación busca actualizaciones, primero activa una solicitud a su servidor solicitando un token de resumen. Este es un token de uso aleatorio que se usa solo una vez para una sola solicitud. Su aplicación debe generar un token, almacenarlo en un formato duradero (archivo, memoria, base de datos, etc.) junto con la marca de tiempo y luego devolverlo.

Ahora, su aplicación recibe este token de resumen (llamado $dt aquí). Luego, lo haces con el token de autenticación preconfigurado que ya se proporcionó.

$authBit = $username . ':' . $authToken; 
$hash = hash_hmac('sha256', $authBit, $digestToken); 
$authField = $username . ':' . $hash . ':' . $digestToken; 

A continuación, enviar el $authField al servidor.El servidor entonces dividir las partes:

list ($user, $hash, $digestToken) = explode(':', $authField); 

Ahora, por primera vez las operaciones de búsqueda token de autenticación del usuario en la base de datos y almacenarlo en $authToken. A continuación, busque el $digestToken para asegurarse de que existe y que se creó hace menos de 60 segundos (puede ajustarlo si es demasiado corto, pero no lo hace mucho más). De cualquier manera, elimínelo de la base de datos en este punto (para evitar que se reutilice).

Ahora, si el $digestToken existe y es válida, y se puede encontrar una $authToken, a continuación, sólo hacer la siguiente comprobación:

$stub = $user . ':' . $authToken; 
if ($hash == hash_hmac('sha256', $stub, $digestToken)) { 
    //valid user 
} else { 
    //Not valid 
} 

Tiene la ventaja de cambiar el testigo de todos y petición http nunca sola enviado (cualquiera que lea la secuencia de solicitud no podrá obtener ninguna información sensible de la solicitud, que no sea el nombre de usuario que podría enmascarar si lo desea) ...

-2

Utilice .htaccess para modificar y ocultar la URL de su sitio web. por ejemplo:

www.mysite.com/index.php?cat=1234&foo=5678 

se busca como:

www.mysite.com/cat-1234-foo-5678-index.html 

cuando u crear correctamente el archivo .htaccess, tanto las direcciones URL actuar de la misma.

+2

Esto no agrega ninguna protección valiosa, toda la información todavía está disponible. Puede ser un poco más difícil de encontrar, pero no hay una protección real. – Nico

+0

esto fue solo un compañero de demostración. puede codificar los valores y variables de acuerdo con cualquiera de los algoritmos que desee. –

+0

la url también se puede diseñar, por ejemplo: http://www.mysite.com/dbu4321gpp8765cheapdata.html –

2

Security trough obscurity no funciona, y usar POST en lugar de GET solo hace que la información sea un poco más difícil de arrebatar si realmente está mirando al usuario por encima del hombro.

El verdadero problema aquí es evitar que las personas intercepten el tráfico en tránsito entre los servidores. La única forma de lidiar con eso es el cifrado, como SSL. Es una buena idea tratar de usar SSL siempre que esté transmitiendo información confidencial como contraseñas. Esto puede ser un poco más difícil de implementar, pero definitivamente vale la pena en términos de seguridad.

Sin embargo, la mejor manera de evitar que se arrebaten los datos confidenciales es no transmitirlos en primer lugar. Considere si es una opción que su aplicación busque actualizaciones sin transmitir una contraseña. Si hay una actualización disponible, puede enviar al usuario a una página web usando HTTPS para descargar la actualización, lo que le ahorra la molestia de implementar SSL usted mismo.

Cuestiones relacionadas