Puedes hacer que un usuario envíe una solicitud HTTP POST al puerto 9100 de varias IPs tratando de alcanzar un puerto de impresión en bruto abierto. Si se encuentra, el **encabezado HTTP se imprime como texto plano o se descarta** según la configuración de la impresora. Sin embargo, los **datos POST** pueden **contener** trabajos de impresión arbitrarios como comandos **PostScript** o **PJL** para ser **interpretados**.
Puedes usar objetos JavaScript XMLHttpRequest (XHR) según se define en para realizar solicitudes HTTP POST a impresoras internas. Una limitación del enfoque de impresión entre sitios discutido hasta ahora es que **los datos solo se pueden enviar al dispositivo**, **no se pueden recibir** debido a la política de mismo origen. Para **doblar** las **restricciones** de la política de mismo origen, puedes hacer que el **servidor** responda con una respuesta HTTP falsa pero **válida** que permita solicitudes CORS (incluyendo `Access-Control-Allow-Origin=*`). Se muestra una descripción esquemática del ataque a continuación:
En una variante mejorada de XSP - combinada con falsificación de CORS - un atacante web tiene acceso completo a la respuesta HTTP, lo que le permite extraer información arbitraria como trabajos de impresión capturados del dispositivo de impresora. Se muestra a continuación un fragmento de código JavaScript de prueba de concepto:
Tenga en cuenta que **PCL** como lenguaje de descripción de página no es aplicable para el spoofing de CORS porque solo permite que se **repita** un **número único**. **PJL tampoco** se puede usar porque, desafortunadamente, agrega `@PJL ECHO` a todas las cadenas repetidas, lo que hace imposible simular un encabezado HTTP válido. Esto, sin embargo, no significa que los ataques **XSP mejorados** estén **limitados** a trabajos de **PostScript**: PostScript se puede usar para responder con un encabezado HTTP falsificado y **el** [**UEL**](./#uel)**se puede invocar para cambiar el lenguaje de la impresora**. De esta manera, un atacante web también puede obtener los resultados de los comandos PJL. Existen dos problemas de implementación que merecen ser mencionados: en primer lugar, se debe determinar un `Content-Length` correcto para los datos que se van a responder con PostScript. Si el atacante no puede predecir el tamaño total de la respuesta y la codificación por fragmentos tampoco es una opción, debe establecer un valor muy alto y usar relleno. En segundo lugar, agregar el campo de encabezado `Connection: close` es importante, de lo contrario, las conexiones HTTP/1.1 se mantienen activas hasta que el cliente web o el dispositivo de impresora activa un tiempo de espera, lo que significa que la impresora no estará accesible durante algún tiempo.
**Si** el dispositivo de impresora admite la **impresión de texto plano**, el encabezado de la **solicitud HTTP** del XHR se imprime como copia impresa, incluido el campo de encabezado `Origin` que contiene la URL que invocó el JavaScript malicioso, lo que hace que sea **difícil** para un atacante **mantenerse en silencio**. Esto es inevitable, ya que no obtenemos control sobre la impresora, y en algunas circunstancias se puede desactivar la funcionalidad de impresión, hasta que el cuerpo HTTP se procesa y el encabezado HTTP ya ha sido interpretado como texto plano por el dispositivo de impresora. Si reducir el ruido es una prioridad, el atacante puede intentar **desactivar primero la funcionalidad de impresión** con comandos PJL propietarios como se propone en [PJL jobmedia](http://hacking-printers.net/wiki/index.php/Document\_processing#PJL\_jobmedia) utilizando otros posibles canales XSP como IPP, LPD, FTP o el servidor web integrado de la impresora. Si bien se pudieron probar con éxito todos los protocolos para implementar trabajos de impresión utilizando variantes de scripting entre protocolos, tienen algunas desventajas más allá de no proporcionar comentarios utilizando encabezados CORS falsificados:
* El acceso entre protocolos a los puertos LPD y FTP está bloqueado por varios navegadores web.
* Los parámetros para la impresión directa sobre el servidor web integrado son específicos del modelo.
* El estándar IPP requiere que el `Content-type` para las solicitudes HTTP POST se establezca en `application/ipp`, lo que no se puede hacer con objetos XHR; sin embargo, depende de la implementación si realmente le importa los tipos incorrectos.
Un problema importante de XSP es **encontrar** la **dirección correcta** o el nombre de host de la **impresora**. Nuestro enfoque es **abusar de WebRTC**, que está implementado en la mayoría de los navegadores modernos y tiene la función de enumerar direcciones IP para interfaces de red locales. Dada la dirección IP local, se utilizan objetos XHR para abrir conexiones al puerto **9100/tcp** para las 253 direcciones restantes para recuperar el nombre del producto de la impresora utilizando PostScript y el spoofing de CORS, lo que solo lleva segundos en nuestras pruebas. Si la impresora está en la misma subred que el host de la víctima, su dirección se puede detectar únicamente con JavaScript. WebRTC está en desarrollo para Safari y es compatible con las versiones actuales de Firefox, Chrome y Microsoft Edge. Internet Explorer no tiene soporte para WebRTC, pero VBScript y Java también se pueden usar para filtrar la dirección IP local. Si no se puede recuperar la dirección de la interfaz local, aplicamos un enfoque de fuerza bruta inteligente: intentamos conectarnos al puerto 80 del enrutador de la víctima utilizando objetos XHR. Para esto, se compiló una lista de 115 direcciones de enrutador predeterminadas de varios recursos accesibles a través de Internet. Si se puede acceder a un enrutador, escaneamos la subred en busca de impresoras como se describe anteriormente.
Una implementación de prueba de concepto que demuestra que los ataques avanzados de impresión entre sitios cruzados son prácticos y una amenaza real para empresas e instituciones está disponible en [hacking-printers.net/xsp/](http://hacking-printers.net/xsp/)
