none
Evitar CSS en MVC con AJAX RRS feed

  • Pregunta

  • Hola.

    estoy trabajando en una aplicacion MVC y utilizo $.AJAX y Jquery para hacer un simple CRUD sobre una base de datos SQL Server.

    En caso no utilizara Ajax, Jquery o JSON para hacer las operaciones, se que debo evitar ataques Cross Site Scripting utilizando en mis vistas el: Html.Encode(dato a mostrar), tambien se que debo utilizar el string username = AntiXssEncoder.HtmlEncode(datos.usuario, false); en mi controlador MVC.

    Mi pregunta es mas para conocer mas sobre el tema, hay alguna forma de proceder para evitar los ataques CSS al utilizar una función como esta tanto cuando mando los datos al controlador como cuando los muestro en un div(por ejemplo)

    submitHandler: function () {
       var forgeryId = $("#forgeryToken").val();
       var datos = {
        usuario: $("#usuario").val().trim(),
        password: $("#password").val().trim()
                };
    
     $.ajax({
        url: encodeURI('@Url.Action("Prueba","Prueba")'),
        dataType: "json",
        type: "POST",
        contentType: 'application/json; charset=utf-8',
        data: JSON.stringify(datos),
        processData: false,
        cache: false,
        headers: {
        'VerificationToken': forgeryId
                 },
        success: function (data) {
        $("#response").html(data);
                 },
        error: function (xhr) {
        alert(xhr.responseText);
                 }
    });


    pabletoreto

    lunes, 29 de junio de 2015 19:59

Respuestas

  • hola

    cuando planteate el tema de CSS pense que te referias a estilos de tu sitio

    hasta donde se el problema de cross site de produce cuando invocas desde un dominio diferente

    si la misma pagina invoca por ajax una funcionalidad no deberia tener problemas

    Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET Web API

    o te refieres a

    Enabling Cross-Origin Requests in ASP.NET Web API 2

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina


    lunes, 29 de junio de 2015 20:44
  • Puedes evitar que se inyecte un script en la página teniendo cuidado de codificar en el servidor los datos que devuelves al cliente. Es decir, el peligro se encuentra en el sitio en el que haces esto:

    $("#response").html(data)

    Ahí se toma lo que llegó en data y se incorpora al html de la página. Si ese "data" contuviese datos que previamente han sido introducidos por un usuario, entonces si ese usuario hubiese escrito tags de html, se podrían usar esos tags para "trucar" la página y "engañar" al usuario que la ve (incuyendo ejecutar scripts).

    El remedio es que, en la rutina donde el servidor ensambla esos datos para devolverlos (es decir en la acción Prueba/Prueba según el ejemplo que has puesto), cualquier dato que provenga de un usuario y en consecuencia no sea de plena confianza, se debe de pasar a través de Server.HtmlEncode para que se codifiquen sus tags de HTML y no sean interpretados por el cliente. Si la acción Prueba/Prueba devuelve una Vista parcial, y dentro de esa vista los datos se devuelven con @expresión, entonces no hace falta que hagas nada porque el @expresión ya hace que la expresión atraviese Server.HtmlEncode antes de incorporarla a la vista, y en consecuencia estás protegido contra los ataques por esta vía.

    • Marcado como respuesta pabletoreto miércoles, 1 de julio de 2015 2:49
    martes, 30 de junio de 2015 6:44

Todas las respuestas

  • hola

    cuando planteate el tema de CSS pense que te referias a estilos de tu sitio

    hasta donde se el problema de cross site de produce cuando invocas desde un dominio diferente

    si la misma pagina invoca por ajax una funcionalidad no deberia tener problemas

    Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET Web API

    o te refieres a

    Enabling Cross-Origin Requests in ASP.NET Web API 2

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina


    lunes, 29 de junio de 2015 20:44
  • Puedes evitar que se inyecte un script en la página teniendo cuidado de codificar en el servidor los datos que devuelves al cliente. Es decir, el peligro se encuentra en el sitio en el que haces esto:

    $("#response").html(data)

    Ahí se toma lo que llegó en data y se incorpora al html de la página. Si ese "data" contuviese datos que previamente han sido introducidos por un usuario, entonces si ese usuario hubiese escrito tags de html, se podrían usar esos tags para "trucar" la página y "engañar" al usuario que la ve (incuyendo ejecutar scripts).

    El remedio es que, en la rutina donde el servidor ensambla esos datos para devolverlos (es decir en la acción Prueba/Prueba según el ejemplo que has puesto), cualquier dato que provenga de un usuario y en consecuencia no sea de plena confianza, se debe de pasar a través de Server.HtmlEncode para que se codifiquen sus tags de HTML y no sean interpretados por el cliente. Si la acción Prueba/Prueba devuelve una Vista parcial, y dentro de esa vista los datos se devuelven con @expresión, entonces no hace falta que hagas nada porque el @expresión ya hace que la expresión atraviese Server.HtmlEncode antes de incorporarla a la vista, y en consecuencia estás protegido contra los ataques por esta vía.

    • Marcado como respuesta pabletoreto miércoles, 1 de julio de 2015 2:49
    martes, 30 de junio de 2015 6:44