none
Error al recibir datos HTTP Post URL a un Default.aspx. Texto con simbolos <>/...Framework 4 RRS feed

  • Pregunta

  • Hola

    Tengo una aplicacion (en VS2013 Framework 4) que envia datos URL Post a un Default.aspx alojado en un hosting.

    Al enviar los datos primero los codifico "URLEncode" los datos antes de enviar el Post.

    Todo funciona muy bien, pero el problema esta cuando en el texto original uso por ejemplo estos caracteres: < > y luego

    envio por http al Default.aspx

    Ejemplo texto original:

    mail= miMail@

    nombre=<MiNombre>

    texto= Algo de texto

    Ejemplo de la cadena ya codificada (URLEncode) para enviar el http post

    http://miSitioWeb/Default.aspx?mail=miMail%40&nombre=%3CMiNombre%3E&texto=Algo%20de%20texto

    Error:

    Entiendo que los simbolos "extraños" como <, >, /, etc... pueden entenderse como peligrosos, pero al codificar antes de enviar el Post no tendrìa que dar problemas ya que el simbolo "<" lo codifica como "%3C". Entonces no entiendo que puede estar pasando?

    He visto que tendrìa que configurar algo en el web.config, pero sinceramente no tengo mucha experiencia. 

    Por favor alguna ayuda...

    sábado, 19 de marzo de 2016 0:44

Respuestas

  • Lo que está pasando es que aunque uses el UrlEncode, el servidor de destino hace un Decode antes de revisar la cadena para ver si tiene algún carácter peligroso. En cuanto se encuentra el "<" presume que estás intentando hacer un ataque de inyección de scripts, y en consecuencia rechaza la petición como peligrosa.

    Si tienes la posibilidad de modificar la aplicación de destino, puedes deshabilitar esa validación poniendo ValidateRequest="False" en el @Page (y <httpRuntimerequestValidationMode="2.0"/> en el web.config). Pero si haces esto, asegúrate de que añades código para verificar que los datos que te llegan son legítimos, no vaya a ser que realmente alguien te envíe un ataque de inyección de scripts.

    • Marcado como respuesta Fabianuy martes, 22 de marzo de 2016 7:12
    domingo, 20 de marzo de 2016 13:11

Todas las respuestas

  • Lo que está pasando es que aunque uses el UrlEncode, el servidor de destino hace un Decode antes de revisar la cadena para ver si tiene algún carácter peligroso. En cuanto se encuentra el "<" presume que estás intentando hacer un ataque de inyección de scripts, y en consecuencia rechaza la petición como peligrosa.

    Si tienes la posibilidad de modificar la aplicación de destino, puedes deshabilitar esa validación poniendo ValidateRequest="False" en el @Page (y <httpRuntimerequestValidationMode="2.0"/> en el web.config). Pero si haces esto, asegúrate de que añades código para verificar que los datos que te llegan son legítimos, no vaya a ser que realmente alguien te envíe un ataque de inyección de scripts.

    • Marcado como respuesta Fabianuy martes, 22 de marzo de 2016 7:12
    domingo, 20 de marzo de 2016 13:11
  • Gracias Alberto por buena respuesta.

    Quizas sea mejor poner un filtro en mi aplicación para que los usuarios cuando ingresan "texto" no introduzcan caracteres que luego el servidor de destino los interprete como peligroso.

    Preguntarte si a demás del caracter "<", cuales son los otros caracteres que el web.config lo interprete como "peligroso" y me de un error al compilar?

    Aprovecho para mostrar mi web.config, para que me den su recomendación y si así como está es suficiente como para no tener problemas con ataques ajenos a mi aplicación:

    <?xml version="1.0"?>
    <!--
      For more information on how to configure your ASP.NET application, please visit
      http://go.microsoft.com/fwlink/?LinkId=169433
      -->
    <configuration>
        <system.web>         
        <compilation debug="true" strict="false" explicit="true" targetFramework="4.0">
        </compilation>

          <globalization
          fileEncoding="utf-8" requestEncoding="utf-8" responseEncoding="utf-8"
        />
          
      </system.web>
      <system.webServer>
        <httpProtocol>
          <customHeaders>
            <add name="access-control-allow-origin" value="*"/>
          </customHeaders>
        </httpProtocol>
      </system.webServer>
        
      <system.serviceModel>
        <behaviors>
          <endpointBehaviors>
            <behavior name="ServiceAspNetAjaxBehavior">
              <enableWebScript />
            </behavior>
          </endpointBehaviors>
        </behaviors>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
          multipleSiteBindingsEnabled="true" />
        <services>
          <service name="Service">
            <endpoint address="" behaviorConfiguration="ServiceAspNetAjaxBehavior"
              binding="webHttpBinding" contract="Service" />
          </service>
        </services>
      </system.serviceModel>
    </configuration>

    Para explicar un poco, es una aplicación para teléfonos moviles la cual se comunica por peticiones (HTTP AJAX URL Post) con otra aplicación ASP.NET Framework 4, instalada en un hosting. Pues la codificación UTF-8 ya que esta abierta a cualquier idioma y acepta todos los caracteres de todas las lenguas (español, ingles, chino, ruso, ajpones, arabe, etc...). Por lo tanto va a estar expuesta a cualquier usuario que ingrese datos dentro de la aplicación.

    Espero me puedan dar una mano, gracias

    domingo, 20 de marzo de 2016 22:28
  • Los caracteres que te rechaza como "peligrosos" son ciertas combinaciones con < y >, y ciertos valores introducidos con #.

    En cuanto al web.config, lo único que le veo que deberías cambiar en producción es el debug="true", que conviene cambiar por false. No es por razones de seguridad, sino de rendimiento.

    Nótese que aunque el web.config esté bien, eso no quiere decir que estés a salvo de cualquier tipo de ataque. Hay muchas cosas que las tienes que tener bien controladas en tu propio código, como por ejemplo los ataques de inyección de SQL o los de falsificación de peticiones inter-sitios (CSRF).

    lunes, 21 de marzo de 2016 8:19
  • Hola Alberto,

    Voy a buscar en la web como proteger mi aplicación por lo que tu recomiendas ( ataques CSRF)

    Por lo que pude testear, también salta el error cuando introduzco la barra / con cierto codigo.

    He decidido filtrar los caracteres <,>,/,#, para no tener mayores problemas y dejar 

    Creo que este tema ya esta resuelto gracias a tus respuestas.

    Ahora en mas queda investigar sobre como puedo proteger un poco mas mi aplicación.

    Antes quería mostrarte el script/source de mi Default.aspx, para que me des tu comentario y recomendación:

    <%@ Page Language="VB" ContentType="text/plain" ResponseEncoding="utf-8" AutoEventWireup="true" 
        CodeBehind="~/Default.aspx" CodeFile="Default.aspx.vb" Inherits="_Default" %>

    Desde ya muchas gracias.

    lunes, 21 de marzo de 2016 21:32
  • Bueno, realmente la cabecera del Default.aspx no dice mucho. Es más o menos estándar, salvo lo del ContentType="text/plain" que es poco usual. Aunque desde luego es factible devolver texto plano desde un .aspx, típicamente este tipo de páginas devuelven html; para un texto plano normalmente usarías un .ashx que es más simple y tiene mayor rendimiento si no se necesitan postbacks.
    martes, 22 de marzo de 2016 7:48
  • Solo uso el .aspx para comunicarme mediante peticiones HTTP.

    Por ejemplo desde las aplicaciónes de los usuarios envío la siguiente cadena:

    http://miSitioWeb/Default.aspx?usuario=Juan&mail=juan@juan.com&clave=1234&pais=sp&requerimiento=Login

    Esto lo recibe la aplicación en ASP.NET, tomo los datos mediante el Request.QueryString y lo proceso.

    Luego respondo con un Response.Output.Write("LoginOK" & "|" & "Datos del usuario..." & "|")

    Entonces la aplicacion del usuario recibe datos del ASP.NET separados por el pipe "|" para poder procesar los datos también devueltos por el ASP.NET.

    Entonces el texto plano me sirve para que cuando voy a leer el .aspx este totalmente limpio. 

    Voy a probar con el GH .ashx que tu recomiendas. Por lo que pude ver en la web, es verdad que es mas rapido y eficiente para este tipo de casos. A parte por lo que vi podría implementar subir y descargar imagenes (este es otro de los requerimientos que necesita la empresa donde estoy trabajando...)

    Por ahora la idea es usar el ASP.NET para la comunicación por HTTP, POST, Request...

    A lo que me refiero es que no se trata de un sitio web, sino que solo uso la aplicacion ASP.NET en el hosting para la comunicación entre otra aplicación de usuarios y la base de datos que tengo instalada en el hosting.

    Si tienes algún consejo, ya sea de que puedas observar que estoy haciendo algo mal, etc., son muy bien venidos.



    • Editado Fabianuy miércoles, 23 de marzo de 2016 3:30 corrección gramatical
    miércoles, 23 de marzo de 2016 0:05
  • codifica los datos en base64 los envías por post (todo seria un solo campo) recibes el post decodificas y deserializas los valores
    jueves, 24 de marzo de 2016 0:08
  • Asi como lo dices suena simple.

    La verdad nunca he trabajado con imagenes en base64 (carga y descarga), pero voy a tomar en cuenta estos consejos. A penas me quite trabajo de encima voy a buscar info en la web.

    Muchas gracaias

    jueves, 24 de marzo de 2016 0:47