¿Es esta conexión de base de datos Perl vulnerable a la inyección SQL?

Question

¿Es esta conexión de base de datos Perl vulnerable a la inyección SQL?

#1 de Ludisposed (3 votos)
#2 de Sjoerd (2 votos)
#3 de LvB (2 votos)

3

Tengo esta consulta de la base de datos Perl (reducida), y me pregunto si esto puede ser explotado de alguna manera. Esto es un desafío, así que sé que las cosas podrían hacerse de manera diferente, la tarea es explotar esto.

Que yo sepa, utiliza declaraciones preparadas y, por lo tanto, es bastante seguro. Sin embargo, pude encontrar esto , con respecto a los problemas con la cita y el parámetro.

if ('POST' eq request_method && param('username') && param('password')){
    my $dbh = DBI->connect( "DBI:mysql:database_name","database_name", "<censored>", {'RaiseError' => 1});
    my $query="Select * FROM users where username =".$dbh->quote(param('username')) . " and password =".$dbh->quote(param('password')); 

    my $sth = $dbh->prepare($query);
    $sth->execute();
    my $ver = $sth->fetch();
    if ($ver){
        print "win!<br>";
        print "here is your result:<br>";
        print @$ver;
    }
    else{
        print "fail";
    }
    $sth->finish();
    $dbh->disconnect();
}

sql-injection perl

pregunta Ludisposed 18.12.2017 - 14:03

fuente

3 respuestas

3

Después de recrear el sitio web localmente y revisar los documentos

Sí

Este programa Perl es vulnerable a la inyección SQL.

Sin embargo, esto depende del controlador DBI, y solo podría reproducirlo con MySQL

Hay 2 fallas con esto en $dbh->quote(param('paramater'))

Verás, param es sensible al contexto. En el contexto escalar, si el parámetro tiene un solo valor (name=foo) , devuelve ese valor, y si el parámetro tiene múltiples valores (name=foo&name=bar) , devuelve un arrayref .

Desde el enlace SO , el problema con llamar directamente a param() es que puede devolver un array
Como un caso especial, los tipos numéricos estándar están optimizados para devolver $value sin llamar a type_info.

De los documentos DBI . La cotización de llamadas como list con SQL_INTEGER como segundo parámetro, devolverá un valor sin comillas.

Desde SQL_INTEGER == 4 Todo lo que tomó fue esta secuencia de comandos de python:

def vuln(url):
    params={"username": "valid_username", "password": ["'lol' or 1", 4]}
    print(requests.post(url, data=params).text)

respondido por el Ludisposed 20.12.2017 - 18:30

fuente

2

En General, es una mala idea usar las variables POST directamente (hay un cliente controlado después de todo). Es mejor hacer lo siguiente:

Limite el tamaño de la entrada para limitar los desbordamientos.
Analice el valor para asegurarse de que sea del tipo que espera.
Sanatice el parámetro para no incluir ninguna instrucción de control (no escapada), la cita hace la mayor parte de esto pero no todas (verifique las instrucciones para su versión de Perl)
Use declaraciones preparadas adecuadas (como sugiere @Marc)

Por lo demás, parece un buen enfoque, pero asegúrate de usar bibliotecas y software actualizados. (va para cualquier aplicación)

respondido por el LvB 18.12.2017 - 14:39

fuente

Lea otras preguntas en las etiquetas sql-injection perl

¿Los MCU (como los arduinos) se ven afectados por Meltdown? ¿Existe una versión base de jQuery que no tenga vulnerabilidad XSS?

score 2 · Accepted Answer

No es seguro, pero no creo que sea explotable.

El punto es que param puede devolver un escalar o una lista. En el contexto de la lista, si pasa username=a&username=b a esta página, la lista será ("a", "b").

En Perl, si pasas una lista a una función, se interpreta como argumentos separados.

quote("a", "b")

es equivalente a

@list = ("a", "b")
quote(@list)

Entonces, si llama a quote(param("username")) , el usuario puede suministrar el segundo parámetro a quote , pasando dos valores de username . Dado que el segundo parámetro determina cómo hacer la cotización, esto puede introducir una vulnerabilidad de inyección de SQL.

Sin embargo, la forma en que se maneja el segundo parámetro depende del controlador DBD, que es diferente para cada tipo de base de datos. Además, en realidad debería ser una referencia de hash, pero solo podemos pasar una cadena. Por lo tanto, puede ser que exista un controlador en el que pasar algo cambie la forma en que se realiza el escape, pero no pude encontrarlo. El controlador de Postgres, por ejemplo, declara explícitamente "El segundo argumento a citar debe ser un hashref".