In che modo un sito web diventa hackerabile? [chiuso]

Sì, ci sono molti modi per hackerare un sito web attraverso l'input dell'utente.

Fortunatamente per te, lo sviluppatore, ci sono elenchi di controllo di sicurezza che puoi utilizzare per leggere vulnerabilità di sicurezza come OWASP Top Ten . Cambia ogni anno ma tra i più comuni troverai:

1. Injection
2. Scripting cross-site
3. Gestione delle sessioni realmente interrotta

... e così via. Puoi iniziare dalla la pagina principale della top ten list di quest'anno . Da ciascun elemento della lista otterrai link a liste di controllo e altre risorse come l'API PHP Enterprise Security .

Il tag php fornisce già un suggerimento: P

Ma più seriamente, c'è un numero di errori comuni:

1. I dati inviati non vengono correttamente recuperati, ad esempio tutte le variabili di richiesta vengono importate automaticamente (utilizzando register_globals ).
2. Una variabile inviata viene utilizzata per includere un file, come in include($_REQUEST['action']) . Se allow_url_include è impostato, e $_REQUEST['action'] sembra essere un url per qualche script, l'interpretato lo caricherà da lì ed eseguirà, il che consente di eseguire qualsiasi tipo di cose malvagie. Questo non richiede nemmeno allow_url_include . Se il sito consente il caricamento di file, puoi prima caricare lo script e includerlo.
3. Una variabile inviata viene utilizzata in una query SQL senza corretta fuga . Ciò consente Iniezione SQL .
4. Una variabile inviata viene visualizzata come contenuto per gli altri utenti, senza invio di codice HTML o rimozione tag pericolosi (come script ), che consentono l'esecuzione di codice arbitrario sui client.
5. Consentendo l'invio GET del modulo e utilizzando solo i cookie per la gestione delle sessioni, il tuo sito diventa vulnerabile a CSRF .
6. Sfruttare bug nelle implementazioni C di varie funzioni PHP (overflow di interi, buffer under-run ecc.).

Fondamentalmente qualsiasi framework decente gestisce 1-3 out-of-the-box, 5 può anche essere automatizzato richiedendo semplicemente POST, o ancora meglio, aggiungendo qualche token di autenticazione al modulo. Inoltre, è meglio affrontare il problema mantenendo aggiornata la versione di PHP, poiché le vulnerabilità sono note e corrette. Di tutte le cose 4 è probabilmente la più difficile, se vuoi che i tuoi utenti siano in grado di utilizzare un sottoinsieme di HTML ma non è impossibile.

I diversi modi in cui le persone cattive fanno cose cattive alle tue applicazioni sono vaste e varie. Per certi aspetti, non importa quanto tu sia paranoico, probabilmente non è abbastanza. Quindi inizia con le nozioni di base:

• Assicurati che il tuo server non stia eseguendo nulla di non critico per l'applicazione, e tu sai cosa stanno facendo tutte le impostazioni di configurazione .
• Non fidarti mai di ciò che un utente ti dà . Sia gli attacchi di iniezione che gli attacchi di cross site scripting danno potere perché l'app accetta e utilizza semplicemente ciò che gli è stato dato. L'input deve essere rimosso e, quando visualizzi tali informazioni, devi assicurarti che sia conservata solo la formattazione desiderata.
• Assicurati di gestire correttamente gli errori . Le tracce dello stack rivelano qualcosa sullo stack del tuo server. Se stai usando il codice C #, ci sono cose che l'aggressore può fare per attaccare il SO o IIS perché sanno che è il server che stai usando. Anche Java non è esente, la traccia dello stack include le informazioni sul server se non lo si cattura e non lo si gestisce correttamente.

C'è molto di più da leggere, ma nel frattempo basta sapere che non è un problema semplice. Dovresti avere più linee di difesa e non affidarti solo all'applicazione web per gestire tutto ciò che riguarda la sicurezza.

Tutti sono hackerabili. Questo è auto-esplicativo.

Alcuni fattori sono:

1. 0 giorni - alcune minacce sconosciute stanno ancora emergendo
2. Social engineering - indipendentemente dalla sicurezza del tuo sito, se l'utente non si preoccupa della sicurezza
3. Piattaforma / sistema operativo hackerati - non importa quanto sicuro sia il tuo sito, se la piattaforma sottostante non è sicura

es. Lanciare lo stack della LAMP, cioè con PHP + Suhosin, su una scatola Linux insicura, sconfigge lo scopo di Suhosin in un modo o nell'altro

I siti web diventano hackerabili quando vengono creati / estesi. I programmatori spesso si concentrano su determinate funzionalità e non pensano molto agli "effetti collaterali". Gli hacker (o dovrei dire i cracker) d'altra parte sono molto aperti e adottano un approccio completamente diverso. Sono interessati a ciò che può fare l'applicazione web, non a ciò che era inteso da fare. Quindi si prendono il tempo per testare varie parti del sito Web e quando in qualche modo causano comportamenti scorretti dell'applicazione Web, sanno che hanno colpito un punto caldo. Tutti i suggerimenti che puoi trovare on-line (convalidare gli input, le query di escape) sono naturalmente corretti, ma seguirli non garantirà un sito web privo di errori. Alcuni dei migliori hack in circolazione (ad es. apache.org ) sono stati eseguiti dopo scoprire un fatto molto piccolo, in un primo momento privo di significato, su un sito web, e poi lavorare da lì.

I siti web diventano hackerabili da qualcuno che scopre un buco di sicurezza in quello che pensavi fosse salvare. È una curva di apprendimento costante per l'attacco e la difesa. È una guerra, con ogni lato in costante aumento.

La miglior difesa è essere indesiderabili. Se il tuo sito gestisce i soldi - eCommerce, servizi bancari, qualunque cosa - allora il costo della maintentnace è dieci volte quello che sarebbe senza la gestione del denaro. I siti vetrina possono essere rattoppati una volta al mese; i siti di e-commerce dovrebbero essere aggiornati ogni ora.

Indipendentemente dalla sicurezza del codice del tuo sito, se il servizio di hosting è incompetente, l'infrastruttura - Apache, MySQL, ecc. - avrà dei buchi senza patch. Niente di ciò che puoi fare tranne cambiare il servizio di hosting.