Reindirizza a una pagina con endResponse a true VSRichiesta completa e thread di sicurezza

Basandosi su queste domande e le risposte lì , mi piace chiedere quale sia il modo corretto di reindirizzamento.

Il modo predefinito usando il Redirect (url, endResponse) è il lancio di ThreadAbortException perché viene chiamato con endResponse=true che chiama il metodo End() e quindi, se lo si utilizza all’interno di un blocco try / catch, questa eccezione viene mostrata lì e ciò può essere assunto come errore, ma in realtà un utente tenta di redirect a una pagina interrompendo il resto dell’elaborazione della pagina.

L’altro ansible è chiamare Redirect(url, endResponse) con endResponse=false following da HttpContext.Current.ApplicationInstance.CompleteRequest(); Usando questo non si ottengono eccezioni.

Quindi la domanda è cosa è meglio usare e perché.

    Devi chiamare il reindirizzamento sempre con endRespose=true oppure qualsiasi hacker può vedere cosa è nella pagina semplicemente tenendo il reindirizzamento.

    Per dimostrare che uso il plugin NoRedirect per Firefox per mantenere il reindirizzamento. Poi provo i due casi e qui ci sono i risultati:

    Ho una pagina semplice con quel testo al suo interno

     
    I am making a redirect - you must NOT see this text.

    e quindi su Caricamento pagina provare a eseguire il reindirizzamento con entrambi i casi:

    Primo caso, utilizzando la richiesta completa ();

      try { // redirect with false that did not throw exception Response.Redirect("SecondEndPage.aspx", false); // complete the Request HttpContext.Current.ApplicationInstance.CompleteRequest(); } catch (Exception x) { } 

    e lì boom, puoi vedere cosa c’è dentro la pagina!

    E secondo caso

     try { // this is throw the ThreadAbortException exception Response.Redirect("SecondEndPage.aspx", true); } catch (ThreadAbortException) { // ignore it because we know that come from the redirect } catch (Exception x) { } 

    Niente mostrato ora.

    Quindi, se non ti piace che un hacker veda cosa sia nella tua pagina, devi chiamarlo con endResponse su true e interrompere ciò che viene eseguito da altri processi -eg return from function e non continuare.

    Se ad esempio si controlla se l’utente è autenticato può vedere quella pagina o se no deve redirect per accedere, e anche nel login se si tenta di redirect con endResponse su false, quindi tenendo il reindirizzamento l’hacker può vedere – cosa credi che non sia ansible perché utilizzi il reindirizzamento.

    Il mio punto di base qui è mostrare il thread di sicurezza che esiste se non ci si ferma a inviare i dati al browser. Il reindirizzamento è un’intestazione e le istruzioni per il browser, ma allo stesso tempo è necessario interrompere l’invio di altri dati, è necessario interrompere l’invio di qualsiasi altra parte della pagina.

    Non è necessario chiamare Response.Redirect con true per endResponse per risolvere il problema di sicurezza endResponse del contenuto della pagina dopo la chiamata di reindirizzamento. È ansible eseguire questo in un altro modo ed evitare di causare una ThreadAbortException allo stesso tempo ( che è sempre male ). Di seguito sono riportati i frammenti di una pagina che ho creato con 5 pulsanti che causano reindirizzamenti in modi diversi, il pulsante RedirectRenderOverride è l’ideale in quanto è quello che triggers il metodo Render per non fare nulla. Questo è stato testato con il componente aggiuntivo NoRedirect. Solo due casi evitano di emettere qualcosa di diverso dalla risposta spostata dall’object 302: RedirectEnd e RedirectRenderOverride .

    Codice in primo piano

          

    Codice dietro

     public partial class _Default : Page { private bool _isTerminating; protected void RedirectEnd(object sender, EventArgs e) { Response.Redirect("Redirected.aspx"); } protected void RedirectCompleteRequest(object sender, EventArgs e) { Response.Redirect("Redirected.aspx", false); HttpContext.Current.ApplicationInstance.CompleteRequest(); } protected void RedirectClear(object sender, EventArgs e) { Response.Clear(); Response.Redirect("Redirected.aspx", false); } protected void RedirectRenderOverride(object sender, EventArgs e) { Response.Redirect("Redirected.aspx", false); _isTerminating = true; } protected void RedirectEndInTryCatch(object sender, EventArgs e) { try { Response.Redirect("Redirected.aspx"); } catch (ThreadAbortException) { // eat it } finally { Response.Write("Still doing stuff!"); } } protected override void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument) { if (!_isTerminating) { base.RaisePostBackEvent(sourceControl, eventArgument); } } protected override void Render(HtmlTextWriter writer) { if (!_isTerminating) { base.Render(writer); } } } 

    Response.End chiama internamente Thread.CurrentThread.Abort e, secondo Eric Lippert , chiamando Thread.Abort , “è al massimo indicativo di un cattivo design, probabilmente inaffidabile ed estremamente pericoloso.”