¿Cómo evito alterar los datos de envío del formulario y cambiar los detalles de cualquier cuenta?

1

Aunque esto es algo que solo los empleados pueden usar, me gustaría evitar la manipulación de todos modos. No me gusta el código inseguro, y esto es terriblemente inseguro.

Aquí hay un enlace de ejemplo:

<a href="#' + j.id + '" onclick="LoadThis(\'Test.aspx?id=' + obj.id + '\', \'post\', null, null);">Edit User #' + j.id + '.</a>

Envié esto al lado del cliente usando jQuery:

$.ajax({
    url: "Test.aspx/RemoveUsernameByID",
    type: "POST",
    data: 1,
    beforeSend: function (before) { /* do stuff */ },
    success: function (success) { /* do stuff */ },
    error: function (error) { /* do stuff */ }
});

... y asegúrate de usar SqlCommand.Parameters.Add() para evitar cosas malas:

    [WebMethod]
    public static void RemoveUsernameByID(int derp)
    {
        string ConnectionString = "Data Source=herp;Initial Catalog=derp;Integrated Security=True";
        string QueryString = @"DELETE FROM [Herp] where [uid] = @derp";


        using (SqlConnection con = new SqlConnection(ConnectionString))
        using (SqlCommand cmd = new SqlCommand(QueryString, con)) 
        {
            con.Open();
            cmd.Parameters.Add("@derp", SqlDbType.Int).Value = derp;
            cmd.ExecuteNonQuery();
        }
    }

Ahora, como puedes ver, esto es hilarantemente malo. Puedo manipular el ID en data: 1 y devolver cualquier número al servidor web para eliminar a cualquier usuario que desee, por su ID. Al usar este tipo de código, puedo hacerme administrador, eliminar cualquier usuario que desee, recopilar información que no debería poder hacer, etc.

He pensado en solicitar y devolver un montón de información adicional, como los nombres y apellidos del usuario o una guía única, pero todo lo que alguien tiene que hacer es detectar esta información, que acabo de hacer. ! - y recolecta para que puedan seguir haciendo lo que quieran.

¿Qué debo hacer?

    
pregunta heh 13.02.2015 - 19:39
fuente

1 respuesta

1

Esto se parece más a una vulnerabilidad Direct Object Reference que una vulnerabilidad de Inyección SQL.

La forma correcta de asegurar esto sería verificar que la sesión actual tenga permisos para realizar la acción solicitada en el lado del servidor. Los detalles de cómo esto no funcionaría dependen de cómo haya implementado la autorización en su aplicación, pero leer la sección de prevención del enlace que proporcioné debería ser un buen comienzo.

    
respondido por el Abe Miessler 13.02.2015 - 19:46
fuente

Lea otras preguntas en las etiquetas