it-swarm-eu.dev

È possibile che un hacker scarichi un file php senza prima eseguirlo?

Ho un sito Web php in cui tutto è nella cartella public_html \, inclusa una cartella includes con config e classi. Ho detto al mio sviluppatore di spostarlo dalla cartella pubblica, ma ha detto che non vi è alcun rischio in quanto i file sono file php e anche se qualcuno digita nel browser il

www.example.com/includex/config.php

tutto ciò che otterranno è una pagina vuota.

È corretto? Non c'è modo che qualcuno possa scaricare un file php e vedere cosa c'è dentro, anche se l'hacker accede al mio server in qualche modo per scaricare il file o includerlo in un file php sul suo server usando XSS?

35
Petja Zaichikov

Per leggere PHP è necessario un vulnerabilità di attraversamento directory . file_get_contents() o altro funzioni del file system sfruttabili =.

SQL Injection in mysql può essere utilizzato per leggere il codice sorgente. Per esempio:

select load_file("/var/www/index.php")

Per combattere questo assicurati che file_privs sono disabilitati per l'account utente MySQL utilizzato da PHP. Se display_errors = on nella tua configurazione php, un utente malintenzionato può ottenere il percorso della tua radice web e usare l'iniezione sql o l'attraversamento di directory per leggere il codice sorgente.

L'uso di FTP significa che il codice sorgente viene trasmesso in testo normale. Usa SFTP , e assicurati di avere una password complessa, o meglio ancora, imposta una chiave RSA.

Fai attenzione ai file di backup, a volte gli editor creano index.php~ o index.php.orig file che possono essere scoperti usando navigazione forzata .

22
rook

Oltre alle vulnerabilità sul lato server di tutte le varietà, anche le password FTP trapelate sono una preoccupazione significativa. Esiste una classe di infezioni lato client che raccolgono le password FTP salvate da programmi come CuteFTP, FileZilla e DreamWeaver, inviando le credenziali di accesso a un utente malintenzionato. Questo è molto comune. Personalmente ho visto centinaia, forse migliaia di casi in cui questo è successo. E in genere, la persona che ha trapelato inconsapevolmente le password è qualcuno che non ha più bisogno di averle comunque.

E se ti stai chiedendo se un utente malintenzionato possa effettivamente scavare tra i file di configurazione in cerca di password, la risposta è inequivocabilmente " yes ". In genere è una delle primissime cose che un attaccante farà, in pochi minuti dopo aver compromesso una nuova macchina.

13
tylerl

Esistono due modi in cui un utente malintenzionato potrebbe leggere questo file come testo anziché eseguirlo.

  1. Se il tuo server web non è configurato correttamente, il php potrebbe non essere eseguito. È ovviamente necessario disporre di php installato e in esecuzione sul lato server, nonché disporre di un server Web in grado di supportarlo. Se, per qualche motivo, qualcosa non va nella tua installazione di php, allora è teoricamente possibile scaricare il file php "raw". Questo, tuttavia, è improbabile.

  2. Se esiste una vulnerabilità LFI (inclusione di file locale) in questo script (o in qualsiasi altra pagina dinamica sul sito), è possibile visualizzare un file che si trova sul server Web. Vedi la pagina Wikipedia sulle vulnerabilità di inclusione dei file per vedere come sarebbe.

A parte questo, vale la pena notare che per utilizzare PHP, devono essere raggiungibili da un browser. Non c'è modo di "nascondere" la pagina, a meno che tu non abbia un altro script che la esegue altrove.

4
dshaw

Le password FTP trapelate sono tutte molto comuni e sono uno dei modi più comuni in cui vengono rimossi i file di origine, il malware installato sui siti Web degli sviluppatori è molto comune e recentemente gli sviluppi hanno iniziato a testimoniare attacchi di spear phishing contro di loro nel tentativo di ottenere la proprietà intellettuale degli hacker .

Uno dei modi non così comuni e di cui sono a conoscenza è noto solo a un certo numero di persone, ma se sviluppi il tuo sito Web sul server web Linux in cui il sito Web è ospitato, potresti avere un problema come alcune modifiche il software memorizzerà i backup dei file modificati nascosti dalla vista degli sviluppatori, ad es.

Login.php ~

È possibile accedere a questo file perché non è gestito dal server Web inserendo

Ciò rivelerebbe la fonte del file login.php di backup per evitare che tu debba sviluppare il tuo codice del sito e caricarlo sul server o assicurarti che non ci siano file di backup memorizzati in una directory che il pubblico ha accesso a.

Fonte: rivista 2600

Cosa succede se un attaccante è stato in grado di accedere

databaseConnection.php ~

Allora il tuo torrente è davvero alto

3
Bratislava Bob

Come altri hanno risposto, questo non dovrebbe essere possibile. Tuttavia, non puoi dire che un attaccante non ha assolutamente modo di leggere il tuo codice sorgente PHP.

Ad esempio, potrebbe esserci una vulnerabilità che consente a un utente malintenzionato di visualizzare i file nel server Web, incluso raw PHP. O un utente malintenzionato potrebbe essere in grado di rilevare la password FTP, che potrebbe anche fatto in molti modi, tra cui attacchi man-in-the-middle e social engineering . Ci sono molte possibilità. Di seguito, ho elencato alcune vulnerabilità che potrebbero consentirlo, ma la linea di fondo è che solo avere PHP nella cartella public_html non dovrebbero assolutamente essere un rischio per se stessi.


Un file A download.php che accetta un parametro GET/POST con il nome del file da scaricare e non filtra correttamente l'input dell'utente, potrebbe consentire di scaricare il codice non elaborato di un file sul sito, accedendo a un indirizzo come questo: http://www.example.com/files/download.php?file=../index.php . Vedi questo .

Un altro esempio: se esiste una vulnerabilità che consente a un utente malintenzionato di eseguire eseguire il codice sul server, ad esempio inclusione file locale/remoto , Vulnerabilità caricamento file e altri, potrebbe anche essere possibile per lui eseguire il codice che gli consente di leggere il tuo codice sorgente PHP.

0
mds

Fintanto che le cose sono impostate correttamente sul server, PHP devono essere registrati come script e il server web dovrebbe averli interpretati da PHP quando richiesto e solo visualizzare i risultati di tale interpretazione.

Detto questo, qualsiasi numero di problemi può comportare l'esposizione dei file. Alcuni di questi problemi possono anche esporre i dati indipendentemente dal fatto che siano in una cartella pubblica o meno. È sempre importante assicurarsi che il server sia configurato correttamente per consentire solo le richieste necessarie. Ciò riduce l'area disponibile per l'attacco e aiuta a evitare possibili problemi relativi ai bug che potrebbero provocare una violazione.

È una buona idea avere un file di configurazione in una cartella pubblica? Finché il server è configurato per non distribuire il file senza elaborarlo, probabilmente non è molto meno sicuro di qualsiasi altro punto del sistema. Esiste la piccola possibilità che un bug nel server Web venga utilizzato per impedire l'esecuzione da parte del motore di scripting, ma gli attacchi più probabili sono attacchi che provengono da un'altra direzione come SQL, FTP o un'iniezione di codice in cui si trovano in una cartella privata sarebbe ugualmente esposto.

Detto questo, il rovescio della medaglia è perché non metterlo altrove. L'opzione più sicura sarebbe quella di mettere in un posto che solo l'utente che il sito web PHP esegue come può accedere e negare l'accesso al file da qualsiasi altro meccanismo (come l'utente FTP o qualsiasi altro utente utilizzato pubblicamente.) Tuttavia, è piuttosto difficile da configurare e gestire, quindi è necessario prendere una decisione se la sicurezza aggiuntiva è necessaria o meno.

È uno scherzo su quale sia il migliore. È necessario molto lavoro per gestire tutti i percorsi, le autorizzazioni e gli utenti per mantenere quel livello di sicurezza. Il rovescio della medaglia, fintanto che il server è mantenuto patchato e correttamente configurato, dovresti essere vulnerabile solo agli exploit zero day che attaccano a un livello molto basso e puoi essere sicuro contro praticamente tutti gli attacchi comuni, anche con il file di configurazione in la cartella pubblica.

0
AJ Henderson