SQL Injection Come iniettare URL puliti / a riposo

Naviga le tue risposte
9

Ho una domanda che spero tu mi possa aiutare?

URL non puliti: 

http://example.com/index.php?page=foo
http://example.com/products?category=2&pid=25
http://example.com/index.php?mod=profiles&id=193
http://example.com/kb/index.php?cat=8&id=41

Pulisci url (gli url equivalenti una volta che sono stati "puliti"): 

http://example.com/foo
http://example.com/products/2/25
http://example.com/profiles/193
http://example.com/kb/8/41

Spiegazione dell'URL pulito / non pulito qui

La mia domanda:

Come puoi vedere negli esempi di URL non puliti e puliti sopra, ovviamente sono leggermente diversi.

Con l'URL non pulito sarebbe possibile testare possibili vulnerabilità di SQL injection aggiungendo un apostrofo (') alla fine dell'URL e così via ...

ad esempio http://example.com/products?category=2&pid=25' e poi guardando le lunghezze di risposta che restituisce.

Sono consapevole che l'uso di url clean / rest non lo rende meno vulnerabile all'iniezione sql e viene principalmente utilizzato per SEO, usabilità e così via (anche se rende anche più difficile l'automazione sql strumenti di iniezione), ma come faresti a iniettare questi tipi di URL e c'è un metodo particolare, preferito / migliore da usare?

ad esempio, il seguente lavoro sarebbe utile per iniettare url puliti (usando un apostrofo)?

http://example.com/kb/8'/41

o

http://example.com/products/2'/25

o

http://example.com/services/legal/patents'

e così via ... o c'è un metodo preferito / migliore.

Il tuo aiuto con questa domanda sarebbe molto apprezzato, molte grazie

    
posta perl-user 22.02.2013 - 11:02
fonte

3 risposte

4

Secondo me, il problema principale quando un pentestore affronta un'applicazione web che usa URL puliti è identificare quali parti dell'URL sono risorse e quali parti sono parametri perché di solito i parametri sono ciò che testiamo più profondamente.

In questo caso, ritengo che l'opzione migliore sia testare tutte le parti degli URL assumendo che tutte le parti siano parametri: 

http://example.com/kb'/8/41
http://example.com/kb/8'/41
http://example.com/kb/8/41'

Il segno di spunta è solo un esempio, il caso è che tutte le parti (incluso kb che dovrebbe essere una risorsa ma potrebbe anche essere un parametro).

Se esiste un modo per differenziare le risorse e i parametri di testing della blackbox, mi piacerebbe saperlo.

    
risposta data 22.02.2013 - 18:22
fonte
5

Non esiste un test magico per il test di SQL injection. Alcune applicazioni potrebbero essere vulnerabili quando si utilizza un determinato approccio e altre quando si utilizza un altro.

C'è una possibilità che il collegamento "/ 41 non funzioni perché gli apostrofi sono bloccati da un IPS, ma mostra lo stesso risultato del link e questo ti darebbe l'informazione che c'è un problema lì.

Solo test con le virgolette è un po 'meglio di non testare affatto, ma non può essere etichettato come valutazione di sicurezza. Tale processo implica una valutazione complessa di tutti i punti di ingresso possibili nella tua applicazione (parametri, cookie, intestazioni, ecc.) E molti altri test più complessi.

Se hai la possibilità, la soluzione migliore è utilizzare un approccio white box e rivedere il codice. In questo modo puoi vedere chiaramente se un determinato parametro è correttamente sterilizzato o meno.

    
risposta data 22.02.2013 - 13:50
fonte
3

Gli URL puliti possono essere implementati in modo diverso e quindi dipende dal sistema utilizzato. Ad esempio con le regole di riscrittura nel server web: 

url.rewrite-final = (
  "^/system/test/(.*)$" => "/index.php?q=system/test/$1",
  "^/([^.?]*)\?(.*)$" => "/index.php?q=$1&$2",
  "^/([^.?]*)$" => "/index.php?q=$1",
   "^/rss.xml" => "/index.php?q=rss.xml"
)

Come puoi vedere, questa espressione regolare (.*) corrisponderà anche a ' o " e se lo script php non gestisce correttamente questo input, può essere vulnerabile a SQL Injection.

Ecco un altro esempio, dove gli URL puliti sono implementati nella WebApplication stessa (in questo caso con python WebFramework django ): 

urlpatterns = patterns('',
    (r'^articles/2003/$', 'news.views.special_case_2003'),
    (r'^articles/(\d{4})/$', 'news.views.year_archive'),
    (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
    (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
)

Come puoi vedere qui, lo sviluppatore ha utilizzato espressioni come (\d{4}) che corrisponde a 4 cifre come 1234 , 2001 , 1995 , ... ma non 12 o 12345 - e quindi anche non 12' .

TL; DR Ciò significa che puoi inserirli come URL non puliti , se lo sviluppatore non utilizza espressioni appropriate.

modifica: non puoi sapere quale parte dell'URL pulito sono valori e quali sono le chiavi, quindi devi identificarli con la ragione o semplicemente testarli anch'essi.

    
risposta data 23.02.2013 - 12:51
fonte

Leggi altre domande sui tag

Riempimento del disco con dati casuali prima della crittografia? Memorizzazione della password nell'applicazione Java