Il caricamento delle immagini su un database è sicuro se ridimensioni l'immagine prima in byte non elaborati?

1

Vedi il codice di caricamento qui sotto. il metodo è chiamato all'interno di una prova, cattura. Se è necessario il codice per le utility immagine, basta dire. Fondamentalmente, tutto viene gestito in byte non elaborati e quindi archiviato nel DB. Attualmente eseguo il rendering delle immagini come base 64, ma mi sto muovendo verso l'utilizzo del frammento di fondo in web api.

I miei pensieri principali sono:

  • L'immagine viene caricata in byte non elaborati. Anche se potrebbe contenere un virus, non verrebbe eseguito
  • Il server ha una dimensione massima del file impostata e, prima di questo metodo, l'utente è autenticato e viene controllato che non stanno scaricando contemporaneamente altri file (uno alla volta) con un caricamento massimo di 100 immagini all'ora. Questo spero, spero, fermi un'immagine specifica.
  • Poiché l'immagine viene modificata in modo da avere una certa dimensione (100 x 100), se non si tratta di un tipo di immagine valido ciò genera un'eccezione e tutto viene categorizzato
  • Potrei aggiungere una lista bianca alle estensioni di file prima di questo se riesci a visualizzare potenziali problemi?
  • Credo che Image.FromStream sia al sicuro da un attacco di overflow

    public string StoreProfileImage(ImageViewModel model, string userId)
    {
            var postedImg = model.Image;
            var image = Image.FromStream(postedImg.InputStream, true, true);
            if (image != null)
            {
                Rectangle rect = new Rectangle();
                rect.X = (int)Math.Floor(model.x / model.scale);
                rect.Y = (int)Math.Floor(model.y / model.scale);
                rect.Width = (int)Math.Floor(model.width / model.scale);
                rect.Height = (int)Math.Floor(model.height / model.scale);
    
                // crop the image
                var croppedImg = ImageUtilities.CropImage(image, rect.Height, rect.Width, rect.X, rect.Y);
                // resize to max pic size
                var resizedImg = ImageUtilities.ResizeImage(100, 100, croppedImg);
                // convert to bytes
                byte[] imageData = ImageUtilities.ImageToByteArray(resizedImg);
    
                using (var db = new DbContext())
                {
                    var userImage = new UserImage
                    {
                        ImageBytes = imageData,
                        ImageName = postedImg.FileName,
                        UserId = userId,
                        IsProfileImage = true
                    };
    
                    // add new users image
                    db.UserImage.Add(userImage);
                    db.SaveChanges(); 
                }
                return ImageUtilities.BytesToBase64(imageData);
            }
            return null;
        }
    

Snippet di rendering

 HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
 result.Content = new ByteArrayContent(image.ImageBytes);
 result.Content.Headers.ContentType = new MediaTypeHeaderValue("image/png");
 return result;
    
posta user2330270 19.03.2016 - 20:51
fonte

2 risposte

3

Pur sanificando l'immagine ridimensionandola, è una buona idea che ci siano stati diversi bug critici nelle librerie di elaborazione delle immagini in passato. Ciò significa che il processo di ridimensionamento dell'immagine stessa potrebbe innescare un tale errore e quindi causare DOS con un attacco di complessità contro la libreria di manipolazione di immagini o anche l'esecuzione di codice remoto. Ecco perché il processo di ridimensionamento dovrebbe essere eseguito all'interno di una sorta di VM o sandbox e dovrebbe anche essere limitato in termini di utilizzo della CPU e della memoria.

E poi ci sono diversi modi per ridimensionare. Non ho familiarità con l'implementazione che si sta usando, ma potrebbe essere che i metadati dell'immagine siano preservati (cioè commenti, flag, tempo di creazione ecc.) E quindi potrebbero essere ancora utilizzati in seguito in un attacco. Quindi è meglio convertire l'immagine prima in un formato come PPM che non ha la capacità di memorizzare i metadati per rimuovere qualsiasi tipo di potenziale metadati dannoso.

Inoltre non ho familiarità con ciò che il codice di memorizzazione dell'immagine nel database fa realmente nell'implementazione. Si spera che utilizzi il binding di parametri o tecniche simili, perché altrimenti potrebbe essere utilizzata anche un'immagine dannosa per un attacco di SQL injection.

Per quanto riguarda la lettura dell'immagine, devi essere consapevole che i browser spesso ignorano il tipo di contenuto che invii a seconda del contesto. Ciò significa che se l'URL viene utilizzato come origine per il tag di script, l'immagine verrà interpretata come script, anche se il tipo di contenuto è image / png (Chrome non consente questo, ma altri lo fanno). L'applicazione contestuale del contesto può essere eseguita con un download forzato. Ad esempio potresti inviare malware nascosto da un tipo di immagine con <a href=image.png download=malware.zip> e potrebbe anche avere i byte magici corretti per il tipo di immagine in primo piano perché l'estrazione dei file ZIP spesso ignora la posta indesiderata all'inizio del file ZIP. Ma se hai rimosso i metadati come ti ho raccomandato, probabilmente sei al sicuro da questo tipo di abuso.

    
risposta data 19.03.2016 - 21:53
fonte
0

Quindi hai un upload di file HTTP per le immagini e un codice per ridimensionare l'immagine sul server, e stai chiedendo se è "sicuro" (contro tutte le cose)?

No, niente è sicuro.

The image is uploaded in raw bytes. While it could contain a virus it wouldn't run.

Perché lo pensi? Con un bug nel server Web e specifici pattern di byte creati per utilizzare questo bug, potrebbe essere eseguito prima che raggiunga anche il codice di elaborazione. Avere codice per ridimensionare le immagini non può impedirlo.

...max file size...stop...DoS

Esistono molti tipi di attacchi DOS / DDOS. Il ridimensionamento delle immagini non aiuterà.

Because the image is modified to be a certain size (100 x 100) then if it's not a valid image type this would throw an exception and everything is binned

I file che sono sia immagini valide che malware non sono un problema.
Immagini che mantengono inalterata la parte del malware durante il ridimensionamento, es. il malware non fa parte dei dati pixel / colore, non sono nemmeno un problema.

I could add a white list

Per cosa? Questo non aiuterà.

I believe Image.FromStream is safe from an overflow attack

E se non è come credi? Destra.

A parte questo, hai elencato le tue opinioni su alcuni attacchi specifici, ma che ne è del resto enorme?

Ridimensionare, o meglio convertire, le immagini sicuramente aiuta contro alcune cose, in alcuni casi,
ma non è un proiettile magico.

    
risposta data 19.03.2016 - 21:12
fonte

Leggi altre domande sui tag