Oltre le iniezioni SQL e XSS

1

Sono un programmatore che lavora su un servizio web (da solo). Dato che non sono un esperto di sicurezza, sono venuto in questo sito per porre la mia domanda.

Ho fatto tutto il necessario per proteggere il mio sito web. Ho provato a proteggere contro ...

  1. Iniezioni SQL utilizzando le istruzioni preparate.
  2. Attacchi XSS utilizzando json_encode(htmlspecialchars($str)); quando si inviano input di stringa degli utenti (tutti i miei dati vengono inviati tramite JSON).
  3. Comprimi password utilizzando la seguente funzione per crittografare le password:

[L'ho trovato online ma dovrei usare bcrypt invece di crypt ?]

$cost = 10;
$salt = strtr(base64_encode(mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)), '+', '.');
$salt = sprintf("$2a$%02d$", $cost) . $salt;
$password = crypt($pass, $salt);

E quindi per accedere:

if (crypt($pass, $realpass) == $realpass)
{ //$pass = entered password, $realpass = database
    //yay
}

Inoltre, ci sono un sacco di cose in cima alla mia testa che non ho tenuto conto. Questi includono:

  1. Caricamento sul server - le immagini / i video possono essere dannosi se modificati con imagick / ffmpeg?
  2. Legalità - Come sanificare i contenuti illegali (ad es. pornografia infantile, ecc.) o persino contenuti illeciti (ad esempio nudità)?

Inoltre non mi sono preoccupato dell'invio di codice / comando poiché non ho esecuzioni vulnerabili a quelle. Oh e, naturalmente, sto inviando / ricevendo tutto su HTTPS.

TUTTAVIA , sono sicuro che tutti voi siete seduti a casa a ridere della mia stupidità nell'argomento. Agli esperti di sicurezza non viene pagato uno stipendio, sai, sicuro contro cose elementari come Iniezioni SQL . Dubito seriamente che eventuali violazioni della sicurezza si verifichino a causa di potenziali violazioni della sicurezza di cui sopra.

E quindi la mia domanda è: cosa mi manca? Vale la pena notare che userò l'EC2 di AWS, quindi non so se devo prendere ulteriori misure di sicurezza sul server o meno.

Grazie in anticipo.

    
posta Shahar 22.12.2014 - 23:23
fonte

3 risposte

3

I seriously doubt that any major security breaches occur because of any of the potential security breaches I listed above.

Sembra che tu stia coprendo queste ben note vulnerabilità dovute a insufficiente sanitizzazione dei parametri, quindi ti aspetteresti che anche il resto del mondo lo facesse.

Ma, ragazzo, ti sbaglieresti!

According to the results of a recent survey of 595 U.S.-based IT security practitioners, 65 percent of respondents said their companies had experienced SQL injection attacks that successfully evaded their perimeter defenses in the past 12 months.source

e XSS è di gran lunga la vulnerabilità più comune in base al rapporto sulla sicurezza Web di WhiteHat

Che cosa ti manca?

Upload di file penso che 8 regole di base per upload di file sicuri da parte di SANS è eccellente.

Librerie di terze parti Il tuo codice potrebbe essere perfetto ma fare affidamento su librerie di terze parti non sicure per tutti i tipi di funzionalità. Questi funzionano per essere sempre aggiornati con le ultime patch.

Escalation dei privilegi La maggior parte delle applicazioni che collaudo, dopo che i loro parametri sono tutti ben disinfettati, non ha prestato attenzione all'escalation dei privilegi. Questo è un tipo di vulnerabilità che gli scanner automatici non sono molto bravi a rilevare. Ad esempio, molte applicazioni popolano moduli con scelte basate sul privilegio dell'utente. Un utente malintenzionato può aggiungere scelte a questi moduli sul lato client con un grande effetto, a meno che il server non sia saggio a ciò che l'utente dovrebbe essere autorizzato a fare. Alcuni framework web controllano questo molto meglio di altri.

Registrazione Assicurati che gli eventi relativi alla sicurezza vengano catturati da qualche parte in modo che tu possa sapere cosa sta succedendo. Eventi da catturare: accessi di successo, accessi non riusciti, modifiche ai ruoli, caricamenti di file, download di file, errori di database e altro ancora importanti per te.

    
risposta data 23.12.2014 - 16:49
fonte
2

Poiché stai creando un'applicazione web, un buon punto di partenza è OWASP Top Ten .

Una volta che credi di aver fatto bene ad indurire il tuo codice, cerca di eseguire analisi sia statiche che dinamiche.

Gli strumenti di analisi statica variano in base al framework utilizzato. Ancora, OWASP può farti iniziare .

Successivamente, controlla i Termini di servizio di AWS ed esegui uno scanner di vulnerabilità contro la tua app web. OWASP ZAP è uno strumento semplice e intuitivo per questo.

Dopo aver completato questi passaggi, sarai sulla buona strada per avere un'applicazione web sicura più .

    
risposta data 23.12.2014 - 04:02
fonte
0

In addition, there are a number of things on top of my head that I did not account for. These include:

Uploading to server - can images/videos be malicious if edited with imagick/ffmpeg?

Non con quello , ma possono essere dannosi in due modi:

  • dannoso per te. Se l'immagine che viene caricata è in realtà un codice eseguibile, e il server può essere ingannato per eseguirlo, o se il percorso di salvataggio è sotto il controllo dell'utente e può sovrascrivere alcuni file critici con un JPEG con un nome dannoso. Puoi evitarlo:
    • verifica il tipo di immagine quando viene caricata (eventualmente rimuovendola dai dati EXIF / APP).
    • salvandolo con un nome di la tua scelta, e ancora meglio, un ID univoco; quindi puoi salvare il nome originale dell'utente; quando l'utente chiede l'immagine, è possibile inviarlo come allegato utilizzando il nome originale, ma sul server il file non ha nemmeno un'estensione e non è eseguibile in alcun modo.
  • Nocivo per gli altri: è possibile creare un JPEG che richiede diversi gigabyte di RAM per essere pienamente rappresentato. Quindi invia il link allo stesso JPEG. Puoi verificarlo - vedo che stai codificando in PHP - usando getImageSize() , che non decodifica l'immagine e quindi consuma pochissima memoria.

Legality - How to sanitize illegal content (i.e. child porn, etc.) or even illicit content (i.e. nudity)?

Alcuni formati di immagine consentono di incorporare un tag "valutazione", ma se non ci si può fidare (o non c'è alcun tag per iniziare), temo che tu non abbia fortuna. Ci sono alcuni servizi online che valutano un'immagine basata sull'estrazione di funzionalità, ma ci sono considerazioni sul costo, sulla larghezza di banda, sull'efficacia. Dai un'occhiata a qui . C'era anche una domanda su Stack Overflow .

HOWEVER, I'm sure all of you are sitting there at home laughing at my stupidity in the subject. Security experts are not paid a salary to, you know, secure against things as elementary as SQL injections.

Saresti sorpreso ...

I seriously doubt that any major security breaches occur because of any of the potential security breaches I listed above.

... e ora mi stai facendo piangere. Non sto cercando di essere lusinghiero o ingraziante, ma la triste, triste verità è che molti di sviluppatori altamente pagati e capi progetto non pensano, implementano e testano veramente un decimo di quello che sei tu " ho 'considerato' da solo. La sicurezza sembra non avere alcun ROI, o come ha detto Joel , è sommersa. Facile da trascurare. A causa del time-to-market e del vincolo di budget per essere sicuri, non è come se non lo farebbero se potessero . Tuttavia, potrei facilmente nominare diversi grandi siti, uno dei quali costava parte del progetto milioni , dove piccoli tavoli Bobby ha avuto un ingresso amministrativo permanente. Uno in cui la "sicurezza" del pannello di controllo dell'amministratore era assicurata "dal fatto che l'URL doveva essere digitato manualmente". E scommetterei dollari contro le noccioline che la maggior parte degli sviluppatori là fuori ha una loro storia di orrore da compagnia.

    
risposta data 23.12.2014 - 17:46
fonte

Leggi altre domande sui tag