Come gestire il contenuto statico-ish da un CDN con l'autenticazione?

Question

Come gestire il contenuto statico-ish da un CDN con l'autenticazione?

#1 da (1 voti)

3

Ho un sito web che consente agli utenti di caricare contenuti. Parte del progetto, ad oggi, comporta la memorizzazione del contenuto dell'utente su un NAS che è stato configurato con un pool di app separato in IIS con script disabilitato, durata inferiore, nessun cookie, ecc. Per il comportamento di tipo CDN come sottodominio (statico. dominio.com vs www.dominio.com). Ho il controllo completo su questo processo e su tutte le istanze. La decisione di progettazione era quella di consentire una più economica conservazione dei documenti caricati (invece di wwwroot o un DB) e contribuire a mitigare alcuni problemi di sicurezza non consentendo la creazione di script.

La preoccupazione che ho ora è che i CDN, e questa configurazione, sono per loro natura molto permissivi e non prevedono alcun controllo o convalida. Esistono misure ragionevolmente efficaci per scoraggiare la condivisione inattiva di questo contenuto utente? So che nulla fermerà le persone determinate o malintenzionate, ma voglio almeno impedire a questo contenuto utente di essere disponibile in generale al popoloso generale. Tutti i link al contenuto saranno dietro un paywall nel sottodominio 'www', ma il contenuto stesso sarà dietro il sottodominio 'statico'.

Idee che ho avuto finora:

Controllo referente HTTP
Nomi di file occultati (lo so, lo so ...)
Test dei cookie con riscrittura degli URL? (IIS8)
...
Chiedi stackexchange

web-applications authentication cdn

posta Bryan Boettcher 18.03.2014 - 21:42

fonte

1 risposta

Leggi altre domande sui tag web-applications authentication cdn

che ricarica le classi singleton e la dipendenza Documentazione / definizione delle strutture dati in Python

score 1 · Answer 1

Are there any reasonably effective measures to discourage idle sharing of this user content?

La limitazione della velocità sarebbe la cosa più semplice da fare:

So for example, a request coming from a particular IP address, may not download a picture file more than 10 times in 1 hour. So what a customer should be able to do, is create a rule that when activated for a specific URI destined for a container protected by the rule, does the following:

1)  Looks at the incoming URI. 
2)  Checks if the URI is for a file that is inside a container defined in a rule (image container for example) 
3)  Pulls out HitCount(integer) for this URI by requester’s IPAddress+URI(Key) 
4)  Checks if HitCount for this URI from that IP has exceeded the allowed hit count (defined by user) during (a time frame defined by user). 
5)  If HitCount is equal to the limit, then CDN serves 403. Else CDN serves the content.

6)  When a timeframe defined by a user has elapsed, The HitCount goes back to 0, and requests can continue until HitCount limit has been reached again.

La protezione Hotlink sarebbe un'altra:

When enabled, the "Hotlink Protection" option ensures that other sites cannot suck up your bandwidth by building pages that use images hosted on your site. Anytime a request for an image on your site hits Cloudflare, we check to ensure that it's not another site requesting them. People will still be able to download and view images from your page, but other sites won't be able to steal them for use on their own pages.

In other words, HTTP Referrers that are not in-zone and not blank will be denied access. Supported file extensions are gif, ico, jpg, jpeg, and png.

**Protected**: http<nolink>://example.com/pic.jpg  
**To bypass**: http<nolink>://example.com/hotlink-ok/pic.jpg

Gli URL firmati sarebbero un terzo:

When signed URL handling is enabled on a backend, Cloud CDN gives special handling to requests with signed URLs. Specifically, requests with a Signature query parameter are considered signed. When such a request is received, Cloud CDN verifies the following:

The HTTP method is GET or HEAD.
The Expires parameter is set to a future time.
The request's signature matches the signature computed using the named key.

If any of these checks fails, a 403 Forbidden response is served. Otherwise, the request is either proxied to the backend or served from the cache. All valid signed requests for a particular base url (the part before the KeyName parameter) will share the same cache entry. Responses to signed and unsigned requests do not share cache entries. Responses are cached and served until the expiration time you set.

Riferimenti