2012-04-05 13 views
13

Estoy compilando una APIS RESTful JSON y estoy preocupado por json data theft y Cross-Site Request Forgery.Compatibilidad del encabezado HTTP "Origen" para imponer restricciones

Una buena solución que se creó para abordar estos dos problemas es el Origin http header. Sin embargo, me preocupa que este método no sea compatible con todos los navegadores modernos. ¿Es esta una preocupación valida? ¿El encabezado http de origen es inútil debido a problemas de compatibilidad? ¿Debería considerarse el origen al realizar un HTTP referer check?

+0

El origen es bueno, también es recomendable que haga una copia de seguridad del host porque ese es un encabezado Las extensiones de Chrome no pueden modificarse - http://code.google.com/chrome/extensions/webRequest.html#life_cycle_footnote –

+0

@Devin G Rhode Todos los encabezados http son triviales para falsificar, excepto en un ataque CSRF. Si un atacante puede instalar una extensión de Chrome en un navegador de víctimas, entonces hay problemas más grandes que CSRF. – rook

+1

@Rook Un atacante puede introducir código malicioso en una extensión (su propia extensión original, o cualquier fuente de código abierto), y esperar a que las personas la instalen. No necesariamente tiene que ser un ataque dirigido a un usuario/máquina específico para ser "útil". –

Respuesta

7

Aquí hay una lista de navegadores compatibles y problemas conocidos. Ahora le toca a usted si se puede vivir con estas limitaciones:

Can I use...

+0

este sitio falta mucho, incluyendo 'content-security-policy' y' x-frame-options' – rook

+0

En realidad, incluye content-security-policy: http://caniuse.com/contentsecuritypolicy/embed/ agents = mobile & eras = -3, y enlaces Para x-frame-options ir a: https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet –

2

Es una preocupación válida. Alguien podría estar usando un navegador más antiguo que no lo admite por completo. También puede haber un error en una versión beta.

También considere agregar X-Frame-Options: SAMEORIGIN a su API JSON para evitar que alguien incluya su sitio en un iframe.

Considere también anteponer sus respuestas JSON devueltas con caracteres especiales y eliminarlas manualmente en su decodificador JSON. Así es como Google lo hace: Why does Google prepend while(1); to their JSON responses?

Considere también, para mayor seguridad adicional, incluir un nonce para cada solicitud, y firme la solicitud para verificar que proviene de su código en lugar de un sitio de phishing. Esto es similar a cómo funciona OAuth1.0. Una alternativa es generar un token para cada sesión, que expira automáticamente, y actualizar el token cuando sea necesario. Así es como funciona OAuth2.0. Esto permite invalidar el acceso a pedido, por ejemplo, si encuentra un error, por lo que los clientes antiguos deben actualizar.

Cuestiones relacionadas