Un client può accedere a un evento di clic del pulsante a livello di codice se il pulsante non viene visualizzato?

Questo è nei moduli Web ASP.NET, ho un pulsante di salvataggio su uno schermo. Quando carico la pagina inizialmente, in determinate condizioni, il pulsante di salvataggio non viene visualizzato.Un client può accedere a un evento di clic del pulsante a livello di codice se il pulsante non viene visualizzato?

button1.visible = false

Nel mio pulsante cliccato evento, ho questo

public void button1_click(Object sender, EventArgs e) 
{ 
    SaveData(); 
}

L'unica sicurezza impedendo all'utente di essere il salvataggio è se il pulsante di salvataggio è reso.

In MVC, sarebbe banale accedere al metodo di azione del pulsante di salvataggio semplicemente eseguendo un POST HTTP sul server con la mia richiesta modificata.

Nei moduli Web ASP.NET, sono un po 'confuso perché si basa sul ViewState crittografato che viene posticipato. Devo ancora aggiungere questa sicurezza anche all'evento button1_click? In tal caso, puoi dirmi in che modo un client può attivare un postback sul server che raggiungerà l'evento click del pulsante senza che il pulsante sia visibile?

fonte

2015-08-04 Diskdrive

Sicuramente una domanda interessante. Anche se indipendentemente da qualsiasi risposta, probabilmente andrei con "supponiamo che la richiesta possa essere falsificata e controlli sempre l'autorizzazione". La sicurezza dovrebbe * sempre * accadere quando si gestisce la richiesta, non quando si presenta all'utente l'opzione per la richiesta. Quest'ultimo è solo UX, non di sicurezza. – David

@david - sì sicuramente. Sono più interessato a come questo potrebbe essere potenzialmente sfruttato – Diskdrive

È "banale", come dici tu in MVC solo se non riesci ad implementare le funzionalità di sicurezza di base, e lo stesso vale per i Web Form di ASP.NET. È assolutamente _può essere potenzialmente sfruttato_ (a meno che tu non faccia affidamento su molti "se e ma"). –

Questo è uno degli errori più comuni su ViewState: NON serve gli eventi di clic e molte altre cose.

Ogni clic sul pulsante (o casella di controllo se l'autopostback è abilitato) genera un modulo che invia al server. E tutte le informazioni su ciò che è stato cliccato sono incluse nei dati di postback come testo normale. Quindi il server analizza questi dati e, dato che il tuo pulsante ha IPostBackDataHandler implementato, solleva eventi appropriati come "l'id del pulsante è stato cliccato". Così, si può effettivamente cambiare richiesta corpo:

D__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPD...&ctl00%24_pdContent%24txtEmail=qwe%40aeqw.ry&ctl00%24_pdContent%24btnRtnUser=Login&__EVENTVALIDATION=%2FwEWDAL424aUAQLjtYbqCAKu8qTUCQLXm%2BfNAwKk2O%2B4DgK3ypStCAL6q%2BaACgKBnvb9CQLr8ey6CALxoZvDCALFt96ABgLMorjMAwoW3zW69NNlOXygWNnB6luGVWnk

Sopra potete vedere il contenuto di ingresso con id = ctl00__pdContent_txtEmail e pulsante di accesso cliccato con id = ctl00__pdContent_btnRtnUser.

Ulteriori spiegazioni sugli eventi del server in WebForms here.

E si prega di leggere di più su ViewState here o anche migliore spiegazione here.

fonte

2015-08-04 13:34:22 LaoR

Cosa ha detto @LaoR.È possibile, a seconda delle specifiche, includere un cookie __AntiXsrfToken nella richiesta, ma il punto di base è che tutti i dati necessari per attivare correttamente l'evento click sul server e ottenere il metodo 'button1_click' per l'esecuzione sono prontamente disponibili per il client (browser). Questo è facilmente verificabile usando Fiddler o qualcosa di simile. –

Ma non sono quegli id sul lato client? Poiché il pulsante non è mai stato visualizzato, non viene nemmeno visualizzato in html. Come modificherebbe il corpo della richiesta per attivare il clic del pulsante? Quale sarebbe l'id? – Diskdrive

@Diskdrive: in qualsiasi strumento di debug di javascript si può semplicemente chiamare '__doPostBack' con i parametri corretti. – Igor

https://stackoverflow.com/a/24064375/279911

Secondo questa risposta su un'altra domanda, sembra che non è possibile raggiungere l'evento click del pulsante se il pulsante non è reso come a quando si hanno le impostazioni di sicurezza pertinenti stabiliti.

Sì, impostare la proprietà Visible di un pulsante per falsa è sufficiente a prevenire Click e Comando eventi di essere sollevato, fino a quando non lo fai spegnere le funzioni di protezione ASP.NET di default.

fonte

2015-08-05 12:43:27 Diskdrive

Ho aggiornato la mia [risposta originale] (http://stackoverflow.com/a/240643/1/1127114) con una cosa più importante da tenere a mente. Vedi il primo punto elenco. –

Impostazione della visibilità su false non _non_ impedisce che gli eventi vengano generati. Se hai già acquisito un viewstate valido e cosa no e poi ripeti una richiesta, ovviamente gli eventi si innescano. La discussione si sta confondendo, ma con la mia interpretazione della domanda originale qui, è un errore servire la risposta di Michaels come corretta in questo contesto. –

La cosa fondamentale da riconoscere in questo è che il rendering o meno del rendering del pulsante reale non è una questione di sicurezza. È una decisione dell'interfaccia utente. (E il server si affida ai dati inviati per interpretare lo "stato" del client, la validità della richiesta e cosa fare dopo.) I dati che sono stati rilasciati al client nella risposta precedente sono irrilevanti.) Non dovrebbe essere pensato di come una sostituzione per - o anche in relazione ad altre misure di sicurezza. –

Un client può accedere a un evento di clic del pulsante a livello di codice se il pulsante non viene visualizzato?

risposta

Problemi correlati