¿Debo prohibir GET para POST sin efectos secundarios de forma predeterminada?

Question

¿Debo prohibir GET para POST sin efectos secundarios de forma predeterminada?

#1 de Lie Ryan (2 votos)
#2 de Matthew (1 votos)

3

Si una página web es segura (sin efecto de servicio) pero usa los parámetros POST (para evitar cualquier problema de longitud de la URL), ¿debería prohibirse llamarla usando GET ? O ¿debería cada página tener algún tipo de "marcador" que indique que es seguro o inseguro , y prohíbe GET solo en inseguro ?

Lo primero conduce a un poco de refactorización aquí y allá para tener GET only y POST only pages (y no más "mix"), mientras que el segundo lleva a páginas potencialmente olvidadas (antiguas y próximas por nuevos desarrolladores) .

Leí la publicación relacionada " ¿Debo evitar el envío de solicitudes GET para las URL que normalmente se operan con la solicitud POST? " pero esa pregunta fue para inseguro POST , que obviamente es debe prohibir GET . Aquí, se trata de cómo manejar globalmente { safe POST que podría ser llamado por GET + safe GET + inseguro POST que no debe ser GET callable}.

http

pregunta Xenos 03.02.2017 - 11:15

fuente

2 respuestas

Lea otras preguntas en las etiquetas http

Comprobación del código de prueba de penetración por primera vez Sqlmap: omitir la seguridad del sitio web que filtra las palabras reservadas de SQL

score 2 · Answer 1

La distinción entre GET y POST no se trata solo de seguridad. En términos de REST (el principio subyacente de HTTP), el método GET es una operación "recuperar la información especificada en la URL", mientras que POST es un "hacer algo al recurso nombrado por la URL" o, a veces "realizar la operación nombrada por el URL "operación.

Si su operación es segura pero no es una recuperación de información, entonces es semánticamente incorrecto usar una operación GET. Si su recuperación de información requiere una consulta que no se ajuste al límite de longitud de la URL, probablemente necesite estructurar mejor sus datos para que sus consultas sean menos complejas, sus clientes apreciarían no tener que desplazarse por la compleja estructura de datos solo para recuperar la información. información que necesitan.

Tener el mismo recurso operado por múltiples métodos HTTP (una "mezcla") es muy común y se recomienda en REST. Cada método generalmente tiene una función diferente al recurso, por ejemplo, puede tener una API donde tiene PUT / transaction / 1 crea o actualiza una transacción no confirmada, PATCH / transaction / 1 programa acciones adicionales para una transacción no confirmada, mientras que POST / transaction / 1 ejecuta la transacción y la marca como confirmada, y GET / transaction / 1 para recuperar el detalle de la transacción.

Hay muchos casos, aunque no todos los métodos tienen sentido en un recurso. En ese caso, es probable que desee emitir una respuesta HTTP 405 Método no permitido.

¿Debería prohibir GET para POST sin efectos secundarios de forma predeterminada?

En general, no quieres. Que incluso pienses en hacerlo, generalmente indica que puedes tener un olor a diseño o puedes tener una API que no es REST.

score 1 · Answer 2

Como ha dicho, para las solicitudes POST seguras, no importa si también se puede acceder a ellas a través de las solicitudes GET. Sin embargo, esto introduce un problema de usabilidad desde el punto de vista de los desarrolladores. Deben poder determinar de manera confiable si una solicitud determinada es segura o no, y aplicar de manera consistente las reglas correctas a esas páginas.

Si no aplican correctamente una regla a una nueva página, o realizan una modificación que convierte una solicitud segura en una no segura en una página anterior sin actualizar las reglas, es posible que tenga problemas.

Por lo tanto, asegurarse de que todas las solicitudes POST se traten como "inseguras", incluso cuando pueden, en casos específicos, ser "seguro" es la opción a prueba de fallos. Le da a los desarrolladores una clasificación muy simple: si usa POST, no usa GET.

Esto podría implicar algo de refactorización en algunos casos, pero esto sería una tarea única, mientras que mantenerse actualizado con los cambios en las clasificaciones seguras / inseguras sería una tarea continua.