CVE-2023-45803

urllib3 es una librería cliente HTTP fácil de usar para Python. Anteriormente, urllib3 no eliminaba el cuerpo de la solicitud HTTP cuando una respuesta de redirección HTTP usaba el estado 301, 302 o 303 después de que la solicitud cambiara su método de uno que pudiera aceptar un cuerpo de solicitud (como `POST`) a `GET` tal como está. requerido por los RFC HTTP. Aunque este comportamiento no se especifica en la sección de redirecciones, se puede inferir reuniendo información de diferentes secciones y hemos observado el comportamiento en otras implementaciones importantes de clientes HTTP como curl y navegadores web. Debido a que la vulnerabilidad requiere que un servicio previamente confiable se vea comprometido para tener un impacto en la confidencialidad, creemos que la explotabilidad de esta vulnerabilidad es baja. Además, muchos usuarios no colocan datos confidenciales en los cuerpos de solicitud HTTP; si este es el caso, entonces esta vulnerabilidad no es explotable. Las dos condiciones siguientes deben ser ciertas para verse afectado por esta vulnerabilidad: 1. Usar urllib3 y enviar información confidencial en el cuerpo de la solicitud HTTP (como datos de formulario o JSON) y 2. El servicio de origen está comprometido y comienza a redireccionar usando 301. 302 o 303 a un par malicioso o el servicio redirigido se ve comprometido. Este problema se solucionó en las versiones 1.26.18 y 2.0.7 y se recomienda a los usuarios que actualicen para resolverlo. Los usuarios que no puedan actualizar deben deshabilitar los redireccionamientos para servicios que no esperan responder con redireccionamientos con `redirects=False` y deshabilitar los redireccionamientos automáticos con `redirects=False` y manejar los redireccionamientos 301, 302 y 303 manualmente eliminando el cuerpo de la solicitud HTTP.

A flaw was found in urllib3, an HTTP client library for Python. urllib3 doesn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303, after changing the method in a request from one that could accept a request body such as `POST` to `GET`, as is required by HTTP RFCs. This issue requires a previously trusted service to become compromised in order to have an impact on confidentiality, therefore, the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies; if this is the case, this vulnerability isn't exploitable.