Gestisci correttamente la richiesta IIS con l'URL di accesso percentuale (/%)

14

Sto cercando qualsiasi tipo di soluzione per ottenere correttamente una richiesta IIS come /programming//% e http://bing.com/% per non visualizzare una pagina 400 Bad Request, ma visualizzare una pagina di errore personalizzata simile a come fanno http://google.com/% e http://facebook.com/% (ovviamente quegli esempi non sono su IIS).

Credo di aver provato a configurare tutte le impostazioni del registro http.sys applicabili (AllowRestrictedChars, PercentUAllowed) per http://support.microsoft.com/kb/820129, ma ciò non ha aiutato. L'impostazione di AllowRestrictedChars e di una pagina 400 personalizzata ha corretto gli URL come /programming//%12 ma non /%.

iis iis-7 iis-7.5

— bkaid
fonte

3

Ti rendi conto che è una fuga URL incompleta ed è una cattiva richiesta, quindi 400 lo sta gestendo correttamente? PercentU e AllowRestricted non sono realmente applicabili

— Rup

Sì, lo faccio (e /% è solo un URL di esempio, ma ovviamente l'errore si verifica con ogni carattere di escape non valido). IIS sta gestendo il 400, ma voglio mostrare una pagina 400 personalizzata come posso con altri codici di stato in IIS e come come i server non IIS possono fare per 400.

— bkaid

Ho alcuni link potenti che puntano ai miei siti Web che sono erroneamente codificati in questo modo. ma non mi è permesso di 301 loro alla pagina corretta, invece è un errore grave. questo è inaccettabile.

— boomhauer,

20

Questo è bloccato proprio a livello di kernel IIS. Come test ho estratto tutti i moduli in IIS in modo che non avesse nemmeno un gestore di pagine statico e visualizzava ancora il messaggio di errore 400.

Non credo sia possibile con IIS aggirarlo. Le impostazioni del registro che hai citato sono per altri tipi di caratteri con restrizioni. Non ho visto una leva per cambiare quella funzionalità.

Qual è il tuo obiettivo è quello di evitarlo? Apre la superficie di attacco più ampia e non riesco a immaginare che un visitatore legittimo si perda a causa del blocco di sequenze di escape URL incomplete.

Aggiornamento2: qui ci sono tre grandi collegamenti su questo. Sia Nazim Lala che Wade Hilmo del team IIS hanno scritto questo blog a causa della discussione sulla tua domanda. Anche Scott Hanselman ha un ottimo post sulla parte di querystring in .NET:

Uso di caratteri speciali in IIS - Nazim Lala
Come IIS blocca i caratteri negli URL : Wade Hilmo
Experiments in Wackiness - Scott Hanselman

Aggiornamento: ho verificato con un membro del team IIS per ottenere una risposta autorevole. Ha menzionato che la% è considerata un carattere non sicuro secondo RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ).

Ecco il testo pertinente:

Unsafe:

I personaggi possono non essere sicuri per una serie di motivi. Il carattere spaziale non è sicuro perché possono scomparire spazi significativi e possono essere introdotti spazi insignificanti quando gli URL vengono trascritti o composti o sottoposti al trattamento di programmi di elaborazione testi. I caratteri "<" e ">" non sono sicuri perché vengono utilizzati come delimitatori attorno agli URL nel testo libero; il segno di virgolette ("" ") viene utilizzato per delimitare gli URL in alcuni sistemi. Il carattere" # "non è sicuro e deve essere sempre codificato perché utilizzato nel World Wide Web e in altri sistemi per delimitare un URL da un frammento / ancora identificatore che potrebbe seguirlo. Il carattere "%" non è sicuro perché viene utilizzato per la codifica di altri caratteri. Altri personaggi non sono sicuri perché i gateway e altri agenti di trasporto sono noti a volte modificare tali caratteri. Questi caratteri sono "{", "}", "|", "\", "^", "~", "[", "]" e "` ".

Tutti i caratteri non sicuri devono essere sempre codificati in un URL. Ad esempio, il carattere "#" deve essere codificato negli URL anche nei sistemi che normalmente non gestiscono frammenti o identificatori di ancoraggio, quindi se l'URL viene copiato in un altro sistema che li utilizza, non sarà necessario modificare il Codifica URL.

Quindi IIS lo blocca in modo proattivo a livello centrale, una misura di sicurezza proattiva per ridurre al minimo la superficie di attacco.

— Scott Forsyth - MVP
fonte

Preferisco registrare e gestire correttamente tutti gli errori per monitorare qualsiasi strana combinazione non valida di URL non validi che vengono generati dinamicamente sul mio sito - nel caso in cui uno non ottenga correttamente l'url evitato.

— bkaid,

1

C'è qualcosa da dire per gestire da soli gli errori, ma se i fallimenti palesemente ovvi vengono gestiti per te, è un bel vantaggio. IIS non dovrebbe consentire caratteri che non corrispondono a un file o una cartella nel file system NTFS. Non saprebbe cosa fare con il percorso della cartella. Se non è un modello di personaggio uguale a un personaggio valido, allora dovrebbe prendere una decisione su cosa fare. In questo caso sembra che fosse dedicato a bloccare anziché ignorare i caratteri non validi.

— Scott Forsyth - MVP

@thekaido Come ha detto Scott, non ha senso analizzare URL incompleti. Che tipo di pagina di errore personalizzata è possibile creare poiché non si ha idea di cosa l'utente stesse cercando di fare (poiché la richiesta è incompleta). Nota che IE9 non ti permetterà nemmeno di arrivare al server con una richiesta incompleta

— Jim B

Comprendo le implicazioni di tutte queste cose, ma Apache e altri server Web lo consentono come dovrebbe IIS. Gli URL con escape errato sono l'unico IIS dell'URL che non ti consente di gestire ciò di cui sono a conoscenza. IIS dovrebbe e consente altri caratteri che non sono mappati al file system NTFS perché il mio sito è stato creato utilizzando ASP.NET MVC in cui le richieste verranno indirizzate a risorse non basate su file.

— Bkaid,

In realtà sto corretto su% in NTFS. È consentito, insieme alla maggior parte degli altri personaggi: en.wikipedia.org/wiki/Ntfs . (cerca i caratteri consentiti nei nomi dei file).

— Scott Forsyth - MVP

3

Posso pensare a 3 possibili modi

Modificare IIS in modo che punti a una pagina personalizzata per 400 errori rispetto al normale
Se questo è univoco per un sito Web specifico in IIS, puoi fare qualcosa di simile in web.config:

<customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
<error statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Scrivi un httpModule che controlla gli URL in arrivo e li gestisce

— Dave Wise
fonte

4

Nessuna di queste funzioni: IIS non passa mai la richiesta.

— Bkaid,

L'opzione n. 1 dovrebbe funzionare indipendentemente dal fatto che è così che IIS risponde all'errore

— Dave Wise,

4

Ho appena provato di nuovo l'opzione 1 e # 2 e nessuno dei due funziona. IIS sta gestendo questa richiesta specialmente come menziona Scott.

— Bkaid,

3

L'unico modo per aggirare questo suona come controllare l'URL prima che il kernel IIS possa farlo.

Dovresti inviare i tuoi collegamenti generati dinamicamente tramite uno script per controllarli prima di inoltrare l'utente finale a quell'URL ...

A parte questo, sai che questa è l'unica situazione in cui IIS non la gestirà nel modo desiderato. Quindi, con il processo di eliminazione, se hai una richiesta non gestita sai cosa l'ha causata.

Forse il controllo del referrer in una pagina 400 personalizzata aiuterebbe a restringere la fonte del traffico?

— Garrett
fonte

2

Questo post sul forum IIS indica che HTTP 400 (richiesta non valida) è bloccato da http.sys e non arriva a IIS che corrisponde ai collegamenti che @Scott Forsyth - MVP ha incluso nella sua risposta originale.

È possibile visualizzare un registro di queste richieste in c: \ Windows \ System32 \ LogFiles \ HTTPERR \

Non so se è possibile configurare la pagina di risposta che viene inviata all'utente per questo tipo di errore, ma poiché anche Bing soffre di questo problema, sospetto che non sia possibile o richiederebbe alcuni orribili hack di sistema.

— Hector Correa
fonte