Cose da cercare una backdoor nel codice sorgente dell'applicazione web (file .PHP, .JS, etc) [chiuso]

-1

Sono in procinto di aggiungere funzionalità a un'applicazione web e riceverò alcuni file sorgente (PHP, JS e CSS) da uno sviluppatore esterno assunto.

Questi file non sono offuscati o crittografati e non presenteranno stranezze ovvie come un'intestazione che inizia con "GIF89a". Quello che volevo controllare sono alcune strane un po 'meno ovvie come il codice che potrebbe essere usato per implementare una backdoor.

[Aggiorna - evidenzia la frase inclusa in precedenza:] Quindi quello che mi piacerebbe fare è una scansione del bulbo oculare per parole chiave o semplici costrutti nel codice sorgente che possono essere usati per questo scopo. Il mio pensiero è che vorrei chiedere un chiarimento dallo sviluppatore per qualsiasi cosa io possa trovare (se non sono in grado di determinare cosa fa) piuttosto che chiedergli di spiegare ogni riga in ogni file.

L'applicazione web utilizza solo il lato server PHP 5.6 e il lato client JS (oltre a CSS e HTML). Quindi qualsiasi funzionalità di backdoor sarebbe limitata a ciò che queste tecnologie possono fornire.

Uno dei costrutti che cercherò nei file PHP e JS sono tutte espressioni contenenti un'istruzione eval ().

Esistono altre parole chiave oltre a eval che potrei verificare?

[Aggiornamento aggiuntivo:] In questa fase stavo solo cercando una scansione di elementi che potrebbero richiedere un'ulteriore discussione con lo sviluppatore. A causa del tempo e di altri vincoli non stavo cercando di evitare tutti gli exploit possibili, né sto cercando di capire tutte le migliaia di righe di codice che saranno presenti su questi file.

    
posta coderworks 06.10.2015 - 17:04
fonte

2 risposte

1

Temo che non sia così semplice. Alcuni costrutti linguistici non sono di per sé negativi ma utilizzati in alcuni punti possono rendere l'applicazione vulnerabile. Si consideri ad es. Funzione strcmp di PHP: sembra OK, non ci sono vulnerabilità segnalate, ma è ancora possibile bypassarlo se viene alimentato direttamente con l'input dell'utente. Quindi, se fossi in te, prenderei in considerazione una revisione approfondita del codice invece della semplice scansione del bulbo oculare. Più esperienza hai, più rischi di sicurezza "non così ovvi" sarai in grado di individuare.

Un breve elenco per aiutarti a iniziare con una revisione della scansione del bulbo oculare:

  • L'input dell'utente è gestito in modo corretto e sicuro?
  • I controlli di uguaglianza vengono eseguiti con ===?
  • Sono utilizzate funzioni deprecate?
  • Sei in grado di capire il codice?

In generale, ci sono molte altre cose da considerare e l'elenco diventa ancora più grande con la complessità dell'applicazione. Per esempio. potresti (dovresti!) voler garantire che tutti gli algoritmi crittografici siano utilizzati in modo corretto e che l'implementazione utilizzata sia corretta e sicura. Vi è la gestione dei file, la connessione al database e potenzialmente decine di altre fonti di dati con cui l'applicazione sta comunicando.

Se ritieni di non poterlo gestire da solo a causa della mancanza di esperienza o altro, ti consiglio di chiedere aiuto a qualcuno. In realtà, anche se sei sicuro di poterlo fare, chiedi a qualcuno di ricontrollare: è sempre meglio avere due paia di occhi su un codice non fidato, piuttosto che uno.

    
risposta data 06.10.2015 - 18:09
fonte
0

PHP

Per motivi di sicurezza puoi bloccare le funzioni PHP per nome nel tuo PHP.ini, quindi se sono nel codice non possono essere eseguite. Ecco un piatto di caldaia di quello che uso normalmente.

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

Ci possono essere usi legittimi per i precedenti. Ma è meglio scoprire solo perché prima li elenchiamo di bianco. Anche se il tuo programmatore non li sta usando per ragioni di male, potrebbe fare in modo che parti malamente codificate permettano a un hacker di abusare di quelle funzioni.

Conosci eval ma dovresti notare shell_exec , exec , system e passthru . Ciò consentirà al tuo sviluppatore di interagire direttamente con il sistema. E per la maggior parte delle situazioni non dovrebbe essere permesso dalla tua configurazione di PHP. Notate anche quanti potrebbero consentire loro di interagire con i processi in esecuzione sul server.

Inoltre vorrei ricontrollare ogni richiesta e include. Con una corretta configurazione di PHP non può includere in remoto ma non fa male a guardare. Vorrei anche cercare lo stesso usando le funzioni fopen e CURL. Se trovato, ha il potenziale per caricare il codice remoto senza che tu sia in grado di esaminarlo o scansionarlo.

JavaScript

Non puoi backdoor un server come JavaScript esegue solo lato client (supponendo che tu non stia utilizzando Node.js). Ma potrebbero metterti a rischio per un attacco XSS. Assicurarsi che non stiano tentando di caricare script remoti se non da una CDN approvata e attendibile. E assicurati che il loro JavaScript non provi ad allegare elementi di script al tuo documento che potrebbero essere caricati nei file JavaScript remoti.

    
risposta data 06.10.2015 - 17:45
fonte

Leggi altre domande sui tag